| Message ID | f22ea4c14d8be5672c036076ecd5818c6ca1d06a.1658849010.git.edvin.torok@citrix.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [v2] x86/msr: fix X2APIC_LAST | expand |
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
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
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(-)