On 7/9/2020 7:00 PM, Dave Hansen wrote:
On 7/8/20 2:51 AM, tip-bot2 for Kan Liang wrote:
diff --git a/arch/x86/include/asm/cpufeatures.h
b/arch/x86/include/asm/cpufeatures.h
index 02dabc9..72ba4c5 100644
--- a/arch/x86/include/asm/cpufeatures.h
+++ b/arch/x86/include/asm/cpufeatures.h
@@ -366,6 +366,7 @@
#define X86_FEATURE_MD_CLEAR (18*32+10) /* VERW clears CPU buffers */
#define X86_FEATURE_TSX_FORCE_ABORT (18*32+13) /* "" TSX_FORCE_ABORT */
#define X86_FEATURE_PCONFIG (18*32+18) /* Intel PCONFIG */
+#define X86_FEATURE_ARCH_LBR (18*32+19) /* Intel ARCH LBR */
#define X86_FEATURE_SPEC_CTRL (18*32+26) /* "" Speculation Control
(IBRS + IBPB) */
#define X86_FEATURE_INTEL_STIBP (18*32+27) /* "" Single Thread
Indirect Branch Predictors */
#define X86_FEATURE_FLUSH_L1D (18*32+28) /* Flush L1D cache */
Are architectural LBRs useful *without* XSAVE?
Yes, previous model-specific LBRs don't have XSAVE support, but it's
still widely used.
Adding XSAVE is more based on performance considerations. It doesn't
impact the existing LBR capabilities.
I once talked with our virtualization team. They also want us to support
both XSAVE and non-XSAVE version of LBRs. If the XSAVE is not available,
we should fall back to the previous MSR method.
I don't think we should make Arch LBR depends on XSAVE.
Thanks,
Kan
If not, should we add an
entry in arch/x86/kernel/cpu/cpuid-deps.c::cpuid_deps[] for this?
...
{ X86_FEATURE_ARCH_LBR, X86_FEATURE_XSAVES },
...
