[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y+tVJkzkeVkf1q2a@zn.tnic>
Date: Tue, 14 Feb 2023 10:32:22 +0100
From: Borislav Petkov <bp@...en8.de>
To: Juergen Gross <jgross@...e.com>
Cc: linux-kernel@...r.kernel.org, x86@...nel.org,
lists@...dbynature.de, mikelley@...rosoft.com,
torvalds@...ux-foundation.org,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
Dave Hansen <dave.hansen@...ux.intel.com>,
"H. Peter Anvin" <hpa@...or.com>
Subject: Re: [PATCH v2 2/8] x86/mtrr: support setting MTRR state for software
defined MTRRs
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
Powered by blists - more mailing lists