| Message ID | d4fb4631b82643751fcb3356b094be65e5bc9bcc.1658846616.git.edvin.torok@citrix.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | x86/msr: fix X2APIC_LAST | expand |
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
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
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
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(-)