Re: [PATCH 2/3] x86/amd: Enumeration for speculative features/hints

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 24/08/2021 16:15, Jan Beulich wrote:
> On 24.08.2021 15:26, Andrew Cooper wrote:
>> On 19/08/2021 15:47, Jan Beulich wrote:
>>> On 17.08.2021 16:30, Andrew Cooper wrote:
>>>> There is a step change in speculation protections between the Zen1 and Zen2
>>>> microarchitectures.
>>>>
>>>> Zen1 and older have no special support.  Control bits in non-architectural
>>>> MSRs are used to make lfence be dispatch-serialising (Spectre v1), and to
>>>> disable Memory Disambiguation (Speculative Store Bypass).  IBPB was
>>>> retrofitted in a microcode update, and software methods are required for
>>>> Spectre v2 protections.
>>>>
>>>> Because the bit controlling Memory Disambiguation is model specific,
>>>> hypervisors are expected to expose a MSR_VIRT_SPEC_CTRL interface which
>>>> abstracts the model specific details.
>>>>
>>>> Zen2 and later implement the MSR_SPEC_CTRL interface in hardware, and
>>>> virtualise the interface for HVM guests to use.  A number of hint bits are
>>>> specified too to help guide OS software to the most efficient mitigation
>>>> strategy.
>>>>
>>>> Zen3 introduced a new feature, Predictive Store Forwarding, along with a
>>>> control to disable it in sensitive code.
>>>>
>>>> Add CPUID and VMCB details for all the new functionality.
>>>>
>>>> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
>>> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
>>> with one suggestion:
>>>
>>>> --- a/tools/libs/light/libxl_cpuid.c
>>>> +++ b/tools/libs/light/libxl_cpuid.c
>>>> @@ -274,8 +274,18 @@ int libxl_cpuid_parse_config(libxl_cpuid_policy_list 
>>>> *cpuid, const char* str)
>>>>          {"rstr-fp-err-ptrs", 0x80000008, NA, CPUID_REG_EBX, 2, 1},
>>>>          {"wbnoinvd",     0x80000008, NA, CPUID_REG_EBX,  9,  1},
>>>>          {"ibpb",         0x80000008, NA, CPUID_REG_EBX, 12,  1},
>>>> +        {"ibrs",         0x80000008, NA, CPUID_REG_EBX, 14,  1},
>>>> +        {"amd-stibp",    0x80000008, NA, CPUID_REG_EBX, 15,  1},
>>>> +        {"ibrs-always",  0x80000008, NA, CPUID_REG_EBX, 16,  1},
>>>> +        {"stibp-always", 0x80000008, NA, CPUID_REG_EBX, 17,  1},
>>>> +        {"ibrs-fast",    0x80000008, NA, CPUID_REG_EBX, 18,  1},
>>>> +        {"ibrs-same-mode", 0x80000008, NA, CPUID_REG_EBX, 19,  1},
>>> Here and below, how about dropping the "mode" part of the name?
>>> I can't seem to be able to think of any other "same" that could
>>> possibly apply here.
>> ibrs-same is very ambiguous.
> I'm curious as to why you think so.

Same what?  There are load of plausible options, e.g. "privilege".

"mode" is the second most important piece of info, behind ibrs.

>
>>   The only other reasonable reasonable
>> alternative I can think of is ibrs-psmp as an abbreviation for
>> ProvideSameModeProtection.  Obviously, the "Provides" bit of that can't
>> be dropped.
> Then better stay with what you have I would say - for me "psmp"
> immediately raises the question "What strange kind of SMP?"
> While not tied to any formal naming, I could see "ibrs-sm" as
> an option ...

That's an initialisation of a shortening, and too far removed from the
original context IMO.

Given nothing better, I'll stick with ibrs-same-mode.

~Andrew