Hi Roger,
> -----Original Message-----
> From: Roger Pau Monne <roger....@citrix.com>
> Subject: [PATCH for-4.17 v3 1/2] amd/virt_ssbd: set SSBD at vCPU context
> switch
>
> The current logic for AMD SSBD context switches it on every
> vm{entry,exit} if the Xen and guest selections don't match. This is
> expensive when not using SPEC_CTRL, and hence should be avoided as
> much as possible.
>
> When SSBD is not being set from SPEC_CTRL on AMD don't context switch
> at vm{entry,exit} and instead only context switch SSBD when switching
> vCPUs. This has the side effect of running Xen code with the guest
> selection of SSBD, the documentation is updated to note this behavior.
> Also note that then when `ssbd` is selected on the command line guest
> SSBD selection will not have an effect, and the hypervisor will run
> with SSBD unconditionally enabled when not using SPEC_CTRL itself.
>
> This fixes an issue with running C code in a GIF=0 region, that's
> problematic when using UBSAN or other instrumentation techniques.
>
> As a result of no longer running the code to set SSBD in a GIF=0
> region the locking of amd_set_legacy_ssbd() can be done using normal
> spinlocks, and some more checks can be added to assure it works as
> intended.
>
> Finally it's also worth noticing that since the guest SSBD selection
> is no longer set on vmentry the VIRT_SPEC_MSR handling needs to
> propagate the value to the hardware as part of handling the wrmsr.
>
> Signed-off-by: Roger Pau Monné <roger....@citrix.com>
Thanks for respinning the patch!
Release-acked-by: Henry Wang <henry.w...@arm.com>
Kind regards,
Henry
