The latest Intel manual now says the X2APIC reserved range is only
0x800 to 0x8ff (NOT 0xbff). 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>
---
 xen/arch/x86/include/asm/msr-index.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

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 16:43, Edwin Török wrote:
> --- 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

May I ask that then the now open-coded values of MSR_X2APIC_LAST
(two instances in vmx.c using MSR_X2APIC_FIRST + 0xff) be replaced
at the same time?

Jan

> On 26 Jul 2022, at 16:07, Jan Beulich <jbeulich@suse.com> wrote:
> 
> On 26.07.2022 16:43, Edwin Török wrote:
>> --- 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
> 
> May I ask that then the now open-coded values of MSR_X2APIC_LAST
> (two instances in vmx.c using MSR_X2APIC_FIRST + 0xff) be replaced
> at the same time?


> On 26 Jul 2022, at 16:03, Andrew Cooper <Andrew.Cooper3@citrix.com> wrote:
> 
> On 26/07/2022 15:43, Edwin Török wrote:
>> The latest Intel manual now says the X2APIC reserved range is only
>> 0x800 to 0x8ff (NOT 0xbff). 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>
> 
> Having done some archaeology, this changed between SDM 68 (Nov 2018) and
> SDM 69 (Jan 2019)

Thanks, I've done both of these updates in the v2 I've sent out.

Best regards,
--Edwin

On 26/07/2022 15:43, Edwin Török wrote:
> The latest Intel manual now says the X2APIC reserved range is only
> 0x800 to 0x8ff (NOT 0xbff). 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>

Having done some archaeology, this changed between SDM 68 (Nov 2018) and
SDM 69 (Jan 2019)

~Andrew