diff options
Diffstat (limited to '0007-x86-vmx-Support-for-CPUs-without-model-specific-LBR.patch')
| -rw-r--r-- | 0007-x86-vmx-Support-for-CPUs-without-model-specific-LBR.patch | 83 |
1 files changed, 83 insertions, 0 deletions
diff --git a/0007-x86-vmx-Support-for-CPUs-without-model-specific-LBR.patch b/0007-x86-vmx-Support-for-CPUs-without-model-specific-LBR.patch new file mode 100644 index 0000000..fc81a17 --- /dev/null +++ b/0007-x86-vmx-Support-for-CPUs-without-model-specific-LBR.patch @@ -0,0 +1,83 @@ +From 9f425039ca50e8cc8db350ec54d8a7cd4175f417 Mon Sep 17 00:00:00 2001 +From: Andrew Cooper <andrew.cooper3@citrix.com> +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 <andrew.cooper3@citrix.com> +Reviewed-by: Jan Beulich <jbeulich@suse.com> +Reviewed-by: Kevin Tian <kevin.tian@intel.com> +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 + |