From: Jeremy Fitzhardinge <jeremy@goop.org>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Jesse Barnes <jbarnes@virtuousgeek.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: Sun, 17 May 2009 21:57:40 -0700 [thread overview]
Message-ID: <4A10EAC4.9070701@goop.org> (raw)
In-Reply-To: <m1iqk1k708.fsf@fess.ebiederm.org>
Eric W. Biederman wrote:
> There are only 3 states that are interesting. WB UC and WC. Since
> Xen controls the page tables anyway. I expect it can even remap
> it feels like it.
>
It would be awkward. A paravirtualized guest has direct access to the
real pagetables, and so would notice if Xen swizzled around the PAT bits
when it reads back a pagetable entry. We don't currently have any
paravirtualized hooks for adjusting the PTE flags, because there hasn't
been any need, and it would probably be pretty costly (lots of
read+bit-tests would turn into a function call). On the other hand,
there's probably only a few places (if any) in the kernel which actually
inspect the PAT status of an established PTE, so we could put in some
special case mapping there. It becomes a maintenance burden to 1) track
down all the right places, and then 2) make sure any new instances get
handled properly. So, not a preferred solution, I think.
But our planned approach is to simply make Xen use the same PAT layout
as Linux, and go from there. We still need to sort out the details of
how to handle other Xen guests which use the existing Xen PAT setup, how
to verify that Xen and the guest kernel are really using the same setup,
etc.
But since we support the last few year's worth of released versions of
Xen, we still need to handle the PAT-not-supported case with reasonable
grace.
> I won't argue that having MTRRs when you can makes sense. It is a bit
> weird in a vitalized system.
It's not really virtualized. We're talking about dom0, which is the
guest domain which has access to the real machine's real hardware; the
MTRR is part of that.
> 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.
>
Yes, but that is true irrespective of Xen.
J
WARNING: multiple messages have this Message-ID (diff)
From: Jeremy Fitzhardinge <jeremy@goop.org>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Xen-devel <xen-devel@lists.xensource.com>,
Ingo Molnar <mingo@elte.hu>,
the arch/x86 maintainers <x86@kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Jesse Barnes <jbarnes@virtuousgeek.org>
Subject: Re: [GIT PULL] xen /proc/mtrr implementation
Date: Sun, 17 May 2009 21:57:40 -0700 [thread overview]
Message-ID: <4A10EAC4.9070701@goop.org> (raw)
In-Reply-To: <m1iqk1k708.fsf@fess.ebiederm.org>
Eric W. Biederman wrote:
> There are only 3 states that are interesting. WB UC and WC. Since
> Xen controls the page tables anyway. I expect it can even remap
> it feels like it.
>
It would be awkward. A paravirtualized guest has direct access to the
real pagetables, and so would notice if Xen swizzled around the PAT bits
when it reads back a pagetable entry. We don't currently have any
paravirtualized hooks for adjusting the PTE flags, because there hasn't
been any need, and it would probably be pretty costly (lots of
read+bit-tests would turn into a function call). On the other hand,
there's probably only a few places (if any) in the kernel which actually
inspect the PAT status of an established PTE, so we could put in some
special case mapping there. It becomes a maintenance burden to 1) track
down all the right places, and then 2) make sure any new instances get
handled properly. So, not a preferred solution, I think.
But our planned approach is to simply make Xen use the same PAT layout
as Linux, and go from there. We still need to sort out the details of
how to handle other Xen guests which use the existing Xen PAT setup, how
to verify that Xen and the guest kernel are really using the same setup,
etc.
But since we support the last few year's worth of released versions of
Xen, we still need to handle the PAT-not-supported case with reasonable
grace.
> I won't argue that having MTRRs when you can makes sense. It is a bit
> weird in a vitalized system.
It's not really virtualized. We're talking about dom0, which is the
guest domain which has access to the real machine's real hardware; the
MTRR is part of that.
> 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.
>
Yes, but that is true irrespective of Xen.
J
next prev parent reply other threads:[~2009-05-18 4:57 UTC|newest]
Thread overview: 73+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-12 23:27 [GIT PULL] xen /proc/mtrr implementation 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 13:30 ` Ingo Molnar
2009-05-13 14:39 ` Jeremy Fitzhardinge
2009-05-13 14:39 ` Jeremy Fitzhardinge
2009-05-15 18:27 ` Ingo Molnar
2009-05-15 18:27 ` Ingo Molnar
2009-05-15 20:09 ` Jeremy Fitzhardinge
2009-05-15 20:09 ` Jeremy Fitzhardinge
2009-05-15 23:26 ` Eric W. Biederman
2009-05-15 23:49 ` Jeremy Fitzhardinge
2009-05-15 23:49 ` Jeremy Fitzhardinge
2009-05-16 3:22 ` Jesse Barnes
2009-05-16 3:22 ` Jesse Barnes
2009-05-16 4:26 ` Eric W. Biederman
2009-05-16 18:22 ` Jesse Barnes
2009-05-16 18:22 ` Jesse Barnes
2009-05-18 5:02 ` Jeremy Fitzhardinge
2009-05-18 5:02 ` Jeremy Fitzhardinge
2009-05-18 4:57 ` Jeremy Fitzhardinge [this message]
2009-05-18 4:57 ` Jeremy Fitzhardinge
2009-05-18 8:59 ` Ingo Molnar
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-18 18:07 ` Jeremy Fitzhardinge
2009-05-19 9:59 ` Ingo Molnar
2009-05-19 9:59 ` Ingo Molnar
2009-05-19 10:22 ` [Xen-devel] " Jan Beulich
2009-05-19 10:22 ` Jan Beulich
2009-05-19 11:08 ` [Xen-devel] " Ingo Molnar
2009-05-19 11:08 ` Ingo Molnar
2009-05-19 12:04 ` [Xen-devel] " Gerd Hoffmann
2009-05-19 12:04 ` Gerd Hoffmann
2009-05-19 12:26 ` [Xen-devel] " Ingo Molnar
2009-05-19 12:26 ` Ingo Molnar
2009-05-19 12:32 ` [Xen-devel] " Alan Cox
2009-05-19 12:32 ` Alan Cox
2009-05-19 12:37 ` [Xen-devel] " Ingo Molnar
2009-05-19 12:37 ` Ingo Molnar
2009-05-19 13:21 ` [Xen-devel] " Gerd Hoffmann
2009-05-19 13:21 ` Gerd Hoffmann
2009-05-19 13:31 ` [Xen-devel] " Ingo Molnar
2009-05-19 13:31 ` Ingo Molnar
2009-05-19 13:51 ` [Xen-devel] " Gerd Hoffmann
2009-05-19 13:51 ` Gerd Hoffmann
2009-05-19 14:17 ` [Xen-devel] " Ingo Molnar
2009-05-19 14:17 ` Ingo Molnar
2009-05-19 14:55 ` [Xen-devel] " Gerd Hoffmann
2009-05-19 14:55 ` Gerd Hoffmann
2009-05-19 15:24 ` [Xen-devel] " Ingo Molnar
2009-05-19 15:24 ` Ingo Molnar
2009-05-20 8:01 ` [Xen-devel] " Gerd Hoffmann
2009-05-20 8:01 ` Gerd Hoffmann
2009-05-20 16:35 ` [Xen-devel] " Jeremy Fitzhardinge
2009-05-20 16:35 ` Jeremy Fitzhardinge
2009-05-20 16:12 ` 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 16:39 ` Jeremy Fitzhardinge
2009-05-20 22:52 ` Andi Kleen
2009-05-20 22:49 ` Jeremy Fitzhardinge
2009-05-20 22:49 ` Jeremy Fitzhardinge
2009-05-20 23:03 ` H. Peter Anvin
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=4A10EAC4.9070701@goop.org \
--to=jeremy@goop.org \
--cc=ebiederm@xmission.com \
--cc=jbarnes@virtuousgeek.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.