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

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 09/10/14 17:10, Don Koch wrote:
> On Thu, 9 Oct 2014 16:56:49 +0100
> Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>
>> On 09/10/14 16:45, Don Koch wrote:
>>> On Wed, 8 Oct 2014 14:29:36 -0400
>>> Don Koch <dkoch@verizon.com> 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.

Right ok - given this info, the patch looks plausible, but these details
must be in the patch description.

Given this diagnosis, I think it is reasonable to not fail the hypercall
if we detect this condition and confirm that all unexpectedly-extra
bytes are 0.

In the case that there is a non-zero byte in there, we must fail the
hypercall to prevent VM data corruption.  The warning can be dropped for
the "fixing up from Xen 4.3" case, but a sentence of two comment in the
code will certainly be needed as justification.

~Andrew