Re: XSAVE save/restore shortcomings

[Paolo Bonzini <pbonzini@redhat.com>]

Il 05/09/2013 14:01, Jan Beulich ha scritto:
>>>> On 05.09.13 at 12:53, Paolo Bonzini <pbonzini@redhat.com> wrote:
>> 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.
> 
> Then why would there be a way to retrieve these offsets via CPUID?

Perhaps Intel envisioned that the OS could blindly do XSAVEOPT on all
detected elements, including yet-unknown features.

>> 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...
> 
> For which it is too late: Both 4.2 and 4.3 already have LWP support.

Which guests are actually using it?

But in the end it doesn't really matter that AMD and Intel have
incompatible XSAVE formats, as long as each vendor remains compatible
with itself.  Again AMD is not doing new x86 development; hence, all
that you'd lose is AMD->Intel migration the day Intel implements LWP,
but only on guests that use LWP (Intel->AMD probably would be broken
anyway due to lack of AVX-512 on AMD).

Paolo