From: "H. Peter Anvin" <hpa@zytor.com>
To: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
Ingo Molnar <mingo@elte.hu>, Thomas Gleixner <tglx@linutronix.de>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
Jeremy Fitzhardinge <Jeremy.Fitzhardinge@citrix.com>,
"sct@redhat.com" <sct@redhat.com>
Subject: Re: [PATCH 12/12] xen/mtrr: Add mtrr_if support for Xen mtrr
Date: Tue, 28 Sep 2010 11:46:24 -0700 [thread overview]
Message-ID: <4CA23800.4020409@zytor.com> (raw)
In-Reply-To: <4CA232EF.3080906@goop.org>
On 09/28/2010 11:24 AM, Jeremy Fitzhardinge wrote:
>>>
>> No, and we really can't do it for a couple of reasons:
>>
>> a) Pre-PAT hardware;
>> b) MTRRs and PAT interact on hardware;
>> c) MTRRs, but not PAT, interact with SMM.
>
> What about pre-PAT software (ie, X servers which still use /proc/mtrr)?
>
Fortunately going away... we have talked in the past about doing
"virtual MTRRs" in terms of PAT to deal with this kind of legacy
software, but the demand for it seems to be low enough to not be worth
bothering with.
>> However, since a virtual machine like Xen doesn't have these issues, it
>> doesn't apply
>
> Well, we're specifically talking about a virtual machine which has
> direct access to hardware, so it is concerned about the real physical
> memory properties of real physical pages. If we can assume that
> BIOS/Xen will always set up MTRR correctly then there shouldn't be any
> need for the kernel to modify the MTRR itself. How true is that in
> general? I don't know, but if we could rely on BIOS then there'd never
> be a need to touch MTRR, would there?
Well, in the past MTRRs were abused for device properties mainly by the
X server, but other than that, no, not really. The other thing we do is
the MTRR cleanup (which doesn't involve /proc/mtrr) to deal with
brokenness in the BIOS setup, but that really belongs in the hypervisor
in your case since it fundamentally affects how memory is handled.
-hpa
next prev parent reply other threads:[~2010-09-28 18:47 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-28 12:16 [PATCH 00/12] xen: initial domain support Stefano Stabellini
2010-09-28 12:16 ` [PATCH 01/12] xen: remap GSIs as pirqs when running as initial domain stefano.stabellini
2010-09-28 12:16 ` [PATCH 02/12] xen: remap MSIs into " stefano.stabellini
2010-09-28 12:16 ` [PATCH 03/12] xen: map a dummy page for local apic and ioapic in xen_set_fixmap stefano.stabellini
2010-09-28 12:16 ` [PATCH 04/12] xen: use vcpu_ops to setup cpu masks stefano.stabellini
2010-09-28 12:16 ` [PATCH 05/12] xen: Initialize xenbus for dom0 stefano.stabellini
2010-09-28 12:16 ` [PATCH 06/12] xen: add the direct mapping area for ISA bus access stefano.stabellini
2010-09-28 12:16 ` [PATCH 07/12] xen: introduce XEN_DOM0 as a silent option stefano.stabellini
2010-09-28 12:16 ` [PATCH 08/12] xen: use host E820 map for dom0 stefano.stabellini
2010-09-28 12:16 ` [PATCH 09/12] xen: make hvc_xen console work " stefano.stabellini
2010-09-28 12:16 ` [PATCH 10/12] xen: add support for the platform_ops hypercall stefano.stabellini
2010-09-28 12:16 ` [PATCH 11/12] x86/mtrr: Extend mtrr_if to include num_var_ranges stefano.stabellini
2010-09-28 12:16 ` [PATCH 12/12] xen/mtrr: Add mtrr_if support for Xen mtrr stefano.stabellini
2010-09-28 12:39 ` Ingo Molnar
2010-09-28 14:00 ` Stefano Stabellini
2010-09-28 17:13 ` Jeremy Fitzhardinge
2010-09-28 17:19 ` Stefano Stabellini
2010-09-28 17:56 ` H. Peter Anvin
2010-09-28 18:13 ` Jeremy Fitzhardinge
2010-09-28 18:19 ` H. Peter Anvin
2010-09-28 18:24 ` Jeremy Fitzhardinge
2010-09-28 18:46 ` H. Peter Anvin [this message]
2010-09-28 18:58 ` Jeremy Fitzhardinge
2010-09-28 19:05 ` H. Peter Anvin
2010-09-28 17:14 ` Jeremy Fitzhardinge
-- strict thread matches above, loose matches on Subject: below --
2010-09-28 13:19 Sander Eikelenboom
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=4CA23800.4020409@zytor.com \
--to=hpa@zytor.com \
--cc=Jeremy.Fitzhardinge@citrix.com \
--cc=jeremy@goop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=sct@redhat.com \
--cc=stefano.stabellini@eu.citrix.com \
--cc=tglx@linutronix.de \
--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