From: Toshi Kani <toshi.kani@hp.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Andy Lutomirski <luto@amacapital.net>,
"Luis R. Rodriguez" <mcgrof@do-not-panic.com>,
Bjorn Helgaas <bhelgaas@google.com>,
Jej B <James.Bottomley@hansenpartnership.com>,
X86 ML <x86@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
ville.syrjala@linux.intel.com,
Julia Lawall <julia.lawall@lip6.fr>,
xen-devel@lists.xenproject.org, Dave Airlie <airlied@redhat.com>,
syrjala@sci.fi, Juergen Gross <JGross@suse.com>,
Luis Rodriguez <Mcgrof@Suse.com>, Borislav Petkov <bp@suse.de>,
Tomi Valkeinen <tomi.valkeinen@ti.com>,
linux-fbdev <linux-fbdev@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
linux-media@vger.kernel.org,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>
Subject: Re: [Xen-devel] RIP MTRR - status update for upcoming v4.2
Date: Fri, 12 Jun 2015 10:58:26 -0600 [thread overview]
Message-ID: <1434128306.11808.97.camel@misato.fc.hp.com> (raw)
In-Reply-To: <557AAD910200007800084014@mail.emea.novell.com>
On Fri, 2015-06-12 at 08:59 +0100, Jan Beulich wrote:
> >>> On 12.06.15 at 01:23, <toshi.kani@hp.com> wrote:
> > There are two usages on MTRRs:
> > 1) MTRR entries set by firmware
> > 2) MTRR entries set by OS drivers
> >
> > We can obsolete 2), but we have no control over 1). As UEFI firmwares
> > also set this up, this usage will continue to stay. So, we should not
> > get rid of the MTRR code that looks up the MTRR entries, while we have
> > no need to modify them.
> >
> > Such MTRR entries provide safe guard to /dev/mem, which allows
> > privileged user to access a range that may require UC mapping while
> > the /dev/mem driver blindly maps it with WB. MTRRs converts WB to UC in
> > such a case.
>
> But it wouldn't be impossible to simply read the MTRRs upon boot,
> store the information, disable MTRRs, and correctly use PAT to
> achieve the same effect (i.e. the "blindly maps" part of course
> would need fixing).
It could be done, but I do not see much benefit of doing it. One of the
reasons platform vendors set MTRRs is so that a system won't hit a
machine check when an OS bug leads an access with a wrong cache type. A
machine check is hard to analyze and can be seen as a hardware issue by
customers. Emulating MTRRs with PAT won't protect from such a bug.
> > UEFI memory table has memory attribute, which describes cache types
> > supported in physical memory ranges. However, this information gets
> > lost when it it is converted to e820 table.
>
> I'm afraid you rather don't want to trust that information, as
> firmware vendors frequently screw it up.
Could be, but we need to use firmware info when necessary...
Thanks,
-Toshi
next prev parent reply other threads:[~2015-06-12 16:58 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-11 20:36 RIP MTRR - status update for upcoming v4.2 Luis R. Rodriguez
2015-06-11 23:23 ` Toshi Kani
2015-06-12 0:52 ` Luis R. Rodriguez
2015-06-12 16:42 ` Toshi Kani
2015-06-12 7:59 ` [Xen-devel] " Jan Beulich
2015-06-12 16:58 ` Toshi Kani [this message]
2015-08-06 19:53 ` Luis R. Rodriguez
2015-08-06 19:55 ` Luis R. Rodriguez
2015-08-06 22:58 ` Toshi Kani
2015-08-07 20:25 ` Luis R. Rodriguez
2015-08-07 21:56 ` Toshi Kani
2015-08-07 22:23 ` Luis R. Rodriguez
2015-08-07 23:08 ` Toshi Kani
2015-08-07 23:19 ` Toshi Kani
2015-08-07 23:26 ` Luis R. Rodriguez
2015-08-07 23:48 ` Toshi Kani
2015-06-12 23:15 ` Andy Lutomirski
2015-06-12 23:29 ` James Bottomley
2015-06-13 6:37 ` Ingo Molnar
2015-06-15 6:20 ` Jan Beulich
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=1434128306.11808.97.camel@misato.fc.hp.com \
--to=toshi.kani@hp.com \
--cc=JBeulich@suse.com \
--cc=JGross@suse.com \
--cc=James.Bottomley@hansenpartnership.com \
--cc=Mcgrof@Suse.com \
--cc=airlied@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=bhelgaas@google.com \
--cc=bp@suse.de \
--cc=julia.lawall@lip6.fr \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=mcgrof@do-not-panic.com \
--cc=syrjala@sci.fi \
--cc=tomi.valkeinen@ti.com \
--cc=ville.syrjala@linux.intel.com \
--cc=x86@kernel.org \
--cc=xen-devel@lists.xenproject.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).