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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 30.11.17 at 19:54, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 27/11/17 14:41, Jan Beulich wrote:
>>>>> On 27.11.17 at 14:02, <andrew.cooper3@xxxxxxxxxx> wrote:
>>> Xen 4.8 and later virtualises CPUID Faulting support for guests.  However, 
> the
>>> value of MSR_MISC_FEATURES_ENABLES is omitted from the vcpu state, meaning
>>> that the current cpuid faulting setting is lost on migrate/suspend/resume.
>>>
>>> To move this MSR, use the new guest_{rd,wr}msr() infrastructure.  This 
> avoids
>>> duplicating or opencoding the feature check and value logic, as well as
>>> abstracting away the internal value representation.  One small adjustment to
>>> guest_wrmsr() is required to cope with being called in toolstack context.
>>>
>>> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
>> With the further intentions mentioned in the description (as a
>> justification for some of the earlier requested changes to not
>> be done), as indicated in a late response to v1
>> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
> 
> I thought that was already clear from the second paragraph.  Either way,
> how about this?

Yes, I like this new version better. Thanks.

Jan

> Xen 4.8 and later virtualises CPUID Faulting support for guests. 
> However, the
> value of MSR_MISC_FEATURES_ENABLES is omitted from the vcpu state, meaning
> that the current cpuid faulting setting is lost on migrate/suspend/resume.
> 
> Instead of following the MSR status quo, take the opportunity to make the
> logic more generic, and in particular, trivial to extend for future MSRs.
> 
> This is done by discarding the notion of optional MSRs, and requiring the
> toolstack to be prepared to move all of the MSRs, although only a subset
> will
> typically need to move.
> 
> This allows for the use of guest_{rd,wr}msr() alone to evaluate whether
> an MSR
> needs moving.  This is a benefit because it means there is a single piece of
> logic responsible for evaluating whether a guest can use an MSR, and which
> values are acceptable.
> 
> One small adjustment to guest_wrmsr() is required to cope with being
> called in
> toolstack context.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>




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