[Xen-devel] Re: Xen's use of PAT and PV guests

[Jeremy Fitzhardinge <jeremy@xxxxxxxx>]

On 03/30/2010 12:44 AM, Jan Beulich wrote:
> > > > Jeremy Fitzhardinge<jeremy@xxxxxxxx>  30.03.10 02:35>>>
> > > >          
> > 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...
> >      
> No. For one, while WT is cachable (for reads), WC isn't.
>
> Second, when the MTRRs indicate WC, using WT from PAT is not
> recommended (and was earlier documented as undefined behavior).
>    
Yes, I noticed that, and I wondered if that was why Linux is using WC, 
for max compatibility.  But presumably since it is now defined 
unconditionally, it means that all older (Intel, at least) 
implementations have that defined behaviour.
> Third, performance would likely suffer (MTRR-{WC,UC} + PAT-WT ->  UC
> whereas MTRR-{WC,UC} + PAT-WC ->  WC).
>    
Yeah.  If !pat_enabled, Linux will map a WC pte into UC-.

> Plus all of this would need revisiting once Linux decides to use WT
> or WP.
>    
Yes.

Ah, I think I know how to do it now: when constructing a PTE, remap 
Linux's PWT to Xen's PAT to end up with a WC PTE.
Does Xen guarantee that PAT is always available to vcpus as part of its 
ABI  (ie, do we support any pre-PAT cpus?).
Also, I'm assuming Xen's PAT entries 6 and 7 are reserved, in case Intel 
defines 2 and 3?
    J

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel