[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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




> -----Original Message-----
> From: xen-devel-bounces@xxxxxxxxxxxxx
> [mailto:xen-devel-bounces@xxxxxxxxxxxxx] 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@xxxxxxxxxxxxx
> http://lists.xen.org/xen-devel

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.