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 2/5] x86/mm: honor opt_pcid also for 32-bit PV domains
Date: Wed, 25 Sep 2019 17:23:45 +0200 [thread overview]
Message-ID: <74eb1e77-7445-92fa-25b1-ece1d6699eb9@suse.com> (raw)
In-Reply-To: <3ce4ab2c-8cb6-1482-6ce9-3d5b019e10c1@suse.com>
I can't see any technical or performance reason why we should treat
32-bit PV different from 64-bit PV in this regard.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
---
xen/arch/x86/pv/domain.c | 21 +++++++++++++++++++--
1 file changed, 19 insertions(+), 2 deletions(-)
--- a/xen/arch/x86/pv/domain.c
+++ b/xen/arch/x86/pv/domain.c
@@ -180,7 +180,24 @@ int switch_compat(struct domain *d)
d->arch.x87_fip_width = 4;
d->arch.pv.xpti = false;
- d->arch.pv.pcid = false;
+
+ if ( use_invpcid && cpu_has_pcid )
+ switch ( ACCESS_ONCE(opt_pcid) )
+ {
+ case PCID_OFF:
+ case PCID_XPTI:
+ d->arch.pv.pcid = false;
+ break;
+
+ case PCID_ALL:
+ case PCID_NOXPTI:
+ d->arch.pv.pcid = true;
+ break;
+
+ default:
+ ASSERT_UNREACHABLE();
+ break;
+ }
return 0;
@@ -324,7 +341,7 @@ int pv_domain_initialise(struct domain *
opt_xpti_domu = 2;
}
- if ( !is_pv_32bit_domain(d) && use_invpcid && cpu_has_pcid )
+ if ( use_invpcid && cpu_has_pcid )
switch ( ACCESS_ONCE(opt_pcid) )
{
case PCID_OFF:
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
next prev parent 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 ` [Xen-devel] [PATCH v3 1/5] x86: suppress XPTI-related TLB flushes when possible Jan Beulich
2020-05-18 17:09 ` 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 ` Jan Beulich [this message]
2020-05-22 11:40 ` [PATCH v3 2/5] x86/mm: honor opt_pcid also for 32-bit PV domains 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=74eb1e77-7445-92fa-25b1-ece1d6699eb9@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 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.