[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] XSAVE save/restore shortcomings
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |