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 3:35 PM, Andrew Cooper
<andrew.cooper3@xxxxxxxxxx> wrote:
> On 13/10/14 12:40, Anthony Liguori wrote:
>> 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.
>
> 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".

The way this is handled by KVM (really by QEMU) is that there are a
number of pre-defined -cpu options which select a fixed CPUID
combinations based on high level CPU families (i.e. Sandybridge,
Nehalem, etc.).  There is also a '-cpu host' option which is
essentially passthrough (although that is done via an in-kernel
feature whitelist).

MSRs are never passed through.  They are always virtualized even with -cpu host.

Regards,

Anthony Liguori

> ~Andrew
>

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