From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1M0XAj-0000BL-Ks for qemu-devel@nongnu.org; Sun, 03 May 2009 04:35:41 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1M0XAe-0000Au-UU for qemu-devel@nongnu.org; Sun, 03 May 2009 04:35:40 -0400 Received: from [199.232.76.173] (port=43699 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M0XAe-0000Ar-OL for qemu-devel@nongnu.org; Sun, 03 May 2009 04:35:36 -0400 Received: from mx2.redhat.com ([66.187.237.31]:49204) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1M0XAe-0002mK-Bv for qemu-devel@nongnu.org; Sun, 03 May 2009 04:35:36 -0400 Date: Sun, 3 May 2009 11:35:31 +0300 From: Gleb Natapov Subject: Re: [Qemu-devel] Re: [PATCH 0/8] kvm: Fixes, cleanups and live migration Message-ID: <20090503083531.GK9795@redhat.com> References: <20090502172308.GA13933@redhat.com> <49FC9B39.4080408@redhat.com> <20090502200754.GB13933@redhat.com> <49FD3266.5050000@redhat.com> <20090503060502.GH9795@redhat.com> <49FD4996.9060606@redhat.com> <20090503074648.GI9795@redhat.com> <49FD4CB4.3070008@redhat.com> <20090503075646.GJ9795@redhat.com> <49FD4F5E.8010907@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49FD4F5E.8010907@redhat.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Anthony Liguori , Jan Kiszka , qemu-devel@nongnu.org On Sun, May 03, 2009 at 11:01:34AM +0300, Avi Kivity wrote: > Gleb Natapov wrote: >>> I don't want the migration protocol to encode vendor specific >>> information. The architectural state is complicated enough, we don't >>> want microarchitectural state as well. >>> >> Then I don't see how migration can work correctly. How do you expect >> migration to work if you don't migrate part of a processor state? Why >> not drop non migratable state immediately after exit then? (that is >> essentially what happens if we don't migrate it). >> > > If we can roll back the state to before the software interrupt executed, > we are never in the situation where the instruction length is needed. > Not according to Intel :) > The whole mess is needed because vmx allows exiting after a software > interrupt instruction has been executed, but before the software > interrupt was processed by the cpu. If we unexecute the instruction and > forget the software interrupt, everything will continue to work. > VMX exits with RIP pointing to software interrupt instruction (i.e before instruction execution), so no need to "unexecute" it. Intel advice to inject software interrupt as opposite to reexecute instruction. If we will not migrate information needed to inject soft interrupt we will have to reexecute it after migration. May be this is not a big deal. -- Gleb.