Re: [Xen-devel] [PATCH v2] Sanity check xsave area when migrating or restoring from older Xen verions

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 20.10.14 at 14:54, <dkoch@xxxxxxxxxxx> wrote:
> On Mon, 20 Oct 2014 11:21:49 +0100
> Jan Beulich <JBeulich@xxxxxxxx> wrote:
> 
>> >>> On 18.10.14 at 01:36, <andrew.cooper3@xxxxxxxxxx> wrote:
>> > On 17/10/2014 18:11, Don Koch wrote:
>> >> +
>> >> +        /* Check to see if the xsave_area is the maximum size.
>> >> +           If so, it is likely the save is from an older xen. */
>> >> +        cpuid_count(XSTATE_CPUID, 0, &eax, &ebx, &ecx, &edx);
>> > 
>> > This check is bogus for heterogeneous hardware.  We have no way of 
>> > calculating what the maximum xsave area size was on the sending side 
>> > should have been...
>> 
>> Actually we have a way, using the xfeature_mask field that you
>> made being ignored a while back. And I think applying sanity
>> checks where they can be applied is a good thing. But of course
>> we can't blindly compare against the full size found on the receiving
>> host. We could get the size from xstate_ctxt_size() unless the
>> sending host had features we don't have, in which case we'd need
>> to resort to manually calculating the value.
> 
> It was (sort of) checked in an earlier test:
>     size = HVM_CPU_XSAVE_SIZE(xfeature_mask);
>     if ( desc->length > size )

No, that's not checking incoming state's consistency, but whether
it fits in what the receiving side can handle. An eventual
consistency check would need to use the incoming record's
xfeature_mask field.

> I suppose we could skip the check as the only other possibility is that
> the block sent is larger than what the current architecture can handle
> and, if it's all zero, it won't matter (at least in the xsave area).

With the model change that you're proposing we actually _need_ to
have a way to also bypass this check, as now what is arriving may
be legitimately larger than what our own possible biggest save area
might be.

Jan


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