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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 06.09.13 at 05:03, "Zhang, Yang Z" <yang.z.zhang@xxxxxxxxx> wrote:
> Jan Beulich wrote on 2013-09-05:
>>>>> 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.
> Agree. If the offset is fixed (it is true currently), then CPU don't need to 
> expose the offset through CPUID. It may vary for future feature.

So here we are: Paolo quotes the doc stating that the layout is fixed
(and I agree with his interpretation of that statement), and an Intel
representative states that "it is true currently". And the fact that the
offsets are to be retrieved also suggests that they're not fixed now
and forever (supported by Vol 3 section 13.6 reading "The number of
save areas, the offset and the size of each save area is enumerated
by CPUID leaf function 0DH").

Looks like the documentation isn't really consistent in itself...

Jan


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