Re: [PATCH v2] x86/msr: fix X2APIC_LAST

[Jan Beulich]

On 26.07.2022 17:42, Andrew Cooper wrote:
> On 26/07/2022 16:33, Jan Beulich wrote:
>> On 26.07.2022 17:28, Edwin Török wrote:
>>> The latest Intel manual now says the X2APIC reserved range is only
>>> 0x800 to 0x8ff (NOT 0xbff).
>>> This changed between SDM 68 (Nov 2018) and SDM 69 (Jan 2019).
>>> The AMD manual documents 0x800-0x8ff too.
>>>
>>> There are non-X2APIC MSRs in the 0x900-0xbff range now:
>>> e.g. 0x981 is IA32_TME_CAPABILITY, an architectural MSR.
>>>
>>> The new MSR in this range appears to have been introduced in Icelake,
>>> so this commit should be backported to Xen versions supporting Icelake.
>>>
>>> Backport: 4.13+
>> FAOD nevertheless it'll be applied only back to 4.15.
> 
> It shouldn't go back before 4.16, because otherwise we start exposing a
> bunch of MSRs (including undocumented ones on Haswell/Broadwell) which
> were previously disallowed.

Hmm, I'm confused - how would the limiting of this range cause more
MSRs to be exposed in 4.15?

Jan

Re: [PATCH v2] x86/msr: fix X2APIC_LAST

[Jan Beulich]

On 26.07.2022 17:28, Edwin Török wrote:
> The latest Intel manual now says the X2APIC reserved range is only
> 0x800 to 0x8ff (NOT 0xbff).
> This changed between SDM 68 (Nov 2018) and SDM 69 (Jan 2019).
> The AMD manual documents 0x800-0x8ff too.
> 
> There are non-X2APIC MSRs in the 0x900-0xbff range now:
> e.g. 0x981 is IA32_TME_CAPABILITY, an architectural MSR.
> 
> The new MSR in this range appears to have been introduced in Icelake,
> so this commit should be backported to Xen versions supporting Icelake.
> 
> Backport: 4.13+

FAOD nevertheless it'll be applied only back to 4.15.

> Signed-off-by: Edwin Török 

Reviewed-by: Jan Beulich 

[PATCH v2] x86/msr: fix X2APIC_LAST

[Edwin Török]

The latest Intel manual now says the X2APIC reserved range is only
0x800 to 0x8ff (NOT 0xbff).
This changed between SDM 68 (Nov 2018) and SDM 69 (Jan 2019).
The AMD manual documents 0x800-0x8ff too.

There are non-X2APIC MSRs in the 0x900-0xbff range now:
e.g. 0x981 is IA32_TME_CAPABILITY, an architectural MSR.

The new MSR in this range appears to have been introduced in Icelake,
so this commit should be backported to Xen versions supporting Icelake.

Backport: 4.13+

Signed-off-by: Edwin Török 
---

Notes:
Changed since v1:
* include version of Intel SDM where the change occured
* remove opencoded MSR_X2APIC_FIRST + 0xff

 xen/arch/x86/hvm/vmx/vmx.c   | 4 ++--
 xen/arch/x86/include/asm/msr-index.h | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 47554cc004..17e103188a 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -3397,7 +3397,7 @@ void vmx_vlapic_msr_changed(struct vcpu *v)
 if ( cpu_has_vmx_apic_reg_virt )
 {
 for ( msr = MSR_X2APIC_FIRST;
-  msr <= MSR_X2APIC_FIRST + 0xff; msr++ )
+  msr <= MSR_X2APIC_LAST; msr++ )
 vmx_clear_msr_intercept(v, msr, VMX_MSR_R);
 
 vmx_set_msr_intercept(v, MSR_X2APIC_PPR, VMX_MSR_R);
@@ -3418,7 +3418,7 @@ void vmx_vlapic_msr_changed(struct vcpu *v)
 if ( !(v->arch.hvm.vmx.secondary_exec_control &
SECONDARY_EXEC_VIRTUALIZE_X2APIC_MODE) )
 for ( msr = MSR_X2APIC_FIRST;
-  msr <= MSR_X2APIC_FIRST + 0xff; msr++ )
+  msr <= MSR_X2APIC_LAST; msr++ )
 vmx_set_msr_intercept(v, msr, VMX_MSR_RW);
 
 vmx_update_secondary_exec_control(v);
diff --git a/xen/arch/x86/include/asm/msr-index.h 
b/xen/arch/x86/include/asm/msr-index.h
index 8cab8736d8..1a928ea6af 100644
--- a/xen/arch/x86/include/asm/msr-index.h
+++ b/xen/arch/x86/include/asm/msr-index.h
@@ -148,7 +148,7 @@
 #define MSR_INTERRUPT_SSP_TABLE 0x06a8
 
 #define MSR_X2APIC_FIRST0x0800
-#define MSR_X2APIC_LAST 0x0bff
+#define MSR_X2APIC_LAST 0x08ff
 
 #define MSR_X2APIC_TPR  0x0808
 #define MSR_X2APIC_PPR  0x080a
-- 
2.34.1