On Wed, Dec 15 2021 at 02:17, Wei W. Wang wrote:
> On Wednesday, December 15, 2021 5:36 AM, Juan Quintela wrote:
>> >> If it needs to be done in any other order, it is completely
>> >> independent of whatever is inside the migration stream.
>> >
>> > From the migration data perspective that's correct, but I have the
>> > nagging feeling that this in not that simple.
>>
>> Oh, I was not meaning that it was simple at all.
>
> It seems to be a consensus that the ordering constraint wouldn't be
> that easy.
Right, but what is easy in this context? Not easy does not mean it is
impossible.
> Would you think that our current solution (the 3 parts shared earlier
> to do fpstate expansion at KVM_SET_XSAVE) is acceptable as the 1st
> version?
This is really the wrong question in the context of an user space ABI.
The point is that if we go and add that hack, then the hack has to be
supported forever. So there is no "as the 1st version".
I'm not at all a fan of this kind of approach because it puts the burden
at the wrong end and it carefully avoids to sit down and really think it
through.
That way we just pile hacks on hacks forever up to the point where the
hacks end up in a circular dependency which becomes unresolvable.
That's not a KVM/Qemu specific problem. That's a problem in general and
we've been bitten by that again and again.
The worst about this is that those people who try to sell their quick
and dirty hack in the first place are not those who end up dealing with
the consequences some time down the road.
Lets assume the restore order is XSTATE, XCR0, XFD:
XSTATE has everything in init state, which means the default
buffer is good enough
XCR0 has everything enabled including AMX, so the buffer is
expanded
XFD has AMX disable set, which means the buffer expansion was
pointless
If we go there, then we can just use a full expanded buffer for KVM
unconditionally and be done with it. That spares a lot of code.
Thanks,
tglx
