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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

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?

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