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 <edvin.torok@citrix.com>
---

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             0x000006a8
 
 #define MSR_X2APIC_FIRST                    0x00000800
-#define MSR_X2APIC_LAST                     0x00000bff
+#define MSR_X2APIC_LAST                     0x000008ff
 
 #define MSR_X2APIC_TPR                      0x00000808
 #define MSR_X2APIC_PPR                      0x0000080a
-- 
2.34.1

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 <edvin.torok@citrix.com>

Reviewed-by: Jan Beulich <jbeulich@suse.com>

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.

~Andrew

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

On 26/07/2022 16:47, Jan Beulich wrote:
> 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?

My mistake.  I forgot when we changed the MSR default readability.

This should go back to 4.15.

~Andrew