This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

To: Ian Campbell <Ian.Campbell@xxxxxxxxxx>
Subject: Re: [Xen-devel] Xen's use of PAT and PV guests
From: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Date: Tue, 30 Mar 2010 14:47:07 -0700
Cc: Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Keir Fraser <Keir.Fraser@xxxxxxxxxxxxx>, Jan Beulich <JBeulich@xxxxxxxxxx>, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Delivery-date: Tue, 30 Mar 2010 14:47:54 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1269971775.2490.88.camel@xxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <4BB1476D.4060209@xxxxxxxx> <1269971775.2490.88.camel@xxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20100301 Fedora/3.0.3-1.fc12 Lightning/1.0b2pre Thunderbird/3.0.3
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.


Xen-devel mailing list