From: "Woods, Brian" <Brian.Woods@amd.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: "Woods, Brian" <Brian.Woods@amd.com>,
"Roger Pau Monné" <roger.pau@citrix.com>,
"Wei Liu" <wei.liu2@citrix.com>,
"Jan Beulich" <JBeulich@suse.com>,
Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [PATCH 8/9] x86/amd: Virtualise MSR_VIRT_SPEC_CTRL for guests
Date: Tue, 4 Dec 2018 21:35:26 +0000 [thread overview]
Message-ID: <20181204213522.GG13738@amd.com> (raw)
In-Reply-To: <1543853902-6257-9-git-send-email-andrew.cooper3@citrix.com>
On Mon, Dec 03, 2018 at 04:18:21PM +0000, Andy Cooper wrote:
> The semantics of MSR_VIRT_SPEC_CTRL are that unknown bits are write-discard
> and read as zero. Only VIRT_SPEC_CTRL.SSBD is defined at the moment.
>
> To facilitate making this per-guest, the legacy SSBD state needs context
> switching between vcpus. amd_ctxt_switch_legacy_ssbd() is updated to take the
> vcpus setting into account. Furthermore, the guests chosen value needs
> preserving across migrate.
>
> This marks a subtle change in how `ssbd=` behaves. If Xen wishes SSBD to be
> asserted, it remains set in hardware all the time. In the default case of Xen
> wishing SSBD not to be asserted, the value set in hardware is the guests
> choice.
Ok, we talked about this some over IRC, but I thought it would be
better to get some more eyes on this on the mailing list.
From what some engineers have said over here, it takes roughly 400
clock cycles for enabling SSBD via LS_CFG. It isn't cheap, no, but if
the average VPCU time is 30ms, that's roughly .66%* overhead worst case
(non-turbo'd on the slowest freq processor at max speed [2GHz]).
The other thing I don't get is why advertise virtualized SSBD when the
guest setting it does nothing? If ssbd_opt=true is set, as the code is
now, why even advertise it to the guest? I'd suggest either allowing
the guest to turn it off or not advertise it at all (when ssbd_opt =
true).
* Twrmsr (in ms) = (400/2000000)*1000,
percent = (Twrmsr/30ms) * 100 = .66(repeating)%
--
Brian Woods
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
next prev parent reply other threads:[~2018-12-04 21:35 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-03 16:18 [PATCH 0/9] xen/amd: Support for guest MSR_VIRT_SPEC_CTRL support Andrew Cooper
2018-12-03 16:18 ` [PATCH 1/9] x86/spec-ctrl: Drop the bti= command line option Andrew Cooper
2018-12-04 16:19 ` Jan Beulich
2018-12-03 16:18 ` [PATCH 2/9] x86/cpuid: Drop the synthetic X86_FEATURE_XEN_IBPB Andrew Cooper
2018-12-04 16:21 ` Jan Beulich
2018-12-03 16:18 ` [PATCH 3/9] x86/cpuid: Extend the cpuid= command line option to support all named features Andrew Cooper
2018-12-04 16:28 ` Jan Beulich
2018-12-06 12:52 ` Wei Liu
2018-12-03 16:18 ` [PATCH 4/9] x86/amd: Introduce CPUID/MSR definitions for per-vcpu SSBD support Andrew Cooper
2018-12-04 16:06 ` Woods, Brian
2018-12-05 16:39 ` Jan Beulich
2018-12-05 17:50 ` Andrew Cooper
2018-12-06 8:49 ` Jan Beulich
2018-12-06 18:35 ` Andrew Cooper
2018-12-03 16:18 ` [PATCH 5/9] x86/amd: Probe for legacy SSBD interfaces on boot Andrew Cooper
2018-12-04 16:15 ` Woods, Brian
2018-12-05 16:50 ` Jan Beulich
2018-12-05 17:09 ` Andrew Cooper
2018-12-06 8:53 ` Jan Beulich
2018-12-06 10:59 ` Jan Beulich
2018-12-28 16:30 ` Andrew Cooper
2019-01-04 8:58 ` Jan Beulich
2018-12-03 16:18 ` [PATCH 6/9] x86/amd: Allocate resources to cope with LS_CFG being per-core on Fam17h Andrew Cooper
2018-12-04 16:38 ` Woods, Brian
2018-12-05 16:57 ` Jan Beulich
2018-12-05 17:05 ` Andrew Cooper
2018-12-06 8:54 ` Jan Beulich
2018-12-06 18:46 ` Andrew Cooper
2018-12-06 19:25 ` Woods, Brian
2018-12-07 10:17 ` Jan Beulich
2018-12-03 16:18 ` [PATCH 7/9] x86/amd: Support context switching legacy SSBD interface Andrew Cooper
2018-12-04 20:27 ` Woods, Brian
2018-12-06 10:51 ` Jan Beulich
2018-12-06 18:55 ` Andrew Cooper
2018-12-07 10:25 ` Jan Beulich
2018-12-03 16:18 ` [PATCH 8/9] x86/amd: Virtualise MSR_VIRT_SPEC_CTRL for guests Andrew Cooper
2018-12-04 21:35 ` Woods, Brian [this message]
2018-12-05 8:41 ` Jan Beulich
2018-12-05 19:09 ` Andrew Cooper
2018-12-06 8:59 ` Jan Beulich
2018-12-06 19:41 ` Woods, Brian
2018-12-06 10:55 ` Jan Beulich
2018-12-03 16:18 ` [PATCH 9/9] x86/amd: Offer MSR_VIRT_SPEC_CTRL to guests Andrew Cooper
2018-12-06 10:57 ` Jan Beulich
2018-12-03 16:24 ` [PATCH 0/9] xen/amd: Support for guest MSR_VIRT_SPEC_CTRL support Jan Beulich
2018-12-03 16:31 ` Andrew Cooper
2018-12-04 9:45 ` Jan Beulich
2018-12-04 11:26 ` Andrew Cooper
2018-12-04 12:45 ` Jan Beulich
2018-12-04 13:41 ` Andrew Cooper
2018-12-04 14:07 ` 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=20181204213522.GG13738@amd.com \
--to=brian.woods@amd.com \
--cc=JBeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=roger.pau@citrix.com \
--cc=wei.liu2@citrix.com \
--cc=xen-devel@lists.xen.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).