From 9f425039ca50e8cc8db350ec54d8a7cd4175f417 Mon Sep 17 00:00:00 2001 From: Andrew Cooper Date: Tue, 7 Feb 2023 17:04:49 +0100 Subject: [PATCH 07/61] x86/vmx: Support for CPUs without model-specific LBR Ice Lake (server at least) has both architectural LBR and model-specific LBR. Sapphire Rapids does not have model-specific LBR at all. I.e. On SPR and later, model_specific_lbr will always be NULL, so we must make changes to avoid reliably hitting the domain_crash(). The Arch LBR spec states that CPUs without model-specific LBR implement MSR_DBG_CTL.LBR by discarding writes and always returning 0. Do this for any CPU for which we lack model-specific LBR information. Adjust the now-stale comment, now that the Arch LBR spec has created a way to signal "no model specific LBR" to guests. Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich Reviewed-by: Kevin Tian master commit: 3edca52ce736297d7fcf293860cd94ef62638052 master date: 2023-01-12 18:42:00 +0000 --- xen/arch/x86/hvm/vmx/vmx.c | 31 ++++++++++++++++--------------- 1 file changed, 16 insertions(+), 15 deletions(-) diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c index bc308d9df2..094141be9a 100644 --- a/xen/arch/x86/hvm/vmx/vmx.c +++ b/xen/arch/x86/hvm/vmx/vmx.c @@ -3518,18 +3518,26 @@ static int vmx_msr_write_intercept(unsigned int msr, uint64_t msr_content) if ( msr_content & rsvd ) goto gp_fault; + /* + * The Arch LBR spec (new in Ice Lake) states that CPUs with no + * model-specific LBRs implement MSR_DBG_CTL.LBR by discarding writes + * and always returning 0. + * + * Use this property in all cases where we don't know any + * model-specific LBR information, as it matches real hardware + * behaviour on post-Ice Lake systems. + */ + if ( !model_specific_lbr ) + msr_content &= ~IA32_DEBUGCTLMSR_LBR; + /* * When a guest first enables LBR, arrange to save and restore the LBR * MSRs and allow the guest direct access. * - * MSR_DEBUGCTL and LBR has existed almost as long as MSRs have - * existed, and there is no architectural way to hide the feature, or - * fail the attempt to enable LBR. - * - * Unknown host LBR MSRs or hitting -ENOSPC with the guest load/save - * list are definitely hypervisor bugs, whereas -ENOMEM for allocating - * the load/save list is simply unlucky (and shouldn't occur with - * sensible management by the toolstack). + * Hitting -ENOSPC with the guest load/save list is definitely a + * hypervisor bug, whereas -ENOMEM for allocating the load/save list + * is simply unlucky (and shouldn't occur with sensible management by + * the toolstack). * * Either way, there is nothing we can do right now to recover, and * the guest won't execute correctly either. Simply crash the domain @@ -3540,13 +3548,6 @@ static int vmx_msr_write_intercept(unsigned int msr, uint64_t msr_content) { const struct lbr_info *lbr = model_specific_lbr; - if ( unlikely(!lbr) ) - { - gprintk(XENLOG_ERR, "Unknown Host LBR MSRs\n"); - domain_crash(v->domain); - return X86EMUL_OKAY; - } - for ( ; lbr->count; lbr++ ) { unsigned int i; -- 2.40.0