On 12/15/21 03:39, Wang, Wei W wrote:
Why would KVM_GET_XSAVE2 still be needed in this case?
I'm thinking it would also be possible to reuse KVM_GET_XSAVE:
- If userspace calls to KVM_CHECK_EXTENSION(KVM_CAP_XSAVE2),
then KVM knows that the userspace is a new version and it works with
larger xsave buffer using the "size" that it returns via KVM_CAP_XSAVE2.
So we can add a flag "kvm->xsave2_enabled", which gets set upon
userspace checks KVM_CAP_XSAVE2.
You can use KVM_ENABLE_CAP(KVM_CAP_XSAVE2) for that, yes. In that case
you don't need KVM_GET_XSAVE2.
On more thing here, what size should KVM_CHECK_EXTENSION(KVM_CAP_XSAVE2) return?
If the size still comes from the guest CPUID(0xd, 0)::RCX, would it be better to just return 1?
This requires that the QEMU CPUID info has been set to KVM before checking the cap.
QEMU already has this CPUID info to get the size (seems no need to inquire KVM for it).
It's still easier to return the full size of the buffer from
KVM_CHECK_EXTENSION(KVM_CAP_XSAVE2). It makes the userspace code a bit
easier.
I'm also thinking that I prefer KVM_GET_XSAVE2 to
KVM_ENABLE_CAP(KVM_CAP_XSAVE2), after all. Since it would be a
backwards-incompatible change to an _old_ ioctl (KVM_GET_XSAVE), I
prefer to limit the ways that userspace can shoot itself in the foot.
Paolo
