xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: "Tim Deegan" <tim@xen.org>,
	"George Dunlap" <george.dunlap@citrix.com>,
	"Andrew Cooper" <andrew.cooper3@citrix.com>,
	"Wei Liu" <wl@xen.org>, "Roger Pau Monné" <roger.pau@citrix.com>,
	"Ian Jackson" <iwj@xenproject.org>
Subject: [PATCH 1/2][4.15?] x86/shadow: suppress "fast fault path" optimization when running virtualized
Date: Fri, 5 Mar 2021 16:37:04 +0100	[thread overview]
Message-ID: <3bb90ab6-22c9-31d4-88a2-39bd3d81c2d7@suse.com> (raw)
In-Reply-To: <d0190313-921f-7cbc-4659-9a79f6299fab@suse.com>

We can't make correctness of our own behavior dependent upon a
hypervisor underneath us correctly telling us the true physical address
with hardware uses. Without knowing this, we can't be certain reserved
bit faults can actually be observed. Therefore, besides evaluating the
number of address bits when deciding whether to use the optimization,
also check whether we're running virtualized ourselves.

Requested-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/mm/shadow/types.h
+++ b/xen/arch/x86/mm/shadow/types.h
@@ -282,10 +282,16 @@ shadow_put_page_from_l1e(shadow_l1e_t sl
  *
  * This is only feasible for PAE and 64bit Xen: 32-bit non-PAE PTEs don't
  * have reserved bits that we can use for this.  And even there it can only
- * be used if the processor doesn't use all 52 address bits.
+ * be used if we can be certain the processor doesn't use all 52 address bits.
  */
 
 #define SH_L1E_MAGIC 0xffffffff00000001ULL
+
+static inline bool sh_have_pte_rsvd_bits(void)
+{
+    return paddr_bits < PADDR_BITS && !cpu_has_hypervisor;
+}
+
 static inline bool sh_l1e_is_magic(shadow_l1e_t sl1e)
 {
     return (sl1e.l1 & SH_L1E_MAGIC) == SH_L1E_MAGIC;
@@ -303,7 +309,7 @@ static inline shadow_l1e_t sh_l1e_gnp(vo
      * On systems with no reserved physical address bits we can't engage the
      * fast fault path.
      */
-    return paddr_bits < PADDR_BITS ? sh_l1e_gnp_raw()
+    return sh_have_pte_rsvd_bits() ? sh_l1e_gnp_raw()
                                    : shadow_l1e_empty();
 }
 
@@ -326,7 +332,7 @@ static inline shadow_l1e_t sh_l1e_mmio(g
 {
     unsigned long gfn_val = MASK_INSR(gfn_x(gfn), SH_L1E_MMIO_GFN_MASK);
 
-    if ( paddr_bits >= PADDR_BITS ||
+    if ( !sh_have_pte_rsvd_bits() ||
          gfn_x(gfn) != MASK_EXTR(gfn_val, SH_L1E_MMIO_GFN_MASK) )
         return shadow_l1e_empty();
 



  reply	other threads:[~2021-03-05 15:37 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-05 15:36 [PATCH 0/2][4.15?] x86/shadow: further refinements to "fast fault path" suppression Jan Beulich
2021-03-05 15:37 ` Jan Beulich [this message]
2021-03-05 15:47   ` [PATCH 1/2][4.15?] x86/shadow: suppress "fast fault path" optimization when running virtualized Andrew Cooper
2021-03-05 16:32     ` Jan Beulich
2021-03-05 16:40     ` Ian Jackson
2021-03-05 16:47       ` Andrew Cooper
2021-03-05 16:58         ` Ian Jackson
2021-03-08  9:25   ` Tim Deegan
2021-03-08  9:40     ` Jan Beulich
2021-03-08 13:47     ` Andrew Cooper
2021-03-08 13:51       ` Jan Beulich
2021-03-08 13:59         ` Andrew Cooper
2021-03-08 14:29           ` Jan Beulich
2021-03-08 14:47             ` Andrew Cooper
2021-03-05 15:37 ` [PATCH 2/2][4.15?] x86/shadow: encode full GFN in magic MMIO entries Jan Beulich
2021-03-05 16:32   ` Andrew Cooper
2021-03-08 12:42     ` Jan Beulich
2021-03-08  9:39   ` Tim Deegan
2021-03-08 12:05     ` 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=3bb90ab6-22c9-31d4-88a2-39bd3d81c2d7@suse.com \
    --to=jbeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=george.dunlap@citrix.com \
    --cc=iwj@xenproject.org \
    --cc=roger.pau@citrix.com \
    --cc=tim@xen.org \
    --cc=wl@xen.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).