On Wed, Oct 12, 2022 at 10:30:45AM +0200, Jan Beulich wrote:
> On 11.10.2022 18:02, Roger Pau Monne wrote:
> > @@ -2365,12 +2365,6 @@ On hardware supporting STIBP (Single Thread Indirect
> > Branch Predictors), the
> > By default, Xen will use STIBP when IBRS is in use (IBRS implies STIBP),
> > and
> > when hardware hints recommend using it as a blanket setting.
> >
> > -On hardware supporting SSBD (Speculative Store Bypass Disable), the `ssbd=`
> > -option can be used to force or prevent Xen using the feature itself.
>
> Why would we want to take away this level of control? Shouldn't we turn this
> on while in Xen if so requested? Which would then either mean enabling it on
> VMEXIT if a guest has it off, or running with it turned on using the OR of
> guest and host settings.
Right, but then we need to context switch the value on vm{entry,exit}
which is problematic. I could move the context switch code code out
of the GIF=0 region, and assume that NMIs executing with the guest
selection of SSBD are OK.
Alternatively setting ssbd= on the command line could be taken as a
value to enforce for the whole system and prevent guest attempts to
change it, not exposing VIRT_SSBD, AMD_SSBD or SSBD (haven't
looked at whether not exposing the SSBD CPUID related to
SPEC_CTRL.SSBD will have impact on other features).
I was under the impression that the command line ssbd option was added
to cope with Xen not exposing the feature to guests. Now that the
feature is exposed guests should be free to make use of it, and hence
there's no need to force a value for Xen.
Thanks, Roger.
