Re: Intended behavior/usage of SSBD setting

[Jan Beulich <jbeulich@suse.com>]

On 20.10.2022 13:01, Roger Pau Monné wrote:
> Hello,
> 
> As part of some follow up improvements to my VIRT_SPEC_CTRL series we
> have been discussing what the usage of SSBD should be for the
> hypervisor itself.  There's currently a `spec-ctrl=ssbd` option [0],
> that has an out of date description, as now SSBD is always offered to
> guests on AMD hardware, either using SPEC_CTRL or VIRT_SPEC_CTRL.
> 
> It has been pointed out by Andrew that toggling SSBD on AMD using
> VIRT_SPEC_CTRL or the non-architectural way (MSR_AMD64_LS_CFG) can
> have a high impact on performance, and hence switching it on every
> guest <-> hypervisor context switch is likely a very high
> performance penalty.
> 
> It's been suggested that it could be more appropriate to run Xen with
> the guest SSBD selection on those systems, however that clashes with
> the current intent of the `spec-ctrl=ssbd` option.
> 
> I hope I have captured the expressed opinions correctly in the text
> above.
> 
> I see two ways to solve this:
> 
>  * Keep the current logic for switching SSBD on guest <-> hypervisor
>    context switch, but only use it if `spec-ctrl=ssbd` is set on the
>    command line.
> 
>  * Remove the logic for switching SSBD on guest <-> hypervisor context
>    switch, ignore setting of `spec-ctrl=ssbd` on those systems and run
>    hypervisor code with the guest selection of SSBD.

* Give the guest the illusion of controlling the behavior, but run with
  SSBD always enabled when "spec-ctrl=ssbd" is in effect.

* Give the guest the illusion of controlling the behavior when
  "spec-ctrl=ssbd" is in effect, running with the OR of guest and host
  settings (switched, if necessary, as vCPU-s are context-switched).

Jan