[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.