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

[Paolo Bonzini <pbonzini@xxxxxxxxxx>]

Il 06/09/2013 14:35, Jan Beulich ha scritto:
>>>> On 06.09.13 at 13:57, Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote:
>> Linux publishes the XSAVE blob to userspace as an NT_X86_XSTATE note in
>> core dumps, but does not include CPUID data.  If offsets change, it will
>> not be possible to examine a core dump without knowing the processor on
>> which it was produced.
> 
> Design mistake.

Perhaps, but...

>> For our beloved hypervisors, if offsets can change it will be
>> _impossible_ to migrate from a machine to another if they have different
>> offsets.  It will be impossible (lest you disable XSAVE and thus all
>> processor features starting with AVX) to have clusters of heterogeneous
>> virtualization hosts.  This is because (a) the guest might have stored
>> XSAVE areas at arbitrary places in the source, and the destination will
>> not be able to restore them; (b) there are no vmexits for
>> XSAVE/XSAVEOPT/XRSTOR, and anyway they would be too slow.
> 
> No, this is precisely what this thread is about: Migration can work
> with the offsets varying, but only if the there's no attempt to save
> the whole blob in one go. There needs to be a save record per
> state component, and that save record needs to include (implicitly
> or explicitly) include the size of that blob; the offset within the
> save area is of no interest then - the consuming system simply
> needs to put it at the offset within its save area that corresponds
> to the respective state component.

... this is not about migration of the current XSAVE state.  The guest
is storing XSAVE data in the internal structures for its processes.  If
offsets change, it won't be able to XRSTOR it on the destination.

Paolo

> The fact that we're currently dependent on the offsets is again a
> design flaw.
> 
>> So please Intel, pretty please do not modify the XSAVE offsets, and
>> clarify this as soon as possible.
> 
> I'd like to ask for the exact opposite: Drop any mention of specific
> numbers from the documentation, except when used as an
> example for a particular implementation (it's that, btw, how I
> interpret the numbers given in the AVX-512 spec). Not allowing
> compaction is going to be harmful sooner or later (as processors
> show up that implement new state, but may not implement all
> previous features, namely if some of them turn out to be relatively
> useless: AMD's LWP appears to be an example of such a feature,
> at least judging by - as you alluded to - no OS actually making use
> of it by now, and at least some people seem to think of MPX as
> being pretty useless too).
> 
> Jan
> 


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