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 30E4EC05027 for ; Tue, 14 Feb 2023 09:32:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232052AbjBNJcc (ORCPT ); Tue, 14 Feb 2023 04:32:32 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41810 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230240AbjBNJc3 (ORCPT ); Tue, 14 Feb 2023 04:32:29 -0500 Received: from mail.skyhub.de (mail.skyhub.de [IPv6:2a01:4f8:190:11c2::b:1457]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D2B3C1BCF for ; Tue, 14 Feb 2023 01:32:27 -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 5FA501EC08BF; Tue, 14 Feb 2023 10:32:26 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1676367146; 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=fQgdfPdv5IbY5cjTtif8wZ2LVGgZcfMSUHyLgK6pkrs=; b=EB1Hnf7ESNTSiJOA07Nf1Fb2ktw9Lxhh60+dGPEBvYWvJRvEo3Ikum/jxkZc2AUgrmxX3r sq8Y0Sgu/gHHtvFzF0S5OiaUk6fgGBUrFQ9fLHzX0J13TwoGj3WEl89WJJbxiqvO1P5uWZ N2A/JA0a1OLoXvxCkokXWC9Zvhzv1h4= Date: Tue, 14 Feb 2023 10:32:22 +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: <85de8576-05b7-400d-6020-7dba519c1d2e@suse.com> <6f561386-9bc4-a3bf-656d-db27a2275413@suse.com> <3520cd7f-0e60-b140-9fd3-032ddb6778b5@suse.com> <807cca5b-06b9-da85-738b-d88fc10298cb@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <807cca5b-06b9-da85-738b-d88fc10298cb@suse.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 14, 2023 at 10:17:12AM +0100, Juergen Gross wrote: > I guess this largely depends on the functionality. I don't see why anyone > would try to use MTRR overwrite functionality without really needing it. > > But maybe I'm wrong here and I'm under-estimating the "creativity" of > kernel hackers. This is exactly it - if it is there, it will get used eventually. Think of it this way: this is a special, well, kinda hack, if you will, which *nothing* else would need. We can always relax the condition for using it if something else appears with a valid use case. What we can't do nearly as easily is the reverse: remove it or tighten the check later. So the general policy is: workarounds like this need to be as specialized as possible. > Maybe I haven't seen enough crazy hacks yet. :-) You're kidding, right? You hack on Xen for a long time... :-P > No need to further discuss this topic from my side, as I have voiced my > opinion and you did so, too. I will add the tests you are asking for. Thanks! -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette