[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH 2/3] x86/amd: Enumeration for speculative features/hints
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. > 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 ... Jan
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |