[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • To: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
  • From: Jesse Barnes <jbarnes@xxxxxxxxxxxxxxxx>
  • Date: Fri, 15 May 2009 20:22:50 -0700
  • Cc: Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, the arch/x86 maintainers <x86@xxxxxxxxxx>, Mailing List <linux-kernel@xxxxxxxxxxxxxxx>, "Eric W. Biederman" <ebiederm@xxxxxxxxxxxx>, Linux, Ingo Molnar <mingo@xxxxxxx>
  • Delivery-date: Fri, 15 May 2009 20:23:24 -0700
  • Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=virtuousgeek.org; h=Received:Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References:X-Mailer:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=dQBJxskyedw5H7vlXfyw7oz/Y9rrK6wSflPMfhyXrTlhSf/8g7gQRruoKPmhCusjdjgOAjLhutlDkAKkRTG6nitSMxpONZdKW46OTdFjYzcuirShXveZIVyrbViQ0LQP;
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

On Fri, 15 May 2009 16:49:12 -0700
Jeremy Fitzhardinge <jeremy@xxxxxxxx> wrote:

> 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.

FWIW I think supporting the MTRR API in Xen makes sense.  There's a lot
of old code out there that wants it; would be nice if it mostly worked,
especially at such a minimal cost.  It's taken awhile to get PAT going
(and there are still issues here and there) so having the MTRR stuffa
available is awfully nice.

-- 
Jesse Barnes, Intel Open Source Technology Center

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.