WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] Re: [GIT PULL] xen /proc/mtrr implementation

To: "Eric W. Biederman" <ebiederm@xxxxxxxxxxxx>
Subject: [Xen-devel] Re: [GIT PULL] xen /proc/mtrr implementation
From: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Date: Sun, 17 May 2009 21:57:40 -0700
Cc: Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Ingo Molnar <mingo@xxxxxxx>, the arch/x86 maintainers <x86@xxxxxxxxxx>, Linux Kernel Mailing List <linux-kernel@xxxxxxxxxxxxxxx>, Jesse Barnes <jbarnes@xxxxxxxxxxxxxxxx>
Delivery-date: Sun, 17 May 2009 21:58:08 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <m1iqk1k708.fsf@xxxxxxxxxxxxxxxxx>
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: <1242170864-13560-1-git-send-email-jeremy@xxxxxxxx> <20090513133021.GA7277@xxxxxxx> <4A0ADBA2.2020300@xxxxxxxx> <20090515182757.GA19256@xxxxxxx> <4A0DCC11.10307@xxxxxxxx> <m1my9ex818.fsf@xxxxxxxxxxxxxxxxx> <4A0DFF78.6000501@xxxxxxxx> <20090515202250.0f1218ef@jbarnes-g45> <m1iqk1k708.fsf@xxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 2.0.0.21 (X11/20090320)
Eric W. Biederman wrote:
There are only 3 states that are interesting.  WB UC and WC.  Since
Xen controls the page tables anyway.  I expect it can even remap
it feels like it.

It would be awkward. A paravirtualized guest has direct access to the real pagetables, and so would notice if Xen swizzled around the PAT bits when it reads back a pagetable entry. We don't currently have any paravirtualized hooks for adjusting the PTE flags, because there hasn't been any need, and it would probably be pretty costly (lots of read+bit-tests would turn into a function call). On the other hand, there's probably only a few places (if any) in the kernel which actually inspect the PAT status of an established PTE, so we could put in some special case mapping there. It becomes a maintenance burden to 1) track down all the right places, and then 2) make sure any new instances get handled properly. So, not a preferred solution, I think.

But our planned approach is to simply make Xen use the same PAT layout as Linux, and go from there. We still need to sort out the details of how to handle other Xen guests which use the existing Xen PAT setup, how to verify that Xen and the guest kernel are really using the same setup, etc.

But since we support the last few year's worth of released versions of Xen, we still need to handle the PAT-not-supported case with reasonable grace.

I won't argue that having MTRRs when you can makes sense.  It is a bit
weird in a vitalized system.

It's not really virtualized. We're talking about dom0, which is the guest domain which has access to the real machine's real hardware; the MTRR is part of that.

  At a practical level there are an
increasing number of systems for which MTRRs are unusable because the
BIOS sets up overlapping mtrrs.  With cheap entry level systems
shipping with 4G I expect it is becoming a majority of systems.

Yes, but that is true irrespective of Xen.

   J

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

<Prev in Thread] Current Thread [Next in Thread>