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

[Anthony Liguori <anthony@xxxxxxxxxxxxx>]

On Mon, Oct 13, 2014 at 11:52 AM, Andrew Cooper
<andrew.cooper3@xxxxxxxxxx> 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@xxxxxxxxxxxxx
> http://lists.xen.org/xen-devel

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