All of lore.kernel.org
 help / color / mirror / Atom feed
From: "H. Peter Anvin" <hpa@zytor.com>
To: Keir Fraser <keir.xen@gmail.com>
Cc: David Vrabel <david.vrabel@citrix.com>,
	xen-devel@lists.xenproject.org, x86@kernel.org,
	linux-kernel@vger.kernel.org, Dave Hansen <dave.hansen@intel.com>,
	Ingo Molnar <mingo@redhat.com>, Mel Gorman <mgorman@suse.de>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [Xen-devel] [PATCH 7/9] x86: skip check for spurious faults for non-present faults
Date: Thu, 15 May 2014 12:51:36 -0700	[thread overview]
Message-ID: <53751AC8.6040902@zytor.com> (raw)
In-Reply-To: <53751403.1010109@gmail.com>

On 05/15/2014 12:22 PM, Keir Fraser wrote:
>>
>> 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?
> 
> See Intel Developer's Manual Vol 3 Section 4.10.4.3, 3rd bullet... This
> is expected behaviour, probably to make copy-on-write faults faster.
> 

Hm, yes.  My memory of this comes from before these formal rules were
written down... I guess there is some wiggle room in there, presumably
as you say, for performance reasons (or implementation leeway, which is
another way to say performance.)

This does make a P bit switch architecturally different from W or NX, so
I'm okay with that, but I would like the patch adjusted in the following
ways:

1. Put in an explicit comment about the architectural difference
   between the P bit on one hand and an W and NX on the other; an SDM
   reference is good, and *why* this makes the specific filtering
   correct.

2. Please use the standard format for multiline comments;

	/*
         * blah
         * blah
         */

With that this should be okay.

	-hpa


  reply	other threads:[~2014-05-15 19:52 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
2014-05-15 19:22     ` [Xen-devel] " Keir Fraser
2014-05-15 19:51       ` H. Peter Anvin [this message]
2014-05-15 19:51       ` H. Peter Anvin
2014-05-15 19:22     ` Keir Fraser
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=53751AC8.6040902@zytor.com \
    --to=hpa@zytor.com \
    --cc=boris.ostrovsky@oracle.com \
    --cc=dave.hansen@intel.com \
    --cc=david.vrabel@citrix.com \
    --cc=keir.xen@gmail.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.