From mboxrd@z Thu Jan 1 00:00:00 1970 From: Radim =?utf-8?B?S3LEjW3DocWZ?= Subject: Re: [CFT PATCH v2 2/2] KVM: x86: support XSAVES usage in the host Date: Wed, 26 Nov 2014 14:53:22 +0100 Message-ID: <20141126135322.GA4887@potion.brq.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> 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: Paolo Bonzini Return-path: Content-Disposition: inline In-Reply-To: <5475D20A.90505@redhat.com> Sender: linux-kernel-owner@vger.kernel.org List-Id: kvm.vger.kernel.org 2014-11-26 14:13+0100, Paolo Bonzini: > On 26/11/2014 13:07, Radim Kr=C4=8Dm=C3=A1=C5=99 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_XS= AVE > >> but the kernel will pass it to XRSTORS, and we need to convert bac= k. > >=20 > > Future instructions might force us to calling xsave/xrstor directly= , so > > we could do that even now and save the explicit conversion ... > >=20 > > What I mean is: we could be using the native xsave.*/xrstor.* whil= e in > > kernel and use xsave/xrstor for communication with userspace. > > Hardware would take care of everything in the conversion. > >=20 > > get_xsave =3D native_xrstor(guest_xsave); xsave(aligned_userspace_= buffer) > > set_xsave =3D xrstor(aligned_userspace_buffer); native_xsave(guest= _xsave) > >=20 > > Could that work? >=20 > It could, though it is more like >=20 > get_fpu() > native_xrstor(guest_xsave) > xsave(buffer) > put_fpu() >=20 > 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 slo= wer. 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.