public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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
> 

  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