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
|
Home