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

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 13/10/14 12:40, Anthony Liguori wrote:
> On Mon, Oct 13, 2014 at 11:52 AM, Andrew Cooper
> <andrew.cooper3@citrix.com> 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.

I am uneasy with keeping two codepaths like this as it doubles the test
matrix, and makes it easier for subtle bugs to hide.

On the other hand, there might not be another compatible method of
"migrating" VMs across this boundary.  This is going to require some
thought to solve.

This is yet another large issue to go on the todo list to "make
migration work properly".

~Andrew