[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f82f5bd0-6455-ffe7-fcc2-834517db1f42@suse.com>
Date: Thu, 1 Jun 2023 14:53:20 +0200
From: Juergen Gross <jgross@...e.com>
To: Borislav Petkov <bp@...en8.de>
Cc: linux-kernel@...r.kernel.org, x86@...nel.org,
linux-hyperv@...r.kernel.org, linux-doc@...r.kernel.org,
mikelley@...rosoft.com, Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
Dave Hansen <dave.hansen@...ux.intel.com>,
"H. Peter Anvin" <hpa@...or.com>,
"K. Y. Srinivasan" <kys@...rosoft.com>,
Haiyang Zhang <haiyangz@...rosoft.com>,
Wei Liu <wei.liu@...nel.org>, Dexuan Cui <decui@...rosoft.com>,
Boris Ostrovsky <boris.ostrovsky@...cle.com>,
xen-devel@...ts.xenproject.org, Jonathan Corbet <corbet@....net>,
Andy Lutomirski <luto@...nel.org>,
Peter Zijlstra <peterz@...radead.org>
Subject: Re: [PATCH v6 00/16] x86/mtrr: fix handling with PAT but without MTRR
On 01.06.23 14:48, Borislav Petkov wrote:
> On Thu, Jun 01, 2023 at 08:39:17AM +0200, Juergen Gross wrote:
>> Does this translate to: "we should remove that cleanup crap"? I'd be
>> positive to that. :-)
>
> Why, what's wrong with that thing?
>
Why do you need it if you don't think adding MTRRs dynamically is
important?
Having a sub-optimal MTRR setup doesn't matter unless you are running
out of MTRRs to use. When you are not adding MTRRs, you can't run out
of them.
This in turn means you don't need mtrr_cleanup().
Juergen
Download attachment "OpenPGP_0xB0DE9DD628BF132F.asc" of type "application/pgp-keys" (3099 bytes)
Download attachment "OpenPGP_signature" of type "application/pgp-signature" (496 bytes)
Powered by blists - more mailing lists