[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y1pQFjiVi9wajQH4@zn.tnic>
Date: Thu, 27 Oct 2022 11:32:06 +0200
From: Borislav Petkov <bp@...en8.de>
To: Juergen Gross <jgross@...e.com>
Cc: linux-kernel@...r.kernel.org, x86@...nel.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 v4 09/16] x86/mtrr: simplify mtrr_bp_init()
On Tue, Oct 04, 2022 at 10:10:16AM +0200, Juergen Gross wrote:
> In case of the generic cache interface being used (Intel CPUs or a
> 64-bit system), the initialization sequence of the boot CPU is more
> complicated as necessary:
s/as/than/
>
> - check if MTRR enabled, if yes, call mtrr_bp_pat_init() which will
> disable caching, set the PAT MSR, and reenable caching
>
> - call mtrr_cleanup(), in case that changed anything, call
> cache_cpu_init() doing the same caching disable/enable dance as
> above, but this time with setting the (modified) MTRR state (even
> if MTRR was disabled) AND setting the PAT MSR (again even with
> disabled MTRR)
>
> The sequence can be simplified a lot while removing potential
> inconsistencies:
>
> - check if MTRR enabled, if yes, call mtrr_cleanup() and then
> cache_cpu_init()
>
> This ensures to:
>
> - no longer disable/enable caching more than once
>
> - avoid to set MTRRs and/or the PAT MSR on the boot processor in case
> of MTRR cleanups even if MTRRs meant to be disabled
>
> With that mtrr_bp_pat_init() can be removed.
I like that simplification - I just hope there's not some weird ordering
that is still needed. But we'll see when this hits the wider audiences.
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
Powered by blists - more mailing lists