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: Fri, 15 May 2009 16:49:12 -0700
Cc: Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Ingo Molnar <mingo@xxxxxxx>, the arch/x86 maintainers <x86@xxxxxxxxxx>, Linux Kernel Mailing List <linux-kernel@xxxxxxxxxxxxxxx>
Delivery-date: Fri, 15 May 2009 16:49:39 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <m1my9ex818.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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 2.0.0.21 (X11/20090320)
Eric W. Biederman wrote:
/proc/mtrr is in wide use today.  It may be planned for obsolescence, but
there's no way you can claim its obsolete today (my completely up-to-date F10 X
server is using it, for example).  We don't break oldish usermode ABIs in new
kernels.

Sure it is.  There is a better newer replacement.  It is taking a while to
get userspace transitioned but that is different.  Honestly I am puzzled
why that it but whatever.

There's no mention in feature-removal-schedule.txt.

Besides, the MTRR code is also a kernel-internal API, used by DRM and other
drivers to configure the system MTRR state.  Those drivers will either perform
badly or outright fail if they can't set the appropriate cachability properties.
That is not obsolete in any way.

There are about 5 of them so let's fix them.

Well, I count at least 30+, but anyway.

With PAT we are in a much better position both for portability and for
flexibility.

PAT is relatively recent, and even more recently bug-free. There are many people with processors which can't or won't do PAT; what's the plan to support them? Just hit them with a performance regression? Or wrap MTRR in some other API?

Is it possible to fix PAT and get that working first.   That is very definitely
the preferend API.

Sure, when available. We're sorting out the details for Xen, but even then it may not be available, either because we're running on an old version of Xen, or because some other guest is using PAT differently.

But I honestly don't understand the hostility towards 120 lines of code to make an interface (albeit legacy/deprecated/whatever) behave in an expected way.

   J

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

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