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
