Re: [Xen-devel] [RFC PATCH] Drop error return if size mismatch is due to xcr0 settings

[Don Koch <dkoch@xxxxxxxxxxx>]

On Thu, 9 Oct 2014 16:56:49 +0100
Andrew Cooper <andrew.cooper3@xxxxxxxxxx> wrote:

> On 09/10/14 16:45, Don Koch wrote:
> > On Wed, 8 Oct 2014 14:29:36 -0400
> > Don Koch <dkoch@xxxxxxxxxxx> wrote:
> >
> >> This prevents migration from 4.3 to 4.4 (or newer) xen on AMD machines, at
> >> least.
> > A clarification: a previous change made migration from xen 4.3 to 4.4 on AMD
> > machine fail. This patch provides a (minimal) fix for the problem. IMO, it 
> > should
> > be targeted for 4.5 and 4.4.x (whatever the next 'x' is).
> >
> > If it's decided to add the other changes I've suggested, those could be 
> > provided
> > in a separate patch, especially if we're time constrained (like for getting 
> > it
> > into 4.5).
> >
> > -d
> 
> Can you explain what the bug is and why this is an appropriate fix?
> 
> What is happening here is that the migration stream is providing an
> xsave area larger than the size it should be based on the xcr0 sent with it.

The old 4.3 system is providing a maximum size xsave area. The 4.4 xen
is calculating a smaller area required for said xsave area. All this means
is that the overflow at the end is meaningless and can be ignored (i.e.
restoring it shouldn't hurt).  If the data sent was smaller than what was
expected, i.e. something is missing, that would be an error.

I consider leaving the check and warning message useful as it allows
some debugging info if there indeed was something wrong. I tested this
on an AMD migrating from 4.3 to 4.4 and checking various ymm registers
with no data lost.

> This means that either the sending Xen sent a bogus record, or the new
> Xen has incorrectly calculated the size from xcr0, but *both* of these
> cases are potential VM data corruption issues.
> 
> As this currently stands with no analysis of the problem and proof as to
> why the change is safe, dropping the "return -EOPNOTSUPP;" is not valid IMO.
> 
> ~Andrew

Not having some sort of fix for this problem means a flag day for anyone
running on AMD.

Thanks,
-d


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