diff options
Diffstat (limited to '0029-x86-vmx-Support-for-CPUs-without-model-specific-LBR.patch')
| -rw-r--r-- | 0029-x86-vmx-Support-for-CPUs-without-model-specific-LBR.patch | 83 |
1 files changed, 0 insertions, 83 deletions
diff --git a/0029-x86-vmx-Support-for-CPUs-without-model-specific-LBR.patch b/0029-x86-vmx-Support-for-CPUs-without-model-specific-LBR.patch deleted file mode 100644 index 2f87b83..0000000 --- a/0029-x86-vmx-Support-for-CPUs-without-model-specific-LBR.patch +++ /dev/null @@ -1,83 +0,0 @@ -From e904d8ae01a0be53368c8c388f13bf4ffcbcdf6c Mon Sep 17 00:00:00 2001 -From: Andrew Cooper <andrew.cooper3@citrix.com> -Date: Tue, 7 Feb 2023 16:59:14 +0100 -Subject: [PATCH 29/89] 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 ad91464103..861f91f2af 100644 ---- a/xen/arch/x86/hvm/vmx/vmx.c -+++ b/xen/arch/x86/hvm/vmx/vmx.c -@@ -3545,18 +3545,26 @@ static int cf_check vmx_msr_write_intercept( - 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 -@@ -3567,13 +3575,6 @@ static int cf_check vmx_msr_write_intercept( - { - 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 - |