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(-)

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 */
-- 
2.11.0

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