1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
|
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
|
GitWeb