From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Bonzini Subject: Re: [CFT PATCH v2 2/2] KVM: x86: support XSAVES usage in the host Date: Wed, 26 Nov 2014 17:26:56 +0100 Message-ID: <5475FF50.4030400@redhat.com> References: <1416847414-22253-1-git-send-email-pbonzini@redhat.com> <1416847414-22253-3-git-send-email-pbonzini@redhat.com> <20141126120753.GA31982@potion.redhat.com> <5475D20A.90505@redhat.com> <20141126135322.GA4887@potion.brq.redhat.com> <5475DC30.4010104@redhat.com> <20141126144252.GB4887@potion.brq.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org, wanpeng.li@linux.intel.com, namit@cs.technion.ac.il, hpa@linux.intel.com, Fenghua Yu To: =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= Return-path: In-Reply-To: <20141126144252.GB4887@potion.brq.redhat.com> Sender: linux-kernel-owner@vger.kernel.org List-Id: kvm.vger.kernel.org On 26/11/2014 15:42, Radim Kr=C4=8Dm=C3=A1=C5=99 wrote: > 2014-11-26 14:57+0100, Paolo Bonzini: >> >> >> On 26/11/2014 14:53, Radim Kr=C4=8Dm=C3=A1=C5=99 wrote: >>>>>>> get_xsave =3D native_xrstor(guest_xsave); xsave(aligned_usersp= ace_buffer) >>>>>>> set_xsave =3D xrstor(aligned_userspace_buffer); native_xsave(g= uest_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 ali= gned, >>>>> so you need some kind of bounce buffer. It can be done if the CP= UID >>>>> 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 ea= sier >>> to convince xsave.h to export its structures if CPUID is the proble= m. >>> (I still see some hope for Linux, so performance isn't my primary g= oal.) >>> >>> I'm quite interested in CPUID now though, so I'll try to benchmark = it, >>> someday. >=20 > (Sorry, I don't fully understand your thoughts and I just talk more o= f > the same in those scenarios.) >=20 >> I'm not sure what is more future proof. :) I wonder if native_xrsto= r >> could be a problem the day XRSTORS actually sets/restores MSRs as th= e >> processor documentation promises. >=20 > XRSTORS won't affect the guest in any way, we are just going to use i= t > to convert the xsave, so any side-effects are going to stay in the ho= st. > (This could break the host though.) Yes, that's the problem. :) > My main presumption is that XSAVE*->XRSTOR*->XSAVE->XRSTOR has the sa= me > 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 XRSTOR= S, > 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 o= f doing XRSTORS far from a guest entry... though that would likely be handled by load_guest_fpu/put_guest_fpu.