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: [GIT PULL] xen /proc/mtrr implementation

To: Ingo Molnar <mingo@xxxxxxx>
Subject: [Xen-devel] Re: [GIT PULL] xen /proc/mtrr implementation
From: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Date: Mon, 18 May 2009 11:07:52 -0700
Cc: Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, the arch/x86 maintainers <x86@xxxxxxxxxx>, Linux Kernel Mailing List <linux-kernel@xxxxxxxxxxxxxxx>, Jesse Barnes <jbarnes@xxxxxxxxxxxxxxxx>, "Eric W. Biederman" <ebiederm@xxxxxxxxxxxx>, "H. Peter Anvin" <hpa@xxxxxxxxx>, Thomas Gleixner <tglx@xxxxxxxxxxxxx>, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
Delivery-date: Mon, 18 May 2009 11:08:31 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20090518085902.GE10687@xxxxxxx>
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> <4A10EAC4.9070701@xxxxxxxx> <20090518085902.GE10687@xxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird (X11/20090320)
Ingo Molnar wrote:
Here Xen invades an already fragile piece of upstream code (/proc/mtrr) that is obsolete and on the way out. If you want a solution you should add PAT support to Xen and you should use recent upstream kernels. Or you should emulate /proc/mtrr in _Xen the hypervisor_, if you really care that much - without increasing the amount of crap in Linux.

That's a gross mis-characterisation of what we're talking about here.

arch/x86 already defines an mtrr_ops, which defines how to manipulate the MTRR registers. There are currently several implementations of that interface. In Xen the MTRR registers belong to the hypervisor, but it allows a privileged kernel to modify them via hypercalls. I simply added a new, straightforward mtrr_ops implementation to do that. It adds about 120 lines of new code, in a single mtrr/xen.c file.

That's it. I could add any number of bizarre convolutions to achieve the same effect, but given that there's an existing interface that is exactly designed for what we want to achieve, I have to admit it didn't occur to me to do anything else.

MTRR may well be on its way out, and PAT is the proper way to achieve the same effect from now on. But MTRR is still a widely used kernel-internal API as well as usermode ABI, and it seems just gratuitous to not support it when doing so is such a low-impact change. And if/when it comes to be time to completely deprecate/remove mtrr support, we can delete it along with everything else.

I'm honestly at a loss to explain the vehemence of your objection to these changes given their nature.

We're also working on making PAT support work where possible. But that doesn't mean we want to do without anything in the meantime.

But more generally, we need to work out how to move things forward.

That said, we can live without. If these MTRR patches are your biggest concern, drop them, pull the rest so we can get them seen, tested, in linux-next, etc, ready for the next merge window. You know, like you said you wanted to do the last time you blocked the Xen patches.

I would prefer to move them through tip.git: I appreciate your (constructive) comments and reviews, the testing infrastructure has proved very valuable in the past, and they'll generally get wider exposure than my pool of testers. And its just the right way to do it.

But if you're so concerned that they'll simply give Linus more ammunition to beat you up with, to the extent that you're second-guessing yourself, then I'm perfectly happy to submit them myself. I don't think it would be an overall better outcome, but it keeps the heat off you, and we'd be making some progress.


Xen-devel mailing list

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