public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Ingo Molnar <mingo@elte.hu>, Thomas Gleixner <tglx@linutronix.de>,
	"H. Peter Anvin" <hpa@zytor.com>,
	"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 10:13:31 -0700	[thread overview]
Message-ID: <4CA2223B.9040400@goop.org> (raw)
In-Reply-To: <alpine.DEB.2.00.1009281455300.2864@kaball-desktop>

 On 09/28/2010 07:00 AM, Stefano Stabellini wrote:
> On Tue, 28 Sep 2010, Ingo Molnar wrote:
>> * stefano.stabellini@eu.citrix.com <stefano.stabellini@eu.citrix.com> wrote:
>>
>>> From: Stephen Tweedie <sct@redhat.com>
>>>
>>> Add a Xen mtrr type, and reorganise mtrr initialisation slightly to
>>> allow the mtrr driver to set up num_var_ranges (Xen needs to do this by
>>> querying the hypervisor itself.)
>>>
>>> [ Impact: add basic MTRR support ]
>>>
>>> Signed-off-by: Stephen Tweedie <sct@redhat.com>
>>> Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
>>> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>>> ---
>>>  arch/x86/kernel/cpu/mtrr/Makefile |    2 +-
>>>  arch/x86/kernel/cpu/mtrr/main.c   |    3 +
>>>  arch/x86/kernel/cpu/mtrr/mtrr.h   |    7 ++
>>>  arch/x86/kernel/cpu/mtrr/xen.c    |  110 +++++++++++++++++++++++++++++++++++++
>>>  4 files changed, 121 insertions(+), 1 deletions(-)
>>>  create mode 100644 arch/x86/kernel/cpu/mtrr/xen.c
>> Still NAK, for the very same reasons as we NAK-ed it the previous time: 
>> /proc/mtrr is a problematic and complicated legacy interface that should 
>> die. Any modern X server will do the right thing via PAT.
>>
> Sorry I should have read the original thread more carefully: I didn't
> realize this patch had been NAK-ed.
>
> However it is not a problem because we can easily disable MTRRs from Xen
> and with no cpu_has_mtrr the kernel would still boot fine on Xen.
> Also I think we do have PAT support nowadays but I'll let Jeremy comment
> on that.

Yes, we could just mask out the MTRR CPU feature and rely entirely on PAT.

The alternative would be to use the wrmsr hooks to emulate the Intel
MTRR registers by mapping them to hypercalls, but that seems needlessly
complex.

    J

  reply	other threads:[~2010-09-28 17:13 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 [this message]
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
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=4CA2223B.9040400@goop.org \
    --to=jeremy@goop.org \
    --cc=Jeremy.Fitzhardinge@citrix.com \
    --cc=hpa@zytor.com \
    --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