Mailing List Archive

[xen stable-4.16] x86/vmx: Support for CPUs without model-specific LBR
commit 9f425039ca50e8cc8db350ec54d8a7cd4175f417
Author: Andrew Cooper <andrew.cooper3@citrix.com>
AuthorDate: Tue Feb 7 17:04:49 2023 +0100
Commit: Jan Beulich <jbeulich@suse.com>
CommitDate: Tue Feb 7 17:04:49 2023 +0100

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;
--
generated by git-patchbot for /home/xen/git/xen.git#stable-4.16