From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1M0Wdv-00082j-7Y for qemu-devel@nongnu.org; Sun, 03 May 2009 04:01:47 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1M0Wdp-00082E-8X for qemu-devel@nongnu.org; Sun, 03 May 2009 04:01:45 -0400 Received: from [199.232.76.173] (port=41168 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M0Wdp-00082B-3h for qemu-devel@nongnu.org; Sun, 03 May 2009 04:01:41 -0400 Received: from mx2.redhat.com ([66.187.237.31]:38107) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1M0Wdo-0008R0-Gi for qemu-devel@nongnu.org; Sun, 03 May 2009 04:01:40 -0400 Message-ID: <49FD4F5E.8010907@redhat.com> Date: Sun, 03 May 2009 11:01:34 +0300 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH 0/8] kvm: Fixes, cleanups and live migration References: <20090502074041.GB7198@redhat.com> <49FC4F90.1030901@codemonkey.ws> <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> In-Reply-To: <20090503075646.GJ9795@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gleb Natapov Cc: Anthony Liguori , Jan Kiszka , qemu-devel@nongnu.org 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. 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. -- error compiling committee.c: too many arguments to function