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@citrix.com>
---
CC: Jan Beulich <JBeulich@suse.com>
CC: Roger Pau Monné <roger.pau@citrix.com>
CC: Wei Liu <wl@xen.org>
The current revision of the APM is buggy with the spec_ctrl VMCB field. It is
currently described as a dword, but a correction is pending to change it to
qword like every other MSR.
---
tools/libs/light/libxl_cpuid.c | 10 ++++++++++
tools/misc/xen-cpuid.c | 8 +++++++-
xen/arch/x86/hvm/svm/svm.c | 1 +
xen/arch/x86/hvm/svm/vmcb.c | 1 +
xen/include/asm-x86/cpufeature.h | 5 +++++
xen/include/asm-x86/hvm/svm/svm.h | 2 ++
xen/include/asm-x86/hvm/svm/vmcb.h | 4 +++-
xen/include/asm-x86/msr-index.h | 3 +++
xen/include/public/arch-x86/cpufeatureset.h | 10 ++++++++++
9 files changed, 42 insertions(+), 2 deletions(-)
diff --git a/tools/libs/light/libxl_cpuid.c b/tools/libs/light/libxl_cpuid.c
index b2c673841a45..5ed7a87180b8 100644
--- 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},
{"no-lmsl", 0x80000008, NA, CPUID_REG_EBX, 20, 1},
{"ppin", 0x80000008, NA, CPUID_REG_EBX, 23, 1},
+ {"amd-ssbd", 0x80000008, NA, CPUID_REG_EBX, 24, 1},
+ {"virt-ssbd", 0x80000008, NA, CPUID_REG_EBX, 25, 1},
+ {"ssb-no", 0x80000008, NA, CPUID_REG_EBX, 26, 1},
+ {"psfd", 0x80000008, NA, CPUID_REG_EBX, 28, 1},
{"nc", 0x80000008, NA, CPUID_REG_ECX, 0, 8},
{"apicidsize", 0x80000008, NA, CPUID_REG_ECX, 12, 4},
diff --git a/tools/misc/xen-cpuid.c b/tools/misc/xen-cpuid.c
index 735bcf8f0e60..713c1657f4df 100644
--- a/tools/misc/xen-cpuid.c
+++ b/tools/misc/xen-cpuid.c
@@ -148,12 +148,18 @@ static const char *const str_e8b[32] =
[ 0] = "clzero",
[ 2] = "rstr-fp-err-ptrs",
- /* [ 8] */ [ 9] = "wbnoinvd",
+ /* [ 8] */ [ 9] = "wbnoinvd",
[12] = "ibpb",
+ [14] = "ibrs", [15] = "amd-stibp",
+ [16] = "ibrs-always", [17] = "stibp-always",
+ [18] = "ibrs-fast", [19] = "ibrs-same-mode",
[20] = "no-lmsl",
/* [22] */ [23] = "ppin",
+ [24] = "amd-ssbd", [25] = "virt-ssbd",
+ [26] = "ssb-no",
+ [28] = "psfd",
};
static const char *const str_7d0[32] =
diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index 642a64b747ae..8dc92c8b9f96 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -1659,6 +1659,7 @@ const struct hvm_function_table * __init start_svm(void)
P(cpu_has_pause_thresh, "Pause-Intercept Filter Threshold");
P(cpu_has_tsc_ratio, "TSC Rate MSR");
P(cpu_has_svm_sss, "NPT Supervisor Shadow Stack");
+ P(cpu_has_svm_spec_ctrl, "MSR_SPEC_CTRL virtualisation");
#undef P
if ( !printed )
diff --git a/xen/arch/x86/hvm/svm/vmcb.c b/xen/arch/x86/hvm/svm/vmcb.c
index 373d5d4af47e..55da9302e5d7 100644
--- a/xen/arch/x86/hvm/svm/vmcb.c
+++ b/xen/arch/x86/hvm/svm/vmcb.c
@@ -271,6 +271,7 @@ static void __init __maybe_unused build_assertions(void)
BUILD_BUG_ON(offsetof(typeof(vmcb), rsp) != 0x5d8);
BUILD_BUG_ON(offsetof(typeof(vmcb), rax) != 0x5f8);
BUILD_BUG_ON(offsetof(typeof(vmcb), _g_pat) != 0x668);
+ BUILD_BUG_ON(offsetof(typeof(vmcb), spec_ctrl) != 0x6e0);
/* Check struct segment_register against the VMCB segment layout. */
BUILD_BUG_ON(sizeof(vmcb.es) != 16);
diff --git a/xen/include/asm-x86/cpufeature.h b/xen/include/asm-x86/cpufeature.h
index 5f6b83f71c21..d9604ff58a49 100644
--- a/xen/include/asm-x86/cpufeature.h
+++ b/xen/include/asm-x86/cpufeature.h
@@ -128,6 +128,11 @@
/* CPUID level 0x80000007.edx */
#define cpu_has_itsc boot_cpu_has(X86_FEATURE_ITSC)
+/* CPUID level 0x80000008.ebx */
+#define cpu_has_amd_ssbd boot_cpu_has(X86_FEATURE_AMD_SSBD)
+#define cpu_has_virt_ssbd boot_cpu_has(X86_FEATURE_VIRT_SSBD)
+#define cpu_has_ssb_no boot_cpu_has(X86_FEATURE_SSB_NO)
+
/* CPUID level 0x00000007:0.edx */
#define cpu_has_avx512_4vnniw boot_cpu_has(X86_FEATURE_AVX512_4VNNIW)
#define cpu_has_avx512_4fmaps boot_cpu_has(X86_FEATURE_AVX512_4FMAPS)
diff --git a/xen/include/asm-x86/hvm/svm/svm.h b/xen/include/asm-x86/hvm/svm/svm.h
index bee939156f4f..05e968502694 100644
--- a/xen/include/asm-x86/hvm/svm/svm.h
+++ b/xen/include/asm-x86/hvm/svm/svm.h
@@ -76,6 +76,7 @@ extern u32 svm_feature_flags;
#define SVM_FEATURE_VLOADSAVE 15 /* virtual vmload/vmsave */
#define SVM_FEATURE_VGIF 16 /* Virtual GIF */
#define SVM_FEATURE_SSS 19 /* NPT Supervisor Shadow Stacks */
+#define SVM_FEATURE_SPEC_CTRL 20 /* MSR_SPEC_CTRL virtualisation */
#define cpu_has_svm_feature(f) (svm_feature_flags & (1u << (f)))
#define cpu_has_svm_npt cpu_has_svm_feature(SVM_FEATURE_NPT)
@@ -91,6 +92,7 @@ extern u32 svm_feature_flags;
#define cpu_has_tsc_ratio cpu_has_svm_feature(SVM_FEATURE_TSCRATEMSR)
#define cpu_has_svm_vloadsave cpu_has_svm_feature(SVM_FEATURE_VLOADSAVE)
#define cpu_has_svm_sss cpu_has_svm_feature(SVM_FEATURE_SSS)
+#define cpu_has_svm_spec_ctrl cpu_has_svm_feature(SVM_FEATURE_SPEC_CTRL)
#define SVM_PAUSEFILTER_INIT 4000
#define SVM_PAUSETHRESH_INIT 1000
diff --git a/xen/include/asm-x86/hvm/svm/vmcb.h b/xen/include/asm-x86/hvm/svm/vmcb.h
index 9e1e42f4941c..4fa2ddfb2ff2 100644
--- a/xen/include/asm-x86/hvm/svm/vmcb.h
+++ b/xen/include/asm-x86/hvm/svm/vmcb.h
@@ -521,7 +521,9 @@ struct vmcb_struct {
u64 _lastbranchtoip; /* cleanbit 10 */
u64 _lastintfromip; /* cleanbit 10 */
u64 _lastinttoip; /* cleanbit 10 */
- u64 res17[301];
+ u64 res17[9];
+ u64 spec_ctrl;
+ u64 res18[291];
};
struct svm_domain {
diff --git a/xen/include/asm-x86/msr-index.h b/xen/include/asm-x86/msr-index.h
index a14841055f0e..903923e5a58b 100644
--- a/xen/include/asm-x86/msr-index.h
+++ b/xen/include/asm-x86/msr-index.h
@@ -33,6 +33,7 @@
#define SPEC_CTRL_IBRS (_AC(1, ULL) << 0)
#define SPEC_CTRL_STIBP (_AC(1, ULL) << 1)
#define SPEC_CTRL_SSBD (_AC(1, ULL) << 2)
+#define SPEC_CTRL_PSFD (_AC(1, ULL) << 7)
#define MSR_PRED_CMD 0x00000049
#define PRED_CMD_IBPB (_AC(1, ULL) << 0)
@@ -137,6 +138,8 @@
#define VM_CR_INIT_REDIRECTION (_AC(1, ULL) << 1)
#define VM_CR_SVM_DISABLE (_AC(1, ULL) << 4)
+#define MSR_VIRT_SPEC_CTRL 0xc001011f /* Layout matches MSR_SPEC_CTRL */
+
/*
* Legacy MSR constants in need of cleanup. No new MSRs below this comment.
*/
diff --git a/xen/include/public/arch-x86/cpufeatureset.h b/xen/include/public/arch-x86/cpufeatureset.h
index 380b51b1b3b8..f1b072cf44cc 100644
--- a/xen/include/public/arch-x86/cpufeatureset.h
+++ b/xen/include/public/arch-x86/cpufeatureset.h
@@ -255,8 +255,18 @@ XEN_CPUFEATURE(CLZERO, 8*32+ 0) /*A CLZERO instruction */
XEN_CPUFEATURE(RSTR_FP_ERR_PTRS, 8*32+ 2) /*A (F)X{SAVE,RSTOR} always saves/restores FPU Error pointers */
XEN_CPUFEATURE(WBNOINVD, 8*32+ 9) /* WBNOINVD instruction */
XEN_CPUFEATURE(IBPB, 8*32+12) /*A IBPB support only (no IBRS, used by AMD) */
+XEN_CPUFEATURE(IBRS, 8*32+14) /* MSR_SPEC_CTRL.IBRS */
+XEN_CPUFEATURE(AMD_STIBP, 8*32+15) /* MSR_SPEC_CTRL.STIBP */
+XEN_CPUFEATURE(IBRS_ALWAYS, 8*32+16) /* IBRS preferred always on */
+XEN_CPUFEATURE(STIBP_ALWAYS, 8*32+17) /* STIBP preferred always on */
+XEN_CPUFEATURE(IBRS_FAST, 8*32+18) /* IBRS preferred over software options */
+XEN_CPUFEATURE(IBRS_SAME_MODE, 8*32+19) /* IBRS provides same-mode protection */
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(PSFD, 8*32+28) /* MSR_SPEC_CTRL.PSFD */
/* Intel-defined CPU features, CPUID level 0x00000007:0.edx, word 9 */
XEN_CPUFEATURE(AVX512_4VNNIW, 9*32+ 2) /*A AVX512 Neural Network Instructions */
--
2.11.0
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@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
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.
Jan
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@citrix.com>
> Reviewed-by: Jan Beulich <jbeulich@suse.com>
> 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. 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.
~Andrew
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@citrix.com>
>> Reviewed-by: Jan Beulich <jbeulich@suse.com>
>> 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
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@citrix.com>
>>> Reviewed-by: Jan Beulich <jbeulich@suse.com>
>>> 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
© 2016 - 2026 Red Hat, Inc.