Re: [Xen-devel] [PATCH for-4.10] x86: Avoid corruption on migrate for vcpus using CPUID Faulting

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 27.11.17 at 12:37, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 27/11/17 09:53, Jan Beulich wrote:
>>>>> On 25.11.17 at 19:15, <andrew.cooper3@xxxxxxxxxx> wrote:
>>> @@ -1311,10 +1311,49 @@ long arch_do_domctl(
>>>                  vmsrs->msr_count = nr_msrs;
>>>              else
>>>              {
>>> +                static const uint32_t msrs[] = {
>>> +                    MSR_INTEL_MISC_FEATURES_ENABLES,
>> ... is this really a non-optional MSR? In particular,
>> calculate_hvm_max_policy() ties it to INTEL_PLATFORM_INFO,
>> which in turn is being tied to running on an Intel CPU.
>> calculate_pv_max_policy() is even more picky. I think you want
>> to introduce a function in msr.c complementing guest_rdmsr() /
>> guest_wrmsr(), similar to HVM's .init_msr() hook.
> 
> Whether an MSR should be migrated depends on whether the guest is able
> to use it.

Indeed, and the MSR here is unusable by a guest as long as Xen
runs on an Intel CPU, regardless of the virtual CPU vendor.

> I'm specifically looking to remove the concept of optional MSRs to avoid
> duplicating the MSR policy logic, and risking it being different.  In
> reality, what this means is that the migration code will be expected to
> cope with the union of all possible MSRs, and only actually get a subset
> to put into the stream.

If that's the goal, I think it would help if you said so in the patch
description.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel