xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: "Luis R. Rodriguez" <mcgrof@kernel.org>
To: David Vrabel <david.vrabel@citrix.com>, Toshi Kani <toshi.kani@hp.com>
Cc: "Luis R. Rodriguez" <mcgrof@kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>, Juergen Gross <jgross@suse.com>,
	X86 ML <x86@kernel.org>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Stuart Hayes <stuart.w.hayes@gmail.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Andy Lutomirski <luto@amacapital.net>,
	Borislav Petkov <bp@alien8.de>, "H. Peter Anvin" <hpa@zytor.com>,
	Paul McKenney <paulmck@linux.vnet.ibm.com>,
	Yinghai Lu <yinghai@kernel.org>, Ingo Molnar <mingo@kernel.org>,
	Prarit Bhargava <prarit@redhat.com>
Subject: Re: [Xen-devel] MTRR on Xen - BIOS use and implications for Linux
Date: Tue, 29 Mar 2016 10:22:15 -0700	[thread overview]
Message-ID: <CAB=NE6WiTg00iyMvebj0OcCR+jBjD-e-Fg2AhWsvHG=YayLP_Q@mail.gmail.com> (raw)
In-Reply-To: <20160317185647.GR1990@wotan.suse.de>

On Thu, Mar 17, 2016 at 11:56 AM, Luis R. Rodriguez <mcgrof@kernel.org> wrote:
> On Thu, Mar 17, 2016 at 11:13:03AM +0000, David Vrabel wrote:
>> On 16/03/16 20:08, Luis R. Rodriguez wrote:
>> > Toshi noted a while ago as well that if BIOS/firmware enables MTRR but
>> > the kernel does not have it enabled one issue might have been any
>> > MTRRs set up by the BIOS and ensuring the mapping is respected,

To be clear the requirement expressed here was needing at least to
implement get_mtrr() on the Linux Xen guest side, it'd call the
already implemented hypercall XENPF_read_memtype in turn. Toshi had
hinted this was perhaps needed on the Linux Xen guest side given that
the BIOS may have set up MTRRs on its own, so we needed the guest to
be able to get the right type for a particular range. More on that
below

>> > in particular UC settings, this concern is raised above.

And the reason for this seems to have been because some BIOSes may
still use a UC MTRR, the BIOS can only use MTRR as the BIOS is in
virtual mode with page tables enabled. Toshi notes that the default
cache attribute is set by setting the MTRR default type MSR, I'm
poking to see if perhaps there is a strategy that can be used to
circumvent the need for actual complex MTRR code in BIOS / platform
code (Xen) (or bare metal) by matching the memory type with PAT's
default and still keep it compatible to enable a functional fan
control [0]

[0] http://lkml.kernel.org/r/CAB=NE6WP2YsVTwypLLGK6Y8KDiV3hxoLM6kvyifV776kUATKGg@mail.gmail.com

>> > Another issue
>> > though is that the kernel would be "unable to verify if a large page
>> > mapping is aligned with MTRRs" [3]
>>
>> This is not a relevant concern for Xen guests:   PV guests do not
>> support superpage mappings
>
> And only with superpage mappings would such things be an issue? Can you
> clarify why? Is there no plans to support this in the future? If the
> MTRRs will not be used, to be safe, why not just skip all of them from
> the e820 map and be done with it?

I still wonder why then just not skip the entire MTRR from the e820
map, specially if there are uncertainties from the above questions or
if we simply do not wish to mesh up Linux upstream MTRR code to
support a Linux guest type with *only* the requirement of get_mtrr()
-- that would seem really silly to do.

>> and HVM guests never see real MTRRs.
>
> Thanks, can you clarify why?
>
>   Luis

  Luis

  reply	other threads:[~2016-03-29 17:22 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-16 20:08 MTRR on Xen - BIOS use and implications for Linux Luis R. Rodriguez
2016-03-17 11:13 ` [Xen-devel] " David Vrabel
2016-03-17 18:56   ` Luis R. Rodriguez
2016-03-29 17:22     ` Luis R. Rodriguez [this message]
2016-03-29 22:14       ` Toshi Kani
2016-03-29 22:28         ` Luis R. Rodriguez

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='CAB=NE6WiTg00iyMvebj0OcCR+jBjD-e-Fg2AhWsvHG=YayLP_Q@mail.gmail.com' \
    --to=mcgrof@kernel.org \
    --cc=andrew.cooper3@citrix.com \
    --cc=bp@alien8.de \
    --cc=david.vrabel@citrix.com \
    --cc=hpa@zytor.com \
    --cc=jgross@suse.com \
    --cc=keir@xen.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=mingo@kernel.org \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=prarit@redhat.com \
    --cc=stuart.w.hayes@gmail.com \
    --cc=toshi.kani@hp.com \
    --cc=x86@kernel.org \
    --cc=xen-devel@lists.xensource.com \
    --cc=yinghai@kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).