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


[Xen-devel] Re: [PATCH 12/12] xen/mtrr: Add mtrr_if support for Xen mtrr

To: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Subject: [Xen-devel] Re: [PATCH 12/12] xen/mtrr: Add mtrr_if support for Xen mtrr
From: "H. Peter Anvin" <hpa@xxxxxxxxx>
Date: Tue, 28 Sep 2010 11:46:24 -0700
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>, "sct@xxxxxxxxxx" <sct@xxxxxxxxxx>, "linux-kernel@xxxxxxxxxxxxxxx" <linux-kernel@xxxxxxxxxxxxxxx>, Jeremy Fitzhardinge <Jeremy.Fitzhardinge@xxxxxxxxxx>, Ingo Molnar <mingo@xxxxxxx>, Thomas Gleixner <tglx@xxxxxxxxxxxxx>
Delivery-date: Tue, 28 Sep 2010 11:47:34 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4CA232EF.3080906@xxxxxxxx>
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: <alpine.DEB.2.00.1009281217540.2864@kaball-desktop> <1285676218-26218-12-git-send-email-stefano.stabellini@xxxxxxxxxxxxx> <20100928123925.GA18208@xxxxxxx> <alpine.DEB.2.00.1009281455300.2864@kaball-desktop> <4CA2223B.9040400@xxxxxxxx> <4CA22C3C.3020209@xxxxxxxxx> <4CA2302C.3000201@xxxxxxxx> <4CA231A8.5000100@xxxxxxxxx> <4CA232EF.3080906@xxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20100907 Fedora/3.1.3-1.fc13 Thunderbird/3.1.3
On 09/28/2010 11:24 AM, Jeremy Fitzhardinge wrote:
>> No, and we really can't do it for a couple of reasons:
>> a) Pre-PAT hardware;
>> b) MTRRs and PAT interact on hardware;
>> c) MTRRs, but not PAT, interact with SMM.
> What about pre-PAT software (ie, X servers which still use /proc/mtrr)?

Fortunately going away... we have talked in the past about doing
"virtual MTRRs" in terms of PAT to deal with this kind of legacy
software, but the demand for it seems to be low enough to not be worth
bothering with.

>> However, since a virtual machine like Xen doesn't have these issues, it
>> doesn't apply
> Well, we're specifically talking about a virtual machine which has
> direct access to hardware, so it is concerned about the real physical
> memory properties of real physical pages.  If we can assume that
> BIOS/Xen will always set up MTRR correctly then there shouldn't be any
> need for the kernel to modify the MTRR itself.  How true is that in
> general?  I don't know, but if we could rely on BIOS then there'd never
> be a need to touch MTRR, would there?

Well, in the past MTRRs were abused for device properties mainly by the
X server, but other than that, no, not really.  The other thing we do is
the MTRR cleanup (which doesn't involve /proc/mtrr) to deal with
brokenness in the BIOS setup, but that really belongs in the hypervisor
in your case since it fundamentally affects how memory is handled.


Xen-devel mailing list