| Message ID | 20220128132927.14997-2-andrew.cooper3@citrix.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | x86: MSR_SPEC_CTRL support for SVM guests | expand |
On 28.01.2022 14:29, Andrew Cooper wrote: > This is a statement of hardware behaviour, and not related to controls for the > guest kernel to use. Pass it straight through from hardware. > > Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
On Fri, Jan 28, 2022 at 01:29:19PM +0000, Andrew Cooper wrote: > This is a statement of hardware behaviour, and not related to controls for the > guest kernel to use. Pass it straight through from hardware. > Not really related to this patch per se, but I think we should expose AMD_SSBD unconditionally for SPEC_CTRL (and VIRT_SSBD for VIRT_SPEC_CTRL when supported) in the max policies and implement them as noop for compatibility reasons? I would expect CPUs exposing SSB_NO to drop AMD_SSBD and VIRT_SSBD at some point. Thanks, Roger.
On 31/01/2022 09:41, Roger Pau Monné wrote: > On Fri, Jan 28, 2022 at 01:29:19PM +0000, Andrew Cooper wrote: >> This is a statement of hardware behaviour, and not related to controls for the >> guest kernel to use. Pass it straight through from hardware. >> > Not really related to this patch per se, but I think we should expose > AMD_SSBD unconditionally for SPEC_CTRL (and VIRT_SSBD for > VIRT_SPEC_CTRL when supported) in the max policies and implement them > as noop for compatibility reasons? > > I would expect CPUs exposing SSB_NO to drop AMD_SSBD and VIRT_SSBD at > some point. Why? SSBD is an architectural feature. It's far more likely to turn into a no-op on SSB_NO hardware, than to disappear, especially as the MSR is exposed to guests. VIRT_SSBD is only offered by hypervisors, and should only be offered when there are members in the migration pool without MSR_SPEC_CTRL. ~Andrew
On Mon, Jan 31, 2022 at 11:15:09AM +0000, Andrew Cooper wrote: > On 31/01/2022 09:41, Roger Pau Monné wrote: > > On Fri, Jan 28, 2022 at 01:29:19PM +0000, Andrew Cooper wrote: > >> This is a statement of hardware behaviour, and not related to controls for the > >> guest kernel to use. Pass it straight through from hardware. > >> > > Not really related to this patch per se, but I think we should expose > > AMD_SSBD unconditionally for SPEC_CTRL (and VIRT_SSBD for > > VIRT_SPEC_CTRL when supported) in the max policies and implement them > > as noop for compatibility reasons? > > > > I would expect CPUs exposing SSB_NO to drop AMD_SSBD and VIRT_SSBD at > > some point. > > Why? SSBD is an architectural feature. It's far more likely to turn > into a no-op on SSB_NO hardware, than to disappear, especially as the > MSR is exposed to guests. > > VIRT_SSBD is only offered by hypervisors, and should only be offered > when there are members in the migration pool without MSR_SPEC_CTRL. But we should also offer VIRT_SSBD in the max policy if the hardware reports SSB_NO, because then it's a no-op and would allow for migration from boxes where we do offer VIRT_SSBD. Thanks, Roger.
diff --git a/xen/include/public/arch-x86/cpufeatureset.h b/xen/include/public/arch-x86/cpufeatureset.h index 6e44148a0901..fd8ab2572304 100644 --- a/xen/include/public/arch-x86/cpufeatureset.h +++ b/xen/include/public/arch-x86/cpufeatureset.h @@ -266,7 +266,7 @@ XEN_CPUFEATURE(NO_LMSL, 8*32+20) /*S EFER.LMSLE no longer supported. */ XEN_CPUFEATURE(AMD_PPIN, 8*32+23) /* Protected Processor Inventory Number */ XEN_CPUFEATURE(AMD_SSBD, 8*32+24) /* MSR_SPEC_CTRL.SSBD available */ XEN_CPUFEATURE(VIRT_SSBD, 8*32+25) /* MSR_VIRT_SPEC_CTRL.SSBD */ -XEN_CPUFEATURE(SSB_NO, 8*32+26) /* Hardware not vulnerable to SSB */ +XEN_CPUFEATURE(SSB_NO, 8*32+26) /*A Hardware not vulnerable to SSB */ XEN_CPUFEATURE(PSFD, 8*32+28) /* MSR_SPEC_CTRL.PSFD */ /* Intel-defined CPU features, CPUID level 0x00000007:0.edx, word 9 */
This is a statement of hardware behaviour, and not related to controls for the guest kernel to use. Pass it straight through from hardware. Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> --- CC: Jan Beulich <JBeulich@suse.com> CC: Roger Pau Monné <roger.pau@citrix.com> CC: Wei Liu <wl@xen.org> Not currently enumerated by any CPU I'm aware of. v2: * New --- xen/include/public/arch-x86/cpufeatureset.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)