Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id EC7D1C61DA4 for ; Tue, 14 Feb 2023 09:12:09 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231414AbjBNJMI (ORCPT ); Tue, 14 Feb 2023 04:12:08 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45162 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232303AbjBNJLp (ORCPT ); Tue, 14 Feb 2023 04:11:45 -0500 Received: from mail.skyhub.de (mail.skyhub.de [5.9.137.197]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 27DE9241D0 for ; Tue, 14 Feb 2023 01:10:10 -0800 (PST) Received: from zn.tnic (p5de8e9fe.dip0.t-ipconnect.de [93.232.233.254]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id A0D9E1EC08BF; Tue, 14 Feb 2023 10:10:08 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1676365808; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:in-reply-to:in-reply-to: references:references; bh=lJzUNBJF+EToTnj0WiHGhlsiqWuytRkjeSbLDMewF1M=; b=o6xc/2CaOy9m7rKWTjNM/rAiF/3clYs4bUeU4ZSmsE7AiUyaEYb3AfCtudCGi/ofNtDIe2 qQh6udms/y6taXFj9yc4bU4PpldahUTadv2FWT6oseskBEximfnnXu2LfYTWpUCOZaM2tT TYXmrS+hWaNiHQPbAzHi2b9ubwWQGsk= Date: Tue, 14 Feb 2023 10:10:05 +0100 From: Borislav Petkov To: Juergen Gross Cc: linux-kernel@vger.kernel.org, x86@kernel.org, lists@nerdbynature.de, mikelley@microsoft.com, torvalds@linux-foundation.org, Thomas Gleixner , Ingo Molnar , Dave Hansen , "H. Peter Anvin" Subject: Re: [PATCH v2 2/8] x86/mtrr: support setting MTRR state for software defined MTRRs Message-ID: References: <6257114d-a957-f586-145c-d2a885417360@suse.com> <85de8576-05b7-400d-6020-7dba519c1d2e@suse.com> <6f561386-9bc4-a3bf-656d-db27a2275413@suse.com> <3520cd7f-0e60-b140-9fd3-032ddb6778b5@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <3520cd7f-0e60-b140-9fd3-032ddb6778b5@suse.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 14, 2023 at 10:02:51AM +0100, Juergen Gross wrote: > I just don't like the idea of trying to catch all possible misuses in > lower levels, at the same time introducing the need to modify those > tests in case a new valid use case is popping up. So what would you do: generally allow this so that potentially other guest configurations misuse it? And when we decide to change it, all those users will come running and complaining that we broke it? And then we're stuck with a nasty workaround in the tree because we have to support them too? See, all we do here is because of such misguided (or maybe didn't know better) decisions which have happened a long time ago. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette