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

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

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.

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


Best regards,
Yang



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