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 <[email protected]> >>> Reviewed-by: Jan Beulich <[email protected]> >>> 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
