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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

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


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