From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54652) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VIzBG-0006MV-Ns for qemu-devel@nongnu.org; Mon, 09 Sep 2013 06:58:55 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VIzBG-000164-06 for qemu-devel@nongnu.org; Mon, 09 Sep 2013 06:58:54 -0400 Received: from mx1.redhat.com ([209.132.183.28]:34097) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VIzBF-00015w-O4 for qemu-devel@nongnu.org; Mon, 09 Sep 2013 06:58:53 -0400 Date: Mon, 9 Sep 2013 13:58:49 +0300 From: Gleb Natapov Message-ID: <20130909105849.GR17294@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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130909105450.GQ17294@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:54:50PM +0300, Gleb Natapov wrote: > On Mon, Sep 09, 2013 at 11:53:45AM +0200, Paolo Bonzini wrote: > > Il 09/09/2013 11:03, Gleb Natapov ha scritto: > > > On Mon, Sep 09, 2013 at 10:31:15AM +0200, Paolo Bonzini wrote: > > >> Il 08/09/2013 13:40, Gleb Natapov ha scritto: > > >>> On Thu, Sep 05, 2013 at 03:06:21PM +0200, Paolo Bonzini wrote: > > >>>> On KVM, the KVM_SET_XSAVE would be executed with a 0 xstate_bv, > > >>>> and not restore anything. > > >>>> > > >>> XRSTOR restores FP/SSE state to reset state if no bits are set in > > >>> xstate_bv. This is what should happen on reset, no? > > >> > > >> Yes. The problem happens on the migration destination when XSAVE data is > > >> not transmitted. FP/SSE data is transmitted and must be restored, but > > >> xstate_bv is zero and KVM_SET_XSAVE restores FP/SSE state to reset > > >> state. The vcpu then loses the values that were set in the migration data. > > >> > > >>>> Since FP and SSE data are always valid, set them in xstate_bv at reset > > >>>> time. In fact, that value is the same that KVM_GET_XSAVE returns on > > >>>> pre-XSAVE hosts. > > >>> It is needed for migration between non xsave host to xsave host. > > >> > > >> Yes, and this patch does the same for migration between non-XSAVE QEMU > > >> and XSAVE QEMU. > > >> > > > Can such migration happen? The commit that added xsave support > > > (f1665b21f16c5dc0ac37de60233a4975aff31193) changed vmstate version id. > > > > Yes, old->new migration can happen. New->old of course cannot. > > > I see. I am fine with the patch, but please drop defines that are not > used in the patch itself. > BTW migration question, will xstate_bv no be zeroed by migration code in old->new case? -- Gleb.