From: "H. Peter Anvin" <hpa@zytor.com>
To: David Vrabel <david.vrabel@citrix.com>, xen-devel@lists.xenproject.org
Cc: 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>,
x86@kernel.org, Mel Gorman <mgorman@suse.de>,
Dave Hansen <dave.hansen@intel.com>
Subject: Re: [PATCH 7/9] x86: skip check for spurious faults for non-present faults
Date: Thu, 15 May 2014 11:42:30 -0700 [thread overview]
Message-ID: <53750A96.2020201@zytor.com> (raw)
In-Reply-To: <1397571337-20409-8-git-send-email-david.vrabel@citrix.com>
On 04/15/2014 07:15 AM, 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.
Erk... this code is screaming WTF to me. The x86 architecture is such
that the CPU is responsible for avoiding these faults.
<dig> <dig> <dig>
5b727a3b0158a129827c21ce3bfb0ba997e8ddd0
x86: ignore spurious faults
When changing a kernel page from RO->RW, it's OK to leave stale TLB
entries around, since doing a global flush is expensive and they
pose no security problem. They can, however, generate a spurious
fault, which we should catch and simply return from (which will
have the side-effect of reloading the TLB to the current PTE).
This can occur when running under Xen, because it frequently changes
kernel pages from RW->RO->RW to implement Xen's pagetable semantics.
It could also occur when using CONFIG_DEBUG_PAGEALLOC, since it
avoids doing a global TLB flush after changing page permissions.
Signed-off-by: Jeremy Fitzhardinge <jeremy@xensource.com>
Cc: Harvey Harrison <harvey.harrison@gmail.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Again WTF?
Are we chasing hardware errata here? Or did someone go off and *assume*
that the x86 hardware architecture work a certain way? Or is there
something way more subtle going on?
I guess next step is mailing list archaeology...
Does anyone still have contacts with Jeremy, and if so, could they poke
him perhaps?
-hpa
next prev parent reply other threads:[~2014-05-15 18:43 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
2014-04-30 12:41 ` David Vrabel
2014-05-15 18:42 ` H. Peter Anvin
2014-05-15 18:42 ` H. Peter Anvin [this message]
2014-05-15 19:22 ` Keir Fraser
2014-05-15 19:22 ` [Xen-devel] " Keir Fraser
2014-05-15 19:51 ` H. Peter Anvin
2014-05-15 19:51 ` [Xen-devel] " 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=53750A96.2020201@zytor.com \
--to=hpa@zytor.com \
--cc=boris.ostrovsky@oracle.com \
--cc=dave.hansen@intel.com \
--cc=david.vrabel@citrix.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.