Re: runtime regression with "x86/mm/pat: Emulate PAT when it is disabled"

From: Borislav Petkov
Date: Thu Mar 10 2016 - 16:08:35 EST

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);

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.


SUSE Linux GmbH, GF: Felix ImendÃrffer, Jane Smithard, Graham Norton, HRB 21284 (AG NÃrnberg)