Messages in this thread Patch in this message | | | Date | Thu, 10 Mar 2016 22:07:18 +0100 | From | Borislav Petkov <> | Subject | Re: runtime regression with "x86/mm/pat: Emulate PAT when it is disabled" |
| |
On Thu, Mar 10, 2016 at 01:24:11PM -0700, Toshi Kani wrote: > I am not familiar with PPRO_FEATURES,
That's the feature bits of the "qemu32" model, and others, in qemu.
> but shouldn't 'flags' in /proc/cpuinfo show "pat" when X86_FEATURE_PAT is set?
static void early_init_intel(struct cpuinfo_x86 *c) ...
/* * There is a known erratum on Pentium III and Core Solo * and Core Duo CPUs. * " Page with PAT set to WC while associated MTRR is UC * may consolidate to UC " * Because of this erratum, it is better to stick with * setting WC in MTRR rather than using PAT on these CPUs. * * Enable PAT WC only on P4, Core 2 or later CPUs. */ if (c->x86 == 6 && c->x86_model < 15) clear_cpu_cap(c, X86_FEATURE_PAT); ---
which also gives a hint as to how we should fix this: pat_enabled() needs to look at that feature bit too:
--- diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.c index faec01e7a17d..359c30d9a78c 100644 --- a/arch/x86/mm/pat.c +++ b/arch/x86/mm/pat.c @@ -56,7 +56,7 @@ early_param("nopat", nopat); bool pat_enabled(void) { - return !!__pat_enabled; + return !!__pat_enabled && static_cpu_has(X86_FEATURE_PAT); } EXPORT_SYMBOL_GPL(pat_enabled); --- Makes sense?
> pat_init() is being called as part of MTRR setup because PAT > initialization requires the same CPU rendezvous operation implemented > in the MTRR code.
... which means, PAT depends on MTRR being present.
-- Regards/Gruss, Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) --
| |