Re: [Qemu-devel] XSAVES in GET_SUPPORTED_CPUID (was Re: [PATCH] target-i386: add Skylake-Client cpu mode)

[Paolo Bonzini <pbonzini@redhat.com>]

On 03/05/2016 19:53, Dave Hansen wrote:
> The guest's use of XSAVES is completely independent of what instructions
> the host (kernel) uses for its xsave buffer.
> 
> For instance, just because the kernel doesn't use XSAVES to context
> switch Processor Trace, it does not make Processor Trace unusable to a
> guest.  Guests are still free to do what they want with it (including
> using XSAVES for its MSRs too btw...).

True.  In addition, there are other considerations to make:

1) right now, KVM is *not* planning to use XSAVES to marshal/unmarshal
MSRs out of the hypervisor and back in.  Instead it will use
KVM_GET_MSR/KVM_SET_MSR.  This is for at least two reasons.  First,
because KVM_GET_XSAVE/KVM_SET_XSAVE is still using the non-compacted
XSAVE/XSAVEOPT format and there's simply no room (as far as I
understasnd) for supervisor state save components in the non-compacted
format.  Second, because QEMU anway doesn't like treating the XSAVE area
as a black box so we'd be parsing the fields around
KVM_GET_XSAVE/KVM_SET_XSAVE.

2) KVM doesn't yet expose any XSAVES state save component, and the only
one defined in Skylake (processor tracing) probably will block migration
and will have to be added separately.


Item number 1 means that it is particularly easy to re-enable XSAVES for
guests only (and Dave's proposal later in the threaad sounds great).

Item number 2 on the other hand means that it's okay to add Skylake CPU
models without XSAVES.  Because of the large number of kernels in the
wild that block XSAVES, I'm inclined to do that.

Thanks,

Paolo