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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
