From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60462) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VIzdr-0008Cc-F9 for qemu-devel@nongnu.org; Mon, 09 Sep 2013 07:28:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VIzdl-0000sF-76 for qemu-devel@nongnu.org; Mon, 09 Sep 2013 07:28:27 -0400 Received: from mx1.redhat.com ([209.132.183.28]:13936) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VIzdk-0000sA-VO for qemu-devel@nongnu.org; Mon, 09 Sep 2013 07:28:21 -0400 Date: Mon, 9 Sep 2013 14:28:18 +0300 From: Gleb Natapov Message-ID: <20130909112817.GA5709@redhat.com> References: <1378386382-415-1-git-send-email-pbonzini@redhat.com> <1378386382-415-2-git-send-email-pbonzini@redhat.com> <20130908114044.GF17294@redhat.com> <522D8753.7010009@redhat.com> <20130909090315.GM17294@redhat.com> <522D9AA9.6060303@redhat.com> <20130909105450.GQ17294@redhat.com> <522DABF9.2080205@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <522DABF9.2080205@redhat.com> Subject: Re: [Qemu-devel] [PATCH uq/master 1/2] x86: fix migration from pre-version 12 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org, ehabkost@redhat.com On Mon, Sep 09, 2013 at 01:07:37PM +0200, Paolo Bonzini wrote: > >>>> In fact, another bug is that kvm_vcpu_ioctl_x86_set_xsave ignores > >>>> xstate_bv when XSAVE is not available. Instead, it should reset the > >>>> FXSAVE data to processor-reset values (except for MXCSR which always > >>>> comes from XRSTOR data), i.e. to all-zeros except for the x87 control > >>>> and tag words. It should also check reserved bits of MXCSR. > >>> > >>> I do not see why. > >> > >> Because otherwise it behaves in a subtly different manner for XSAVE and > >> non-XSAVE hosts. > > > > I do not see how. Can you elaborate? > > Suppose userspace calls KVM_SET_XSAVE with XSTATE_BV=0. > > On an XSAVE host, when the guest FPU state is loaded KVM will do an > XRSTOR. The XRSTOR will restore the FPU state to default values. > > On a non-XSAVE host, when the guest FPU state is loaded KVM will do an > FXRSTR. The FXRSTR will load the FPU state from the first 512 bytes of > the block that was passed to KVM_SET_XSAVE. > > This is not a problem because userspace will usually pass to > KVM_SET_XSAVE only something that it got from KVM_GET_XSAVE, and > KVM_GET_XSAVE will never set XSTATE_BV=0. However, KVM_SET_XSAVE is > supposed to emulate XSAVE/XRSTOR if it is not available, and it is > failing to emulate this detail. > You are trying to be bug to bug compatible :) XSTATE_BV can be zero only if FPU state is reset one, otherwise the guest will not survive. KVM_SET_XSAVE is not suppose to emulate XSAVE/XRSTOR, it is not emulator function. It is better to outlaw zero value for XSTATE_BV at all, but we cannot do it because current QEMU uses it. > >>>> Yes. QEMU unmarshals information from the XSAVE region and back, so it > >>>> cannot support MPX or AVX-512 yet (even if KVM were). Separate bug, though. > >>>> > >>> IMO this is the main issue here, not separate bug. If we gonna let guest > >>> use CPU state QEMU does not support we gonna have a bad time. > >> > >> We cannot force the guest not to use a feature; all we can do is hide > > > > Of course we can't, this is correct for other features too, but this is > > guest's problem. > > Ok, then we agree that QEMU doesn't have a problem? The XSAVE data will Which problem exactly. The problems I see is that 1. We do not support MPX and AVX-512 (but this is probably not the problem you meant :)) 2. 0D data is not consistent with features. Guest may not expect it and do stupid things. > always be "fresh" as long as the guest obeys CPUID bits it receives, and > the CPUID bits that QEMU passes will never enable XSAVE data that QEMU > does not support. > -- Gleb.