Re: XSAVE save/restore shortcomings

[Paolo Bonzini <pbonzini@redhat.com>]

Il 30/08/2013 12:11, Jan Beulich ha scritto:
> I'd like to make clear that the change presented is going to handle
> only the most trivial cases (where any new xsave state addition
> adds to the end of the save area). This is an effect of a more
> fundamental flaw in the original design (which the patch doesn't try
> to revise, as it's not clear to me yet what the best approach here is):
> While the XSAVE hardware specification allows for each piece to be
> individually savable/restorable, both PV and HVM save/restore
> assume a single monolithic blob. Which is already going to be a
> problem: AVX-512 as well as MPX conflict with LWP. And obviously
> it can't be excluded that we'll see CPUs supporting AVX-512 but not
> MPX as well as guests using the former but not the latter, and
> neither can be dealt with under the current design.

This should not be a problem, the manual says "The layout of the
XSAVE/XRSTOR save area is fixed and may contain non-contiguous
individual save areas.  The XSAVE/XRSTOR save area is not compacted if
some features are not saved or are not supported by the processor and/or
by system software".  Note "by the processor": the way I read this, size
may vary (which is why CPUID.0Dh exists, basically), but offsets are
guaranteed to be constant.

Thus the only problem is LWP.  Given AMD's current non-involvement in
x86, it may be simpler to avoid the problem completely by not
implementing virtual LWP...

Paolo

> I therefore think that we'll need to start over from scratch with
> how save/restore is to be implemented, breaking up the current
> monolithic block into individual pieces. But before working on a
> proposal, I'd first like to hear whether others can see better (and
> namely less intrusive) ways of dealing with the problem.
> 
> Jan
>