Re: [Xen-devel] XSAVE save/restore shortcomings

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 05.09.13 at 15:58, Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote:
> Il 05/09/2013 14:01, Jan Beulich ha scritto:
>>>>> On 05.09.13 at 12:53, Paolo Bonzini <pbonzini@xxxxxxxxxx> 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.

For that all you'd need would be the total size, not the individual
offsets.

>>> 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?

Who knows what guests (particularly HVM ones) use?

> 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).

Yes, if Intel is going to confirm that the layout is going to be fixed
now and forever, I'll tell them that's an awful design (along the
lines of them requiring a 32-bit OS to enable XCR0[7] in order to
use AVX-512, no matter that the guest can't possibly make use of
these registers, and thus the tail half or so of the save area will
remain entirely unused, but needs to be allocated), but we might
indeed get along without redesign as long as we e.g. don't care
about (or allow) migration between LWP-capable and LWP-incapable
hosts.

Jan


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