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

["Zhang, Yang Z" <yang.z.zhang@xxxxxxxxx>]

Jan Beulich wrote on 2013-09-06:
>>>> 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
Layout is not equal to the offset.

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


Best regards,
Yang



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