[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] x2APIC MSR range (XSA-108 follow-up)
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@xxxxxxxxxxxxx > http://lists.xen.org/xen-devel Best regards, Yang _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |