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: "George Dunlap" <George.Dunlap@eu.citrix.com>,
	"Andrew Cooper" <andrew.cooper3@citrix.com>,
	"Wei Liu" <wl@xen.org>, "Roger Pau Monné" <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH v3 1/5] x86: suppress XPTI-related TLB flushes when possible
Date: Wed, 25 Sep 2019 17:23:11 +0200	[thread overview]
Message-ID: <ae47cb2c-2fff-cd08-0a26-683cef1f3303@suse.com> (raw)
In-Reply-To: <3ce4ab2c-8cb6-1482-6ce9-3d5b019e10c1@suse.com>

When there's no XPTI-enabled PV domain at all, there's no need to issue
respective TLB flushes. Hardwire opt_xpti_* to false when !PV, and
record the creation of PV domains by bumping opt_xpti_* accordingly.

As to the sticky opt_xpti_domu vs increment/decrement of opt_xpti_hwdom,
this is done this way to avoid
(a) widening the former variable,
(b) any risk of a missed flush, which would result in an XSA if a DomU
    was able to exercise it, and
(c) any races updating the variable.
Fundamentally the TLB flush done when context switching out the domain's
vCPU-s the last time before destroying the domain ought to be
sufficient, so in principle DomU handling could be made match hwdom's.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
v3: Re-base.
v2: Add comment to spec_ctrl.h. Explain difference in accounting of DomU
    and hwdom.
---
TBD: The hardwiring to false could be extended to opt_pv_l1tf_* and (for
     !HVM) opt_l1d_flush as well.

---
 xen/arch/x86/flushtlb.c         |    2 +-
 xen/arch/x86/pv/domain.c        |   14 +++++++++++++-
 xen/arch/x86/spec_ctrl.c        |    6 ++++++
 xen/include/asm-x86/spec_ctrl.h |   11 +++++++++++
 4 files changed, 31 insertions(+), 2 deletions(-)

--- a/xen/arch/x86/flushtlb.c
+++ b/xen/arch/x86/flushtlb.c
@@ -207,7 +207,7 @@ unsigned int flush_area_local(const void
                  */
                 invpcid_flush_one(PCID_PV_PRIV, addr);
                 invpcid_flush_one(PCID_PV_USER, addr);
-                if ( opt_xpti_hwdom || opt_xpti_domu )
+                if ( opt_xpti_hwdom > 1 || opt_xpti_domu > 1 )
                 {
                     invpcid_flush_one(PCID_PV_PRIV | PCID_PV_XPTI, addr);
                     invpcid_flush_one(PCID_PV_USER | PCID_PV_XPTI, addr);
--- a/xen/arch/x86/pv/domain.c
+++ b/xen/arch/x86/pv/domain.c
@@ -272,6 +272,9 @@ void pv_domain_destroy(struct domain *d)
     destroy_perdomain_mapping(d, GDT_LDT_VIRT_START,
                               GDT_LDT_MBYTES << (20 - PAGE_SHIFT));
 
+    opt_xpti_hwdom -= IS_ENABLED(CONFIG_LATE_HWDOM) &&
+                      !d->domain_id && opt_xpti_hwdom;
+
     XFREE(d->arch.pv.cpuidmasks);
 
     FREE_XENHEAP_PAGE(d->arch.pv.gdt_ldt_l1tab);
@@ -310,7 +313,16 @@ int pv_domain_initialise(struct domain *
     /* 64-bit PV guest by default. */
     d->arch.is_32bit_pv = d->arch.has_32bit_shinfo = 0;
 
-    d->arch.pv.xpti = is_hardware_domain(d) ? opt_xpti_hwdom : opt_xpti_domu;
+    if ( is_hardware_domain(d) && opt_xpti_hwdom )
+    {
+        d->arch.pv.xpti = true;
+        ++opt_xpti_hwdom;
+    }
+    if ( !is_hardware_domain(d) && opt_xpti_domu )
+    {
+        d->arch.pv.xpti = true;
+        opt_xpti_domu = 2;
+    }
 
     if ( !is_pv_32bit_domain(d) && use_invpcid && cpu_has_pcid )
         switch ( ACCESS_ONCE(opt_pcid) )
--- a/xen/arch/x86/spec_ctrl.c
+++ b/xen/arch/x86/spec_ctrl.c
@@ -85,10 +85,12 @@ static int __init parse_spec_ctrl(const
 
             opt_eager_fpu = 0;
 
+#ifdef CONFIG_PV
             if ( opt_xpti_hwdom < 0 )
                 opt_xpti_hwdom = 0;
             if ( opt_xpti_domu < 0 )
                 opt_xpti_domu = 0;
+#endif
 
             if ( opt_smt < 0 )
                 opt_smt = 1;
@@ -187,6 +189,7 @@ static int __init parse_spec_ctrl(const
 }
 custom_param("spec-ctrl", parse_spec_ctrl);
 
+#ifdef CONFIG_PV
 int8_t __read_mostly opt_xpti_hwdom = -1;
 int8_t __read_mostly opt_xpti_domu = -1;
 
@@ -253,6 +256,9 @@ static __init int parse_xpti(const char
     return rc;
 }
 custom_param("xpti", parse_xpti);
+#else /* !CONFIG_PV */
+# define xpti_init_default(caps) ((void)(caps))
+#endif /* CONFIG_PV */
 
 int8_t __read_mostly opt_pv_l1tf_hwdom = -1;
 int8_t __read_mostly opt_pv_l1tf_domu = -1;
--- a/xen/include/asm-x86/spec_ctrl.h
+++ b/xen/include/asm-x86/spec_ctrl.h
@@ -43,7 +43,18 @@ extern bool bsp_delay_spec_ctrl;
 extern uint8_t default_xen_spec_ctrl;
 extern uint8_t default_spec_ctrl_flags;
 
+#ifdef CONFIG_PV
+/*
+ * Values -1, 0, and 1 have the usual meaning of "not established yet",
+ * "disabled", and "enabled". Values larger than 1 indicate there's actually
+ * at least one such domain (or there has been). This way XPTI-specific TLB
+ * flushes can be avoided when no XPTI-enabled domain is/was active.
+ */
 extern int8_t opt_xpti_hwdom, opt_xpti_domu;
+#else
+# define opt_xpti_hwdom false
+# define opt_xpti_domu false
+#endif
 
 extern int8_t opt_pv_l1tf_hwdom, opt_pv_l1tf_domu;
 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

  reply	other threads:[~2019-09-25 15:23 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-25 15:19 [Xen-devel] [PATCH v3 0/5] (remaining) XSA-292 follow-up Jan Beulich
2019-09-25 15:23 ` Jan Beulich [this message]
2020-05-18 17:09   ` [PATCH v3 1/5] x86: suppress XPTI-related TLB flushes when possible Roger Pau Monné
2020-05-19  7:55     ` Jan Beulich
2020-05-19  9:15       ` Roger Pau Monné
2020-05-19  9:45         ` Jan Beulich
2020-05-22 11:00   ` Andrew Cooper
2020-05-22 11:13     ` Roger Pau Monné
2020-05-22 11:58       ` Andrew Cooper
2020-05-22 11:42     ` Jan Beulich
2019-09-25 15:23 ` [Xen-devel] [PATCH v3 2/5] x86/mm: honor opt_pcid also for 32-bit PV domains Jan Beulich
2020-05-22 11:40   ` Andrew Cooper
2019-09-25 15:25 ` [Xen-devel] [PATCH v3 3/5] x86/HVM: move NOFLUSH handling out of hvm_set_cr3() Jan Beulich
2020-05-22 10:40   ` Andrew Cooper
2019-09-25 15:25 ` [Xen-devel] [PATCH v3 4/5] x86/HVM: refuse CR3 loads with reserved (upper) bits set Jan Beulich
2019-09-25 15:26 ` [Xen-devel] [PATCH v3 5/5] x86/HVM: cosmetics to hvm_set_cr3() Jan Beulich
2020-04-28  7:59 ` Ping: [PATCH v3 0/5] (remaining) XSA-292 follow-up 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=ae47cb2c-2fff-cd08-0a26-683cef1f3303@suse.com \
    --to=jbeulich@suse.com \
    --cc=George.Dunlap@eu.citrix.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=roger.pau@citrix.com \
    --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).