x2APIC MSR range (XSA-108 follow-up)

x2APIC MSR range (XSA-108 follow-up)

[Jan Beulich]

All,

during the embargo period of XSA-108 Matt pointed out that restricting
the emulated MSR range to 0x800-0x8ff isn't necessarily the ultimately
correct thing to do (as also noted in commit 61fdda7acf's description):
The x2APIC MSR range really is being specified as 0x800-0xbff, as
opposed to the range considered for virtualization purposes
(0x800-0x8ff). In order to determine proper behavior here we'd like to
get clarification from you, particularly also in the light of probing real
hardware pointing out the existence of (at least) MSRs 0xa00-0xa02.

With what we currently do (kind of supported by their values at least
not differing across physical CPUs on the probed systems) their values
are getting passed through to guests. The alternative of forcing #GP
for accesses to them as one could imply from the spec seems
undesirable: Guests may imply their existence based on CPU model.
Hence the only apparent reasonable alternative would be to provide
proper virtualization for these registers, requiring to know their
purpose.

Thanks, Jan

Re: x2APIC MSR range (XSA-108 follow-up)

[Anthony Liguori]

On Mon, Oct 13, 2014 at 8:45 AM, Jan Beulich <JBeulich@suse.com> wrote:
> All,
>
> during the embargo period of XSA-108 Matt pointed out that restricting
> the emulated MSR range to 0x800-0x8ff isn't necessarily the ultimately
> correct thing to do (as also noted in commit 61fdda7acf's description):
> The x2APIC MSR range really is being specified as 0x800-0xbff, as
> opposed to the range considered for virtualization purposes
> (0x800-0x8ff). In order to determine proper behavior here we'd like to
> get clarification from you, particularly also in the light of probing real
> hardware pointing out the existence of (at least) MSRs 0xa00-0xa02.

The original x2apic patch for Xen was a ported version of the KVM
implementation for x2apic.  Unfortunately, it lacked the changes to
apic_reg_read() to prevent accesses to the reserved registers which is
what led to XSA 108.  The check in KVM is:

+       if (offset > 0x3f0 || !(rmask & (1ULL << (offset >> 4)))) {
+               printk(KERN_ERR "KVM_APIC_READ: read reserved register %x\n",
+                               offset);
+               return 1;
+       }
+

In apic_reg_read() who's logical cousin in Xen would probably be
vlapic_read_aligned().  Having checks closer to the actual access
seems more robust than relying on higher level code to do the right
thing.  Am happy to send a patch if this seems reasonable.

> With what we currently do (kind of supported by their values at least
> not differing across physical CPUs on the probed systems) their values
> are getting passed through to guests. The alternative of forcing #GP
> for accesses to them as one could imply from the spec seems
> undesirable: Guests may imply their existence based on CPU model.

This range is not documented publicly AFAIK so I think this risk is
pretty low.  I think the risk of passing through reserved MSRs that
may one day have security implications is something not to take
lightly either.

Regards,

Anthony Liguori

> Hence the only apparent reasonable alternative would be to provide
> proper virtualization for these registers, requiring to know their
> purpose.
>
> Thanks, Jan
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

Re: x2APIC MSR range (XSA-108 follow-up)

[Jan Beulich]

>>> On 13.10.14 at 11:26, <anthony@codemonkey.ws> wrote:
> On Mon, Oct 13, 2014 at 8:45 AM, Jan Beulich <JBeulich@suse.com> wrote:
>> With what we currently do (kind of supported by their values at least
>> not differing across physical CPUs on the probed systems) their values
>> are getting passed through to guests. The alternative of forcing #GP
>> for accesses to them as one could imply from the spec seems
>> undesirable: Guests may imply their existence based on CPU model.
> 
> This range is not documented publicly AFAIK so I think this risk is
> pretty low.  I think the risk of passing through reserved MSRs that
> may one day have security implications is something not to take
> lightly either.

Note that this has been standard behavior for all MSR reads that
don't get explicitly virtualized. Yes, it is known that this poses a
certain risk going forward. But changing from a black listing to a
white listing approach would (just like for some parts of CPUID
handling) be risking regressions if we failed to white list (no
matter whether to pass through the host value or to emulate)
everything needed by any kind of guest OS. Which I suppose is
the reason no-one dared to come up with a respective patch so
far.

Jan

Supporting default reads of host MSRs [WAS: x2APIC MSR range (XSA-108 follow-up)]

[Andrew Cooper]

On 13/10/14 07:45, Jan Beulich wrote:
> All,
>
> during the embargo period of XSA-108 Matt pointed out that restricting
> the emulated MSR range to 0x800-0x8ff isn't necessarily the ultimately
> correct thing to do (as also noted in commit 61fdda7acf's description):
> The x2APIC MSR range really is being specified as 0x800-0xbff, as
> opposed to the range considered for virtualization purposes
> (0x800-0x8ff). In order to determine proper behavior here we'd like to
> get clarification from you, particularly also in the light of probing real
> hardware pointing out the existence of (at least) MSRs 0xa00-0xa02.
>
> With what we currently do (kind of supported by their values at least
> not differing across physical CPUs on the probed systems) their values
> are getting passed through to guests. The alternative of forcing #GP
> for accesses to them as one could imply from the spec seems
> undesirable: Guests may imply their existence based on CPU model.
> Hence the only apparent reasonable alternative would be to provide
> proper virtualization for these registers, requiring to know their
> purpose.
>
> Thanks, Jan

Having read this and put  two and two together, permitting default reads
of host MSRs is irreconcilable against correctly supporting migration of
HVM VMs.

In the past, XenServer has seen a handful of cases of a Window BSODs
because of critical structure corruption in the IA32_MISC_ENABLE MSR. 
They were unable to be seen again, but were on migration tests.

Exactly the same logic applies to the cpuid infrastructure, although
that has many more noticeable problems atm.

~Andrew

Re: Supporting default reads of host MSRs

[Matt Wilson]

On Mon, Oct 13, 2014 at 10:52:34AM +0100, Andrew Cooper wrote:
> 
> Having read this and put  two and two together, permitting default reads
> of host MSRs is irreconcilable against correctly supporting migration of
> HVM VMs.
> 
> In the past, XenServer has seen a handful of cases of a Window BSODs
> because of critical structure corruption in the IA32_MISC_ENABLE MSR. 
> They were unable to be seen again, but were on migration tests.
> 
> Exactly the same logic applies to the cpuid infrastructure, although
> that has many more noticeable problems atm.

I think it makes a lot of sense to be much more explicit about this
aspect of CPU virtualization.

--msw

Re: Supporting default reads of host MSRs [WAS: x2APIC MSR range (XSA-108 follow-up)]

[Anthony Liguori]

On Mon, Oct 13, 2014 at 11:52 AM, Andrew Cooper
<andrew.cooper3@citrix.com> wrote:
> On 13/10/14 07:45, Jan Beulich wrote:
>> All,
>>
>> during the embargo period of XSA-108 Matt pointed out that restricting
>> the emulated MSR range to 0x800-0x8ff isn't necessarily the ultimately
>> correct thing to do (as also noted in commit 61fdda7acf's description):
>> The x2APIC MSR range really is being specified as 0x800-0xbff, as
>> opposed to the range considered for virtualization purposes
>> (0x800-0x8ff). In order to determine proper behavior here we'd like to
>> get clarification from you, particularly also in the light of probing real
>> hardware pointing out the existence of (at least) MSRs 0xa00-0xa02.
>>
>> With what we currently do (kind of supported by their values at least
>> not differing across physical CPUs on the probed systems) their values
>> are getting passed through to guests. The alternative of forcing #GP
>> for accesses to them as one could imply from the spec seems
>> undesirable: Guests may imply their existence based on CPU model.
>> Hence the only apparent reasonable alternative would be to provide
>> proper virtualization for these registers, requiring to know their
>> purpose.
>>
>> Thanks, Jan
>
> Having read this and put  two and two together, permitting default reads
> of host MSRs is irreconcilable against correctly supporting migration of
> HVM VMs.

Yes.

> In the past, XenServer has seen a handful of cases of a Window BSODs
> because of critical structure corruption in the IA32_MISC_ENABLE MSR.
> They were unable to be seen again, but were on migration tests.
>
> Exactly the same logic applies to the cpuid infrastructure, although
> that has many more noticeable problems atm.

Given that a number of these MSRs have functionality that are not
publicly documented, I think a white list is the only sane approach.

This could be done as an option during domain creation if there was a
concern about backwards compatibility.

Regards,

Anthony Liguori

> ~Andrew
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

Re: Supporting default reads of host MSRs [WAS: x2APIC MSR range (XSA-108 follow-up)]

[Andrew Cooper]

On 13/10/14 12:40, Anthony Liguori wrote:
> On Mon, Oct 13, 2014 at 11:52 AM, Andrew Cooper
> <andrew.cooper3@citrix.com> wrote:
>> On 13/10/14 07:45, Jan Beulich wrote:
>>> All,
>>>
>>> during the embargo period of XSA-108 Matt pointed out that restricting
>>> the emulated MSR range to 0x800-0x8ff isn't necessarily the ultimately
>>> correct thing to do (as also noted in commit 61fdda7acf's description):
>>> The x2APIC MSR range really is being specified as 0x800-0xbff, as
>>> opposed to the range considered for virtualization purposes
>>> (0x800-0x8ff). In order to determine proper behavior here we'd like to
>>> get clarification from you, particularly also in the light of probing real
>>> hardware pointing out the existence of (at least) MSRs 0xa00-0xa02.
>>>
>>> With what we currently do (kind of supported by their values at least
>>> not differing across physical CPUs on the probed systems) their values
>>> are getting passed through to guests. The alternative of forcing #GP
>>> for accesses to them as one could imply from the spec seems
>>> undesirable: Guests may imply their existence based on CPU model.
>>> Hence the only apparent reasonable alternative would be to provide
>>> proper virtualization for these registers, requiring to know their
>>> purpose.
>>>
>>> Thanks, Jan
>> Having read this and put  two and two together, permitting default reads
>> of host MSRs is irreconcilable against correctly supporting migration of
>> HVM VMs.
> Yes.
>
>> In the past, XenServer has seen a handful of cases of a Window BSODs
>> because of critical structure corruption in the IA32_MISC_ENABLE MSR.
>> They were unable to be seen again, but were on migration tests.
>>
>> Exactly the same logic applies to the cpuid infrastructure, although
>> that has many more noticeable problems atm.
> Given that a number of these MSRs have functionality that are not
> publicly documented, I think a white list is the only sane approach.
>
> This could be done as an option during domain creation if there was a
> concern about backwards compatibility.

I am uneasy with keeping two codepaths like this as it doubles the test
matrix, and makes it easier for subtle bugs to hide.

On the other hand, there might not be another compatible method of
"migrating" VMs across this boundary.  This is going to require some
thought to solve.

This is yet another large issue to go on the todo list to "make
migration work properly".

~Andrew

Re: Supporting default reads of host MSRs [WAS: x2APIC MSR range (XSA-108 follow-up)]

[Anthony Liguori]

On Mon, Oct 13, 2014 at 3:35 PM, Andrew Cooper
<andrew.cooper3@citrix.com> wrote:
> On 13/10/14 12:40, Anthony Liguori wrote:
>> On Mon, Oct 13, 2014 at 11:52 AM, Andrew Cooper
>> <andrew.cooper3@citrix.com> wrote:
>>> On 13/10/14 07:45, Jan Beulich wrote:
>>>> All,
>>>>
>>>> during the embargo period of XSA-108 Matt pointed out that restricting
>>>> the emulated MSR range to 0x800-0x8ff isn't necessarily the ultimately
>>>> correct thing to do (as also noted in commit 61fdda7acf's description):
>>>> The x2APIC MSR range really is being specified as 0x800-0xbff, as
>>>> opposed to the range considered for virtualization purposes
>>>> (0x800-0x8ff). In order to determine proper behavior here we'd like to
>>>> get clarification from you, particularly also in the light of probing real
>>>> hardware pointing out the existence of (at least) MSRs 0xa00-0xa02.
>>>>
>>>> With what we currently do (kind of supported by their values at least
>>>> not differing across physical CPUs on the probed systems) their values
>>>> are getting passed through to guests. The alternative of forcing #GP
>>>> for accesses to them as one could imply from the spec seems
>>>> undesirable: Guests may imply their existence based on CPU model.
>>>> Hence the only apparent reasonable alternative would be to provide
>>>> proper virtualization for these registers, requiring to know their
>>>> purpose.
>>>>
>>>> Thanks, Jan
>>> Having read this and put  two and two together, permitting default reads
>>> of host MSRs is irreconcilable against correctly supporting migration of
>>> HVM VMs.
>> Yes.
>>
>>> In the past, XenServer has seen a handful of cases of a Window BSODs
>>> because of critical structure corruption in the IA32_MISC_ENABLE MSR.
>>> They were unable to be seen again, but were on migration tests.
>>>
>>> Exactly the same logic applies to the cpuid infrastructure, although
>>> that has many more noticeable problems atm.
>> Given that a number of these MSRs have functionality that are not
>> publicly documented, I think a white list is the only sane approach.
>>
>> This could be done as an option during domain creation if there was a
>> concern about backwards compatibility.
>
> I am uneasy with keeping two codepaths like this as it doubles the test
> matrix, and makes it easier for subtle bugs to hide.
>
> On the other hand, there might not be another compatible method of
> "migrating" VMs across this boundary.  This is going to require some
> thought to solve.
>
> This is yet another large issue to go on the todo list to "make
> migration work properly".

The way this is handled by KVM (really by QEMU) is that there are a
number of pre-defined -cpu options which select a fixed CPUID
combinations based on high level CPU families (i.e. Sandybridge,
Nehalem, etc.).  There is also a '-cpu host' option which is
essentially passthrough (although that is done via an in-kernel
feature whitelist).

MSRs are never passed through.  They are always virtualized even with -cpu host.

Regards,

Anthony Liguori

> ~Andrew
>

Re: x2APIC MSR range (XSA-108 follow-up)

[Matt Wilson]

On Mon, Oct 13, 2014 at 07:45:58AM +0100, Jan Beulich wrote:
> All,
> 
> during the embargo period of XSA-108 Matt pointed out that restricting
> the emulated MSR range to 0x800-0x8ff isn't necessarily the ultimately
> correct thing to do (as also noted in commit 61fdda7acf's description):
> The x2APIC MSR range really is being specified as 0x800-0xbff, as
> opposed to the range considered for virtualization purposes
> (0x800-0x8ff). In order to determine proper behavior here we'd like to
> get clarification from you, particularly also in the light of probing real
> hardware pointing out the existence of (at least) MSRs 0xa00-0xa02.

I recall the MSRs in question being 0xa00 and 0xa01. Perhaps 0xa02
also provided a value, but I'm not as sure.

> With what we currently do (kind of supported by their values at least
> not differing across physical CPUs on the probed systems) their values
> are getting passed through to guests. The alternative of forcing #GP
> for accesses to them as one could imply from the spec seems
> undesirable: Guests may imply their existence based on CPU model.
> Hence the only apparent reasonable alternative would be to provide
> proper virtualization for these registers, requiring to know their
> purpose.

As MSRs that are not publicly documented, I suspect that 0xa00 and
0xa01 don't have semantics that have meaning in the virtualization
context. Confirmation from Intel is welcome so we can determine the
right path.

--msw

Re: x2APIC MSR range (XSA-108 follow-up)

[Wu, Feng]

> -----Original Message-----
> From: xen-devel-bounces@lists.xen.org
> [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of Matt Wilson
> Sent: Monday, October 13, 2014 6:58 PM
> To: Jan Beulich
> Cc: xen-devel; Tian, Kevin; Dong, Eddie; Dugger, Donald D; Nakajima, Jun
> Subject: Re: [Xen-devel] x2APIC MSR range (XSA-108 follow-up)
> 
> On Mon, Oct 13, 2014 at 07:45:58AM +0100, Jan Beulich wrote:
> > All,
> >
> > during the embargo period of XSA-108 Matt pointed out that restricting
> > the emulated MSR range to 0x800-0x8ff isn't necessarily the ultimately
> > correct thing to do (as also noted in commit 61fdda7acf's description):
> > The x2APIC MSR range really is being specified as 0x800-0xbff, as
> > opposed to the range considered for virtualization purposes
> > (0x800-0x8ff). In order to determine proper behavior here we'd like to
> > get clarification from you, particularly also in the light of probing real
> > hardware pointing out the existence of (at least) MSRs 0xa00-0xa02.
> 
> I recall the MSRs in question being 0xa00 and 0xa01. Perhaps 0xa02
> also provided a value, but I'm not as sure.
> 
> > With what we currently do (kind of supported by their values at least
> > not differing across physical CPUs on the probed systems) their values
> > are getting passed through to guests. The alternative of forcing #GP
> > for accesses to them as one could imply from the spec seems
> > undesirable: Guests may imply their existence based on CPU model.
> > Hence the only apparent reasonable alternative would be to provide
> > proper virtualization for these registers, requiring to know their
> > purpose.
> 
> As MSRs that are not publicly documented, I suspect that 0xa00 and
> 0xa01 don't have semantics that have meaning in the virtualization
> context. Confirmation from Intel is welcome so we can determine the
> right path.
> 
> --msw

The SDM 10.12.1.2 says:

" Addresses in the range 800H¨CBFFH that are not listed in Table 10-6 (including 80EH and 831H) are reserved.
Executions of RDMSR and WRMSR that attempt to access such addresses cause general-protection exceptions. "

Table 10-6. Local APIC Register Address Map Supported by x2APIC

Why should we virtualize those reserved MSRs for guests?

Thanks,
Feng

> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

Re: x2APIC MSR range (XSA-108 follow-up)

[Zhang, Yang Z]

Wu, Feng wrote on 2014-10-14:
> 
> 
> xen-devel-bounces@lists.xen.org wrote on mailto:xen-devel-bounces@lists.xen.org] On Behalf Of Matt Wilson:
>> Jun
>> Subject: Re: [Xen-devel] x2APIC MSR range (XSA-108 follow-up)
>> 
>> On Mon, Oct 13, 2014 at 07:45:58AM +0100, Jan Beulich wrote:
>>> All,
>>> 
>>> during the embargo period of XSA-108 Matt pointed out that restricting
>>> the emulated MSR range to 0x800-0x8ff isn't necessarily the ultimately
>>> correct thing to do (as also noted in commit 61fdda7acf's
>>> description): The x2APIC MSR range really is being specified as
>>> 0x800-0xbff, as opposed to the range considered for virtualization
>>> purposes (0x800-0x8ff). In order to determine proper behavior here
>>> we'd like to get clarification from you, particularly also in the
>>> light of probing real hardware pointing out the existence of (at
>>> least) MSRs
> 0xa00-0xa02.
>> 
>> I recall the MSRs in question being 0xa00 and 0xa01. Perhaps 0xa02
>> also provided a value, but I'm not as sure.
>> 
>>> With what we currently do (kind of supported by their values at
>>> least not differing across physical CPUs on the probed systems)
>>> their values are getting passed through to guests. The alternative
>>> of forcing #GP for accesses to them as one could imply from the
>>> spec seems
>>> undesirable: Guests may imply their existence based on CPU model.
>>> Hence the only apparent reasonable alternative would be to provide
>>> proper virtualization for these registers, requiring to know their
>>> purpose.
>> 
>> As MSRs that are not publicly documented, I suspect that 0xa00 and
>> 0xa01 don't have semantics that have meaning in the virtualization
>> context. Confirmation from Intel is welcome so we can determine the
>> right path.
>> 
>> --msw
> 
> The SDM 10.12.1.2 says:
> 
> " Addresses in the range 800H¨CBFFH that are not listed in Table 10-6
> (including 80EH and 831H) are reserved.
> Executions of RDMSR and WRMSR that attempt to access such addresses
> cause general-protection exceptions. "
> 
> Table 10-6. Local APIC Register Address Map Supported by x2APIC
> 
> Why should we virtualize those reserved MSRs for guests?

IIUC the question should be why those undocumented MSRs exist on real hardware and what do they do? Will guest access to them via check CPU model? If yes, how can we virtualize them correctly?

I don't have the answer right now but I will forward the question to hardware guy for more help.

> 
> Thanks,
> Feng
> 
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


Best regards,
Yang

Re: x2APIC MSR range (XSA-108 follow-up)

[Jan Beulich]

>>> On 14.10.14 at 08:23, <yang.z.zhang@intel.com> wrote:
>> The SDM 10.12.1.2 says:
>> 
>> " Addresses in the range 800ḦCBFFH that are not listed in Table 10-6
>> (including 80EH and 831H) are reserved.
>> Executions of RDMSR and WRMSR that attempt to access such addresses
>> cause general-protection exceptions. "
>> 
>> Table 10-6. Local APIC Register Address Map Supported by x2APIC
>> 
>> Why should we virtualize those reserved MSRs for guests?
> 
> IIUC the question should be why those undocumented MSRs exist on real 
> hardware and what do they do? Will guest access to them via check CPU model? 
> If yes, how can we virtualize them correctly?

Exactly. Additionally, the fact that MSRs 0xa00..0xa02 exist at least
on some CPU models already makes clear that the above cited
statement regarding raising of #GP is not really correct.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: x2APIC MSR range (XSA-108 follow-up)

[Matt Wilson]

On Tue, Oct 14, 2014 at 06:23:52AM +0000, Zhang, Yang Z wrote:
> Wu, Feng wrote on 2014-10-14:
> > 
> > The SDM 10.12.1.2 says:
> > 
> > " Addresses in the range 800H¨CBFFH that are not listed in Table 10-6
> > (including 80EH and 831H) are reserved.
> > Executions of RDMSR and WRMSR that attempt to access such addresses
> > cause general-protection exceptions. "
> > 
> > Table 10-6. Local APIC Register Address Map Supported by x2APIC
> > 
> > Why should we virtualize those reserved MSRs for guests?
> 
> IIUC the question should be why those undocumented MSRs exist on
> real hardware and what do they do? Will guest access to them via
> check CPU model? If yes, how can we virtualize them correctly?

I suspect that Intel knows what they are and what they do. I imagine
that both are CPU model specific.

> I don't have the answer right now but I will forward the question to
> hardware guy for more help.

Since these MSRs are not part of the SDM or any public platform
documentation as far as I can tell, I imagine that they are for
BIOS-level functionality that does not have meaning in a virtual
environment today and presents no OS compatibility problem if we
choose to #GP all access to them.

Short of some reply from Intel saying "No! That will break some OS" I
think that we should make the x2APIC MSR code handle 0x800...0xbff and
#GP any access that is above the emulated area.

--msw

Re: x2APIC MSR range (XSA-108 follow-up)

[Andrew Cooper]

On 16/10/14 08:57, Matt Wilson wrote:
> On Tue, Oct 14, 2014 at 06:23:52AM +0000, Zhang, Yang Z wrote:
>> Wu, Feng wrote on 2014-10-14:
>>> The SDM 10.12.1.2 says:
>>>
>>> " Addresses in the range 800H¨CBFFH that are not listed in Table 10-6
>>> (including 80EH and 831H) are reserved.
>>> Executions of RDMSR and WRMSR that attempt to access such addresses
>>> cause general-protection exceptions. "
>>>
>>> Table 10-6. Local APIC Register Address Map Supported by x2APIC
>>>
>>> Why should we virtualize those reserved MSRs for guests?
>> IIUC the question should be why those undocumented MSRs exist on
>> real hardware and what do they do? Will guest access to them via
>> check CPU model? If yes, how can we virtualize them correctly?
> I suspect that Intel knows what they are and what they do. I imagine
> that both are CPU model specific.
>
>> I don't have the answer right now but I will forward the question to
>> hardware guy for more help.
> Since these MSRs are not part of the SDM or any public platform
> documentation as far as I can tell, I imagine that they are for
> BIOS-level functionality that does not have meaning in a virtual
> environment today and presents no OS compatibility problem if we
> choose to #GP all access to them.
>
> Short of some reply from Intel saying "No! That will break some OS" I
> think that we should make the x2APIC MSR code handle 0x800...0xbff and
> #GP any access that is above the emulated area.

I have a patch like this currently getting a kicking in our dedicated
XSA-108 test set.  I will report back with how it does.

~Andrew

Re: x2APIC MSR range (XSA-108 follow-up)

[Zhang, Yang Z]

Matt Wilson wrote on 2014-10-13:
> On Mon, Oct 13, 2014 at 07:45:58AM +0100, Jan Beulich wrote:
>> All,
>> 
>> during the embargo period of XSA-108 Matt pointed out that
>> restricting the emulated MSR range to 0x800-0x8ff isn't necessarily
>> the ultimately correct thing to do (as also noted in commit 61fdda7acf's description):
>> The x2APIC MSR range really is being specified as 0x800-0xbff, as
>> opposed to the range considered for virtualization purposes
>> (0x800-0x8ff). In order to determine proper behavior here we'd like
>> to get clarification from you, particularly also in the light of
>> probing real hardware pointing out the existence of (at least) MSRs 0xa00-0xa02.
> 
> I recall the MSRs in question being 0xa00 and 0xa01. Perhaps 0xa02
> also provided a value, but I'm not as sure.

Which platform are you seeing it?

> 
>> With what we currently do (kind of supported by their values at
>> least not differing across physical CPUs on the probed systems)
>> their values are getting passed through to guests. The alternative
>> of forcing #GP for accesses to them as one could imply from the spec
>> seems
>> undesirable: Guests may imply their existence based on CPU model.
>> Hence the only apparent reasonable alternative would be to provide
>> proper virtualization for these registers, requiring to know their
>> purpose.
> 
> As MSRs that are not publicly documented, I suspect that 0xa00 and
> 0xa01 don't have semantics that have meaning in the virtualization context.
> Confirmation from Intel is welcome so we can determine the right path.
> 
> --msw
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


Best regards,
Yang

Re: x2APIC MSR range (XSA-108 follow-up)

[Matt Wilson]

On Tue, Oct 14, 2014 at 07:07:32AM +0000, Zhang, Yang Z wrote:
> Matt Wilson wrote on 2014-10-13:
> > On Mon, Oct 13, 2014 at 07:45:58AM +0100, Jan Beulich wrote:
> >> All,
> >> 
> >> during the embargo period of XSA-108 Matt pointed out that
> >> restricting the emulated MSR range to 0x800-0x8ff isn't necessarily
> >> the ultimately correct thing to do (as also noted in commit 61fdda7acf's description):
> >> The x2APIC MSR range really is being specified as 0x800-0xbff, as
> >> opposed to the range considered for virtualization purposes
> >> (0x800-0x8ff). In order to determine proper behavior here we'd like
> >> to get clarification from you, particularly also in the light of
> >> probing real hardware pointing out the existence of (at least) MSRs 0xa00-0xa02.
> > 
> > I recall the MSRs in question being 0xa00 and 0xa01. Perhaps 0xa02
> > also provided a value, but I'm not as sure.
> 
> Which platform are you seeing it?

Sandy Bridge and Ivy Bridge.

--msw

Re: x2APIC MSR range (XSA-108 follow-up)

[Jan Beulich]

>>> On 14.10.14 at 09:07, <yang.z.zhang@intel.com> wrote:
> Matt Wilson wrote on 2014-10-13:
>> On Mon, Oct 13, 2014 at 07:45:58AM +0100, Jan Beulich wrote:
>>> All,
>>> 
>>> during the embargo period of XSA-108 Matt pointed out that
>>> restricting the emulated MSR range to 0x800-0x8ff isn't necessarily
>>> the ultimately correct thing to do (as also noted in commit 61fdda7acf's 
> description):
>>> The x2APIC MSR range really is being specified as 0x800-0xbff, as
>>> opposed to the range considered for virtualization purposes
>>> (0x800-0x8ff). In order to determine proper behavior here we'd like
>>> to get clarification from you, particularly also in the light of
>>> probing real hardware pointing out the existence of (at least) MSRs 
> 0xa00-0xa02.
>> 
>> I recall the MSRs in question being 0xa00 and 0xa01. Perhaps 0xa02
>> also provided a value, but I'm not as sure.
> 
> Which platform are you seeing it?

Sandybridge (Romley) in my case.

Jan