All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Vrabel <david.vrabel@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Cc: <xen-devel@lists.xenproject.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	<linux-kernel@vger.kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	<x86@kernel.org>, Mel Gorman <mgorman@suse.de>
Subject: Re: [PATCH 7/9] x86: skip check for spurious faults for non-present faults
Date: Wed, 30 Apr 2014 13:41:20 +0100	[thread overview]
Message-ID: <5360EF70.20202@citrix.com> (raw)
In-Reply-To: <1397571337-20409-8-git-send-email-david.vrabel@citrix.com>

On 15/04/14 15:15, David Vrabel wrote:
> If a fault on a kernel address is due to a non-present page, then it
> cannot be the result of stale TLB entry from a protection change (RO
> to RW or NX to X).  Thus the pagetable walk in spurious_fault() can be
> skipped.
> 
> This avoids spurious_fault() oopsing in some cases if the pagetables
> it attempts to walk are not accessible.  This obscures the location of
> the original fault.
> 
> This also fixes a crash with Xen PV guests when they access entries in
> the M2P corresponding to device MMIO regions.  The M2P is mapped
> (read-only) by Xen into the kernel address space of the guest and this
> mapping may contains holes for non-RAM regions.  Read faults will
> result in calls to spurious_fault(), but because the page tables for
> the M2P mappings are not accessible by the guest the pagetable walk
> would fault.
> 
> This was not normally a problem as MMIO mappings would not normally
> result in a M2P lookup because of the use of the _PAGE_IOMAP bit the
> PTE.  However, removing the _PAGE_IOMAP bit requires M2P lookups for
> MMIO mappings as well.
> 
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> Reported-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
> x86 maintainers, this is a prerequisite for removing Xen's usage of
> _PAGE_IOMAP so I think this is best merged via the Xen tree.

Peter, any opinion on this patch?

David

  reply	other threads:[~2014-04-30 12:41 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-15 14:15 [PATCHv6 0/9] x86/xen: fixes for mapping high MMIO regions (and remove _PAGE_IOMAP) David Vrabel
2014-04-15 14:15 ` [PATCH 1/9] x86/xen: rename early_p2m_alloc() and early_p2m_alloc_middle() David Vrabel
2014-04-15 14:15   ` David Vrabel
2014-04-15 14:15 ` [PATCH 2/9] x86/xen: fix set_phys_range_identity() if pfn_e > MAX_P2M_PFN David Vrabel
2014-04-15 14:15   ` David Vrabel
2014-04-15 14:15 ` [PATCH 3/9] x86/xen: compactly store large identity ranges in the p2m David Vrabel
2014-04-15 14:15   ` David Vrabel
2014-04-15 14:15 ` [PATCH 4/9] x86/xen: only warn once if bad MFNs are found during setup David Vrabel
2014-04-15 14:15 ` David Vrabel
2014-04-15 14:15 ` [PATCH 5/9] x86/xen: set regions above the end of RAM as 1:1 David Vrabel
2014-04-15 14:15 ` David Vrabel
2014-04-15 14:15 ` [PATCH 6/9] x86/xen: do not use _PAGE_IOMAP in xen_remap_domain_mfn_range() David Vrabel
2014-04-15 14:15   ` David Vrabel
2014-04-15 14:15 ` [PATCH 7/9] x86: skip check for spurious faults for non-present faults David Vrabel
2014-04-15 14:15   ` David Vrabel
2014-04-30 12:41   ` David Vrabel [this message]
2014-04-30 12:41   ` David Vrabel
2014-05-15 18:42   ` H. Peter Anvin
2014-05-15 19:22     ` [Xen-devel] " Keir Fraser
2014-05-15 19:51       ` H. Peter Anvin
2014-05-15 19:51       ` H. Peter Anvin
2014-05-15 19:22     ` Keir Fraser
2014-05-15 18:42   ` H. Peter Anvin
2014-04-15 14:15 ` [PATCH 8/9] x86/xen: do not use _PAGE_IOMAP PTE flag for I/O mappings David Vrabel
2014-04-15 14:15   ` David Vrabel
2014-04-15 14:15 ` [PATCH 9/9] x86: remove the Xen-specific _PAGE_IOMAP PTE flag David Vrabel
2014-04-15 14:15   ` David Vrabel
2014-05-15 15:30 ` [PATCHv6 0/9] x86/xen: fixes for mapping high MMIO regions (and remove _PAGE_IOMAP) David Vrabel
2014-05-15 15:30 ` David Vrabel

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=5360EF70.20202@citrix.com \
    --to=david.vrabel@citrix.com \
    --cc=boris.ostrovsky@oracle.com \
    --cc=hpa@zytor.com \
    --cc=konrad.wilk@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mgorman@suse.de \
    --cc=mingo@redhat.com \
    --cc=tglx@linutronix.de \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.