* [PATCH v2] x86/msr: fix X2APIC_LAST
@ 2022-07-26 15:28 Edwin Török
2022-07-26 15:33 ` Jan Beulich
0 siblings, 1 reply; 5+ messages in thread
From: Edwin Török @ 2022-07-26 15:28 UTC (permalink / raw
To: xen-devel
Cc: Edwin Török, Jun Nakajima, Kevin Tian, Jan Beulich,
Andrew Cooper, Roger Pau Monné, Wei Liu
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
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH v2] x86/msr: fix X2APIC_LAST
2022-07-26 15:28 [PATCH v2] x86/msr: fix X2APIC_LAST Edwin Török
@ 2022-07-26 15:33 ` Jan Beulich
2022-07-26 15:42 ` Andrew Cooper
0 siblings, 1 reply; 5+ messages in thread
From: Jan Beulich @ 2022-07-26 15:33 UTC (permalink / raw
To: Edwin Török
Cc: Jun Nakajima, Kevin Tian, Andrew Cooper, Roger Pau Monné,
Wei Liu, xen-devel
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>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH v2] x86/msr: fix X2APIC_LAST
2022-07-26 15:33 ` Jan Beulich
@ 2022-07-26 15:42 ` Andrew Cooper
2022-07-26 15:47 ` Jan Beulich
0 siblings, 1 reply; 5+ messages in thread
From: Andrew Cooper @ 2022-07-26 15:42 UTC (permalink / raw
To: Jan Beulich, Edwin Torok
Cc: Jun Nakajima, Kevin Tian, Roger Pau Monne, Wei Liu,
xen-devel@lists.xenproject.org
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH v2] x86/msr: fix X2APIC_LAST
2022-07-26 15:42 ` Andrew Cooper
@ 2022-07-26 15:47 ` Jan Beulich
2022-07-27 10:56 ` Andrew Cooper
0 siblings, 1 reply; 5+ messages in thread
From: Jan Beulich @ 2022-07-26 15:47 UTC (permalink / raw
To: Andrew Cooper
Cc: Jun Nakajima, Kevin Tian, Roger Pau Monne, Wei Liu,
xen-devel@lists.xenproject.org, Edwin Torok
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH v2] x86/msr: fix X2APIC_LAST
2022-07-26 15:47 ` Jan Beulich
@ 2022-07-27 10:56 ` Andrew Cooper
0 siblings, 0 replies; 5+ messages in thread
From: Andrew Cooper @ 2022-07-27 10:56 UTC (permalink / raw
To: Jan Beulich
Cc: Jun Nakajima, Kevin Tian, Roger Pau Monne, Wei Liu,
xen-devel@lists.xenproject.org, Edwin Torok
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
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2022-07-27 10:57 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2022-07-26 15:28 [PATCH v2] x86/msr: fix X2APIC_LAST Edwin Török
2022-07-26 15:33 ` Jan Beulich
2022-07-26 15:42 ` Andrew Cooper
2022-07-26 15:47 ` Jan Beulich
2022-07-27 10:56 ` Andrew Cooper
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.