mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Jesse Barnes <jbarnes@virtuousgeek.org>
To: ebiederm@xmission.com (Eric W. Biederman)
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Ingo Molnar <mingo@elte.hu>,
	the arch/x86 maintainers <x86@kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [GIT PULL] xen /proc/mtrr implementation
Date: Sat, 16 May 2009 11:22:33 -0700	[thread overview]
Message-ID: <20090516112233.5cb085c8@jbarnes-g45> (raw)
In-Reply-To: <m1iqk1k708.fsf@fess.ebiederm.org>

On Fri, 15 May 2009 21:26:47 -0700
ebiederm@xmission.com (Eric W. Biederman) wrote:
> > 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.
> 
> I won't argue that having MTRRs when you can makes sense.  It is a bit
> weird in a vitalized system.  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.

Yeah, MTRRs definitely have issues too; as you say on many recent
machines they're tougher to use.  Either we need to reprogram them to
free some up for WC mappings, or use PAT.  But that's a relatively
recent development (last year or two I think?).

This is really about what software Xen wants to support though.  You
can say, "it would be easier for you to just support new software that
doesn't use MTRRs," and you might be right, but supporting older stuff
doesn't appear that difficult, and it sounds like something they want
to do.

-- 
Jesse Barnes, Intel Open Source Technology Center

  reply	other threads:[~2009-05-16 18:22 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-12 23:27 Jeremy Fitzhardinge
2009-05-12 23:27 ` [PATCH 1/6] xen: set cpu_callout_mask to make mtrr work Jeremy Fitzhardinge
2009-05-12 23:27 ` [PATCH 2/6] xen mtrr: Use specific cpu_has_foo macros instead of generic cpu_has() Jeremy Fitzhardinge
2009-05-12 23:27 ` [PATCH 3/6] xen mtrr: Use generic_validate_add_page() Jeremy Fitzhardinge
2009-05-12 23:27 ` [PATCH 4/6] xen mtrr: Implement xen_get_free_region() Jeremy Fitzhardinge
2009-05-12 23:27 ` [PATCH 5/6] xen mtrr: Add xen_{get,set}_mtrr() implementations Jeremy Fitzhardinge
2009-05-12 23:27 ` [PATCH 6/6] xen mtrr: Kill some unnecessary includes Jeremy Fitzhardinge
2009-05-13 13:30 ` [GIT PULL] xen /proc/mtrr implementation Ingo Molnar
2009-05-13 14:39   ` Jeremy Fitzhardinge
2009-05-15 18:27     ` Ingo Molnar
2009-05-15 20:09       ` Jeremy Fitzhardinge
2009-05-15 23:26         ` Eric W. Biederman
2009-05-15 23:49           ` Jeremy Fitzhardinge
2009-05-16  3:22             ` Jesse Barnes
2009-05-16  4:26               ` Eric W. Biederman
2009-05-16 18:22                 ` Jesse Barnes [this message]
2009-05-18  5:02                   ` Jeremy Fitzhardinge
2009-05-18  4:57                 ` Jeremy Fitzhardinge
2009-05-18  8:59                   ` Ingo Molnar
2009-05-18 13:17                     ` [Xen-devel] " Jan Beulich
2009-05-18 17:51                     ` Chris Wright
2009-05-18 18:07                     ` Jeremy Fitzhardinge
2009-05-19  9:59                       ` Ingo Molnar
2009-05-19 10:22                         ` [Xen-devel] " Jan Beulich
2009-05-19 11:08                           ` Ingo Molnar
2009-05-19 12:04                             ` Gerd Hoffmann
2009-05-19 12:26                               ` Ingo Molnar
2009-05-19 12:32                                 ` Alan Cox
2009-05-19 12:37                                   ` Ingo Molnar
2009-05-19 13:21                                 ` Gerd Hoffmann
2009-05-19 13:31                                   ` Ingo Molnar
2009-05-19 13:51                                     ` Gerd Hoffmann
2009-05-19 14:17                                       ` Ingo Molnar
2009-05-19 14:55                                         ` Gerd Hoffmann
2009-05-19 15:24                                           ` Ingo Molnar
2009-05-20  8:01                                             ` Gerd Hoffmann
2009-05-20 16:35                             ` Jeremy Fitzhardinge
2009-05-20 16:12                         ` Jeremy Fitzhardinge
2009-05-20  8:16                       ` Andi Kleen
2009-05-20 16:39                         ` Jeremy Fitzhardinge
2009-05-20 22:52                           ` Andi Kleen
2009-05-20 22:49                             ` Jeremy Fitzhardinge
2009-05-20 23:03                             ` H. Peter Anvin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090516112233.5cb085c8@jbarnes-g45 \
    --to=jbarnes@virtuousgeek.org \
    --cc=ebiederm@xmission.com \
    --cc=jeremy@goop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=x86@kernel.org \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®