Xen's use of PAT and PV guests

[Jeremy Fitzhardinge <jeremy@goop.org>]

I'm looking again at what it will take to reconcile Xen's PAT setup with 
the standard Linux one so that we can enable PAT use in pvops kernels.

Just for reference, this is the Linux vs Xen vs default PAT setups:

Index	PTE flags	Linux	Xen	Default
0			WB	WB	WB
1	        PWT	WC	WT	WT
2	    PCD	   	UC-	UC-	UC-
3	    PCD PWT	UC	UC	UC
4	PAT        	WB	WC	WB
5	PAT     PWT	WC	WP	WT
6	PAT PCD	   	UC-	UC	UC-
7	PAT PCD PWT	UC	UC	UC


Originally I was thinking of a moderately complex scheme in which an ELF 
node on the dom0 kernel could determine the system-wide Xen PAT MSR, and 
then the kernel ELF notes on subsequent domains would determine whether 
the PAT CPU feature flag is enabled or not.

However this has several problems:

   1. it is fairly complex
   2. if dom0 sets the PAT configuration to something strange, it may
      completely break other PV guests entirely (since it might
      effectively change the meaning of PCD+PWT globally)
   3. disabling the PAT CPU feature flag is meaningless, as its only
      effect is to say "there's no PAT, so PCD/PWT have their default
      behaviours", which is definitely not true in general

Linux only uses the first 4 PAT entries, and repeats it, effectively 
making the PAT pte flag a don't-care.  In those 4 entries, the Linux, 
Xen and Default configurations are identical aside from Linux using WC 
rather than WT.

It therefore seems to me that if I make Linux:

   1. never set the PAT flag (which it won't anyway),
   2. check that the value written to IA32_PAT is as expected, but
      otherwise ignore it, and
   3. use WT rather than WC

then it all should just work.  I'm not completely confident in the third 
point though, since I'm not quite sure about the full set of differences 
between WT and WC, and their respective interactions with the MTRR, and 
whether that would break anything.  At first glance it seems pretty safe 
though...

Thoughts?

     J