Re: [Xen-devel] x2APIC MSR range (XSA-108 follow-up)

["Zhang, Yang Z" <yang.z.zhang@xxxxxxxxx>]

Wu, Feng wrote on 2014-10-14:
> 
> 
> xen-devel-bounces@xxxxxxxxxxxxx wrote on 
> mailto:xen-devel-bounces@xxxxxxxxxxxxx] 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@xxxxxxxxxxxxx
>> http://lists.xen.org/xen-devel
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxx
> http://lists.xen.org/xen-devel


Best regards,
Yang



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