Re: [Xen-devel] [PATCH 4/9] x86/amd: Introduce CPUID/MSR definitions for per-vcpu SSBD support

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 03.12.18 at 17:18, <andrew.cooper3@xxxxxxxxxx> wrote:
> At the time of writing, the spec is available from:
> 
>   
> https://developer.amd.com/wp-content/resources/124441_AMD64_SpeculativeStoreB 
> ypassDisable_Whitepaper_final.pdf
> 
> Future hardware (Zen v2) is expect to have hardware MSR_SPEC_CTRL support,
> including SPEC_CTRL.SSBD, and with the expectation that this will be directly
> passed through to guests for performance.
> 
> On currently released hardware, the only mechanism available is the legacy
> LS_CFG option, and this is very expensive to use.  Furthermore, emulating
> MSR_SPEC_CTRL via interception is prohibitively expensive, as certain OSes use
> the write-discard flexibility to simplify their entry/exit logic.

With this, ...

> As an alternative, MSR_VIRT_SPEC_CTRL is specified as an architectural control
> (with semantics equivilent to MSR_SPEC_CTRL) which is provided by the
> hypervisor.  This abstracts away the model-specific details of the LS_CFG
> mechanism, which allows migration safety to be retained.

... how is this any less expensive, when it necessarily requires
interception? At least the way things are worded, I'm getting
the impression that you consider this less expensive.

> --- a/tools/libxl/libxl_cpuid.c
> +++ b/tools/libxl/libxl_cpuid.c
> @@ -245,6 +245,11 @@ int libxl_cpuid_parse_config(libxl_cpuid_policy_list 
> *cpuid, const char* str)
>          {"invtsc",       0x80000007, NA, CPUID_REG_EDX,  8,  1},
>  
>          {"ibpb",         0x80000008, NA, CPUID_REG_EBX, 12,  1},
> +        {"amd_ibrs",     0x80000008, NA, CPUID_REG_EBX, 14,  1},

While of the following two the names indeed clash with Intel's, the
above one doesn't. Any reason you still gave it an amd_ prefix?

> +        {"amd_stibp",    0x80000008, NA, CPUID_REG_EBX, 15,  1},
> +        {"amd_ssbd",     0x80000008, NA, CPUID_REG_EBX, 24,  1},
> +        {"virt_sc_ssbd", 0x80000008, NA, CPUID_REG_EBX, 25,  1},
> +        {"amd_ssb_no",   0x80000008, NA, CPUID_REG_EBX, 26,  1},

Since you're at it, why not also introduce names for bits 16-18
at this occasion?

> --- a/tools/misc/xen-cpuid.c
> +++ b/tools/misc/xen-cpuid.c
> @@ -140,6 +140,10 @@ static const char *str_e8b[32] =
>      [ 0] = "clzero",
>  
>      [12] = "ibpb",
> +    [14] = "amd_ibrs",      [15] = "amd_stibp",
> +
> +    [24] = "amd_ssbd",      [25] = "virt_sc_ssbd",
> +    [26] = "amd_ssb_no",

Same comments here.

> --- a/xen/include/public/arch-x86/cpufeatureset.h
> +++ b/xen/include/public/arch-x86/cpufeatureset.h
> @@ -238,6 +238,11 @@ XEN_CPUFEATURE(EFRO,          7*32+10) /*   APERF/MPERF 
> Read Only interface */
>  /* AMD-defined CPU features, CPUID level 0x80000008.ebx, word 8 */
>  XEN_CPUFEATURE(CLZERO,        8*32+ 0) /*A  CLZERO instruction */
>  XEN_CPUFEATURE(IBPB,          8*32+12) /*A  IBPB support only (no IBRS, used 
> by AMD) */
> +XEN_CPUFEATURE(AMD_IBRS,      8*32+14) /*   MSR_SPEC_CTRL.IBRS available */
> +XEN_CPUFEATURE(AMD_STIBP,     8*32+15) /*   MSR_SPEC_CTRL.STIBP available */
> +XEN_CPUFEATURE(AMD_SSBD,      8*32+24) /*   MSR_SPEC_CTRL.SSBD available */
> +XEN_CPUFEATURE(VIRT_SC_SSBD,  8*32+25) /*   MSR_VIRT_SPEC_CTRL.SSBD 
> available. */
> +XEN_CPUFEATURE(AMD_SSB_NO,    8*32+26) /*   Hardware not vulnerable to SSB */

And here.

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel