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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
>>> Jeremy Fitzhardinge <jeremy@goop.org> 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). Third, performance would likely suffer (MTRR-{WC,UC} + PAT-WT -> UC whereas MTRR-{WC,UC} + PAT-WC -> WC). Plus all of this would need revisiting once Linux decides to use WT or WP. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Konrad Rzeszutek Wilk
2010-Mar-30 16:57 UTC
[Xen-devel] Re: Xen''s use of PAT and PV guests
On Mon, Mar 29, 2010 at 05:35:57PM -0700, Jeremy Fitzhardinge wrote:> 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:And this LKML is good a primer: http://www.linuxsymposium.org/archives/OLS/Reprints-2008/pallipadi-reprint.pdf> > 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)How does this work on pages shared across domains? Say Guest A makes the page WC,Dom0 makes it WB and Xen puts it in WC, and Dom0 reads does a Write/Read/Write, but in actuallity it is a Read/Write/Write. Or is there no danger there since the grant table pages have UC set on them?> 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 WCThat would make all writes synchronous. Why not write back?> > 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...The graphics cards (and the XServer) are the ones that come in my mind as heavy users of having this "just right". But in most (all?) cases they want it to be UC or better UC- so that shouldn''t affect this. http://lkml.indiana.edu/hypermail/linux/kernel/9904.1/0306.html Ah, but of course, there is an exception: (i915_dma.c): gtt = ioremap_wc(pci_resource_start(dev->pdev, gtt_bar) + gtt_offset, gtt_size); and then ''ttm_bo_ioremap'' which does the ioremap_wc if TTM_PL_FLAG_WC is set. And it looks to be is set by the Radeon (if card is an AGP) and nouveau on their first memory BAR. Also the vmwgfx (VMWare) driver sets this, but we don''t have to worry about that. So I think setting it to WC->WT would mean that graphics performance would go down the drain. But then, there are some lingering issues with the TTM/DRM infrastructure that need to tracked down and I believe Arvind and Michael are actively looking at that. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 03/30/2010 12:44 AM, Jan Beulich wrote:>>>> Jeremy Fitzhardinge<jeremy@goop.org> 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@lists.xensource.com http://lists.xensource.com/xen-devel
On Tue, 2010-03-30 at 01:35 +0100, Jeremy Fitzhardinge wrote:> 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 had a patch ages ago (which I have now lost) that caused the kernel to read back the PAT MSR after writing it and try and locate a suitable entry for each cache setting it was interested in (with fallbacks as appropriate) to use dynamically thereafter. This has the nice property that Linux could write what it really wanted to the PAT register but it would then read and use whatever it actually ended up with. I''m not sure that this scheme is at all upstreamable though. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 30/03/2010 18:39, "Jeremy Fitzhardinge" <jeremy@goop.org> wrote:> Does Xen guarantee that PAT is always available to vcpus as part of its > ABI (ie, do we support any pre-PAT cpus?).As it happens I think we do only support CPUs that have PAT. But you can always check CPUID, just like running natively. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jeremy Fitzhardinge
2010-Mar-30 18:25 UTC
Re: [Xen-devel] Re: Xen''s use of PAT and PV guests
On 03/30/2010 10:59 AM, Keir Fraser wrote:> As it happens I think we do only support CPUs that have PAT. But you can > always check CPUID, just like running natively. >Yeah, I wasn''t going to remove any of the tests, but I was wondering if the guest can always assume that it can set the pat flags in the pte. I guess that since Xen uses the same settings for the default pat (=no pat at all), then so long as the guest doesn''t try to set _PAGE_PAT, then it doesn''t matter. Unfortunately hugetlbfs adds a wart, since it appears to end up going down to the make_pte/pte_val path, but we can''t tell whether its a page with _PAGE_PSE or _PAGE_PAT set... J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jeremy Fitzhardinge
2010-Mar-30 18:43 UTC
Re: [Xen-devel] Re: Xen''s use of PAT and PV guests
On 03/30/2010 09:57 AM, Konrad Rzeszutek Wilk wrote:> On Mon, Mar 29, 2010 at 05:35:57PM -0700, Jeremy Fitzhardinge wrote: > >> 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: >> > And this LKML is good a primer: > > http://www.linuxsymposium.org/archives/OLS/Reprints-2008/pallipadi-reprint.pdf >Thanks, just what I was looking for.>> 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) >> > How does this work on pages shared across domains? Say Guest A makes the > page WC,Dom0 makes it WB and Xen puts it in WC, and Dom0 reads does a > Write/Read/Write, but in actuallity it is a Read/Write/Write. Or is > there no danger there since the grant table pages have UC set on them? >Not sure. That would invoke undefined behaviour, I''d assume. Does Xen keep track of memory type aliases? Grant pages don''t have to be UC do they? Pages between front and backends don''t need to be (and shouldn''t be) UC.> The graphics cards (and the XServer) are the ones that come in my mind > as heavy users of having this "just right". But in most (all?) cases > they want it to be UC or better UC- so that shouldn''t affect this. >Hm, I don''t want to try out-guessing Linux''s use of all these modes; we need to either get it right or not try. J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 03/30/2010 10:56 AM, Ian Campbell wrote:> I had a patch ages ago (which I have now lost) that caused the kernel to > read back the PAT MSR after writing it and try and locate a suitable > entry for each cache setting it was interested in (with fallbacks as > appropriate) to use dynamically thereafter. > > This has the nice property that Linux could write what it really wanted > to the PAT register but it would then read and use whatever it actually > ended up with. >I started to implement something like that, but stopped and decided to do a much simpler hack. I wanted to make sure that make_pte and pte_val are proper inverses of each other, so pte_val needs to do the reverse mapping from xen pte pat flags -> linux pte pat flags. Given that the only difference between Xen and Linux is whether _PAGE_PWT means WT or WC, it is easy to do the mapping forward and back. But hugetlbfs adds the complication that it ends up constructing ptes via the pte operations (which makes logical sense), but on x86 that''s a mess because the meaning of _PAGE_PAT changes to _PAGE_PSE on level 2/3/4 entries, and there''s no way of knowing what level we''re looking at. At the moment I''m winging it by ignoring _PAGE_PAT in make_pte, and hope that nobody wants to do pte_val on a hugetlbfs pte... Looks like the proper fix is to stop hugetlbfs from using mk_pte, and add a mk_huge_tlb instead, and have the x86 version use the pmd operations.> I''m not sure that this scheme is at all upstreamable though. >I don''t see why not; it would all be hidden away in the Xen code, and maintains the normal x86 illusion. It''s just a matter of hooking wrmsr, make_pte and pte_val, which we do already. J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>>> Jeremy Fitzhardinge <jeremy@goop.org> 30.03.10 20:43 >>> >On 03/30/2010 09:57 AM, Konrad Rzeszutek Wilk wrote: >> How does this work on pages shared across domains? Say Guest A makes the >> page WC,Dom0 makes it WB and Xen puts it in WC, and Dom0 reads does a >> Write/Read/Write, but in actuallity it is a Read/Write/Write. Or is >> there no danger there since the grant table pages have UC set on them? >> > >Not sure. That would invoke undefined behaviour, I''d assume. Does Xen >keep track of memory type aliases? Grant pages don''t have to be UC do >they? Pages between front and backends don''t need to be (and shouldn''t >be) UC.Granted pages are RAM pages, and hence should always be WB everywhere. As to Xen''s memory type handling - iirc the most recent memory type used in a page table entry determines what Xen uses in its 1:1 mapping, but I don''t think global consistency is being enforced. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Tue, 2010-03-30 at 22:47 +0100, Jeremy Fitzhardinge wrote:> > > I''m not sure that this scheme is at all upstreamable though. > > > > I don''t see why not; it would all be hidden away in the Xen code, and > maintains the normal x86 illusion. It''s just a matter of hooking > wrmsr, make_pte and pte_val, which we do already.I was referring to my patch which wasn''t at all hidden away in the Xen code. Anyway I''ve found and attached it for your amusement, it''s not nearly as fully baked as I remembered ;-) In my defence the date stamp on the patch file is May 2009... Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 03/31/2010 01:31 AM, Ian Campbell wrote:> I was referring to my patch which wasn''t at all hidden away in the Xen > code. Anyway I''ve found and attached it for your amusement, it''s not > nearly as fully baked as I remembered ;-) In my defence the date stamp > on the patch file is May 2009... >Urk, yeah, that''s going to be much harder to make fly. Conversion at the make_pte/pte_val level gets us most of way there with less intrusion. J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel