From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35346) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VIzvg-0007R8-0G for qemu-devel@nongnu.org; Mon, 09 Sep 2013 07:46:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VIzvZ-0005Xj-IV for qemu-devel@nongnu.org; Mon, 09 Sep 2013 07:46:51 -0400 Received: from mx1.redhat.com ([209.132.183.28]:46859) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VIzvZ-0005Xc-AO for qemu-devel@nongnu.org; Mon, 09 Sep 2013 07:46:45 -0400 Message-ID: <522DB529.4000001@redhat.com> Date: Mon, 09 Sep 2013 13:46:49 +0200 From: Paolo Bonzini MIME-Version: 1.0 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> <20130909112817.GA5709@redhat.com> In-Reply-To: <20130909112817.GA5709@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: Gleb Natapov Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org, ehabkost@redhat.com Il 09/09/2013 13:28, Gleb Natapov ha scritto: >> 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. Yes. > 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. I agree it'd be better to forbid it. If the mismatch in semantics does not bother you, I won't fix it. It slightly bothers me. :) >>>>>> 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. It is not a problem to unmarshal information out of KVM_GET_XSAVE data (and back). If the guest does stupid things, it's a bug in an ill-behaving guest. On the other hand, I agree that passthrough of host 0xD data is bad and will fix it. Paolo >> 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. >