[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

>>> 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.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.