From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: stefan.bader@canonical.com, david.vrabel@citrix.com,
xen-devel <xen-devel@lists.xenproject.org>,
Boris Ostrovsky <boris.ostrovsky@oracle.com>,
chuck.anderson@oracle.com, Juergen Gross <JGross@suse.com>,
linux-kernel@vger.kernel.org
Subject: Re: XSA 154 and ISA region (640K -> 1MB) WB cache instead of UC
Date: Fri, 19 Aug 2016 10:52:00 -0400 [thread overview]
Message-ID: <20160819145200.GB26577@char.us.oracle.com> (raw)
In-Reply-To: <57B5A4C90200007800106FF2@prv-mh.provo.novell.com>
On Thu, Aug 18, 2016 at 04:06:33AM -0600, Jan Beulich wrote:
> >>> On 17.08.16 at 22:32, <konrad.wilk@oracle.com> wrote:
> > One of the interesting things about XSA 154 fix ("x86: enforce consistent
> > cachability of MMIO mappings") is that when certain applications (mcelog)
> > are trying to map /dev/mmap and lurk in ISA regions - we get:
>
> DYM /dev/mem ? Most accesses to which are bogus in PV guests
> (often including Dom0) anyway.
Yes.
>
> > [ 49.399053] WARNING: CPU: 0 PID: 2471 at arch/x86/mm/pat.c:913 untrack_pfn+0x93/0xc0()
>
> What Linux version is this? untrack_pfn() doesn't span line 913 in
4.1
> 4.8-rc2. And follow_phys() appears to only check whether the write
> flag is set as expected; I can't see any cachability checks. Plus it
> gets called only when both incoming address and size are zero.
The error that happens is much sooner - that is when the VMA is setup
with the incorrect page attributes. Specifically: reserve_memtype which
548 /* Low ISA region is always mapped WB in page table. No need to track */
549 if (x86_platform.is_untracked_pat_range(start, end)) {
550 if (new_type)
551 *new_type = _PAGE_CACHE_MODE_WB;
552 return 0;
553 }
(And this for a change is v4.8-rc2)
>
> > Anyhow what I am wondering:
> >
> > a) Should we add a edge case in the hypervisor to allow multiple mappings
> > for this region? I am thinking no.. but it sounds like mapping ISA region
> > as WB is safe even in baremetal?
>
> We should never allow multiple mappings with different cachability.
> And I don't understand what makes you think the ISA region is safe
> to map WB? There might be ROMs, MMIO regions, or simply nothing
> there, neither of which is safe to map WB. ROMs certainly could be
> WP, but that would require a way to reliably size not only ISA
> extension ROMs, but also main and video BIOS.
>
> > b) Or would it be better to let Linux do its thing and treat 640KB->1MB
> > as uncached instead of writeback?
>
> According to what you wrote earlier the two parts of the sentence
> read contradictory to me.
>
> > Looking at the kernel it assumes that WB is ok for 640KB->1MB.
> > The comment says:
> > " /* Low ISA region is always mapped WB in page table. No need to track *"
>
> As per above it's not clear to me what this comment is backed by.
I was hoping you would know :-)
Ah, commit 2e5d9c857d4e6c9e7b7d8c8c86a68a7842d213d6
Author: venkatesh.pallipadi@intel.com <venkatesh.pallipadi@intel.com>
Date: Tue Mar 18 17:00:14 2008 -0700
x86: PAT infrastructure patch
Sets up pat_init() infrastructure.
which sets the MTRR for that region.
>
> Jan
>
next prev parent reply other threads:[~2016-08-19 14:53 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-17 20:32 XSA 154 and ISA region (640K -> 1MB) WB cache instead of UC Konrad Rzeszutek Wilk
2016-08-18 10:06 ` Jan Beulich
2016-08-18 10:16 ` [Xen-devel] " Andrew Cooper
2016-08-18 11:12 ` Jan Beulich
2016-08-18 15:35 ` One Thousand Gnomes
2016-08-19 15:27 ` Konrad Rzeszutek Wilk
2016-08-19 14:52 ` Konrad Rzeszutek Wilk [this message]
2016-08-19 15:14 ` 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=20160819145200.GB26577@char.us.oracle.com \
--to=konrad.wilk@oracle.com \
--cc=JBeulich@suse.com \
--cc=JGross@suse.com \
--cc=boris.ostrovsky@oracle.com \
--cc=chuck.anderson@oracle.com \
--cc=david.vrabel@citrix.com \
--cc=linux-kernel@vger.kernel.org \
--cc=stefan.bader@canonical.com \
--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