On 26/11/2014 15:42, Radim Krčmář wrote: > 2014-11-26 14:57+0100, Paolo Bonzini: >> >> >> On 26/11/2014 14:53, Radim Krčmář wrote: >>>>>>> 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. > > (Sorry, I don't fully understand your thoughts and I just talk more of > the same in those scenarios.) > >> I'm not sure what is more future proof. :) I wonder if native_xrstor >> could be a problem the day XRSTORS actually sets/restores MSRs as the >> processor documentation promises. > > XRSTORS won't affect the guest in any way, we are just going to use it > to convert the xsave, so any side-effects are going to stay in the host. > (This could break the host though.) Yes, that's the problem. :) > My main presumption is that XSAVE*->XRSTOR*->XSAVE->XRSTOR has the same > result as XSAVE->XRSTOR, because we are only interested in the state, > not in any metadata. > (If it isn't possible to combine intructions, like XSAVE after XRSTORS, > this solution won't work.) Yes, that should be right. But actually what KVM would do it is XRSTOR->XSAVE*->XRSTOR*->XSAVE. The problem here is the side effects of doing XRSTORS far from a guest entry... though that would likely be handled by load_guest_fpu/put_guest_fpu. -- 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
