2014-11-26 14:13+0100, Paolo Bonzini: > On 26/11/2014 13:07, Radim Krčmář wrote: > > 2014-11-24 17:43+0100, Paolo Bonzini: > >> Userspace is expecting non-compacted format for KVM_GET_XSAVE, but > >> struct xsave_struct might be using the compacted format. Convert > >> in order to preserve userspace ABI. > >> > >> Likewise, userspace is passing non-compacted format for KVM_SET_XSAVE > >> but the kernel will pass it to XRSTORS, and we need to convert back. > > > > Future instructions might force us to calling xsave/xrstor directly, so > > we could do that even now and save the explicit conversion ... > > > > What I mean is: we could be using the native xsave.*/xrstor.* while in > > kernel and use xsave/xrstor for communication with userspace. > > Hardware would take care of everything in the conversion. > > > > get_xsave = native_xrstor(guest_xsave); xsave(aligned_userspace_buffer) > > set_xsave = xrstor(aligned_userspace_buffer); native_xsave(guest_xsave) > > > > Could that work? > > It could, though it is more like > > get_fpu() > native_xrstor(guest_xsave) > xsave(buffer) > put_fpu() > > and vice versa. Also, the userspace buffer is mos likely not aligned, > so you need some kind of bounce buffer. It can be done if the CPUID > turns out to be a bottleneck, apart from that it'd most likely be slower. Yeah, it was mostly making this code more future-proof ... it is easier to convince xsave.h to export its structures if CPUID is the problem. (I still see some hope for Linux, so performance isn't my primary goal.) I'm quite interested in CPUID now though, so I'll try to benchmark it, someday. -- 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
