From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1M0Up5-0001CY-BL for qemu-devel@nongnu.org; Sun, 03 May 2009 02:05:11 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1M0Up0-0001Bn-Mk for qemu-devel@nongnu.org; Sun, 03 May 2009 02:05:10 -0400 Received: from [199.232.76.173] (port=38723 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M0Up0-0001Bk-K5 for qemu-devel@nongnu.org; Sun, 03 May 2009 02:05:06 -0400 Received: from mx2.redhat.com ([66.187.237.31]:47031) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1M0Up0-0007Dx-29 for qemu-devel@nongnu.org; Sun, 03 May 2009 02:05:06 -0400 Date: Sun, 3 May 2009 09:05:02 +0300 From: Gleb Natapov Subject: Re: [Qemu-devel] Re: [PATCH 0/8] kvm: Fixes, cleanups and live migration Message-ID: <20090503060502.GH9795@redhat.com> References: <20090501211717.24514.23246.stgit@mchn012c.ww002.siemens.net> <49FB7A40.1020005@us.ibm.com> <20090502074041.GB7198@redhat.com> <49FC4F90.1030901@codemonkey.ws> <20090502172308.GA13933@redhat.com> <49FC9B39.4080408@redhat.com> <20090502200754.GB13933@redhat.com> <49FD3266.5050000@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49FD3266.5050000@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 08:57:58AM +0300, Avi Kivity wrote: > Gleb Natapov wrote: >> On Sat, May 02, 2009 at 10:12:57PM +0300, Avi Kivity wrote: >> >>> Gleb Natapov wrote: >>> >>>>> I think the right thing to do with this is introduce a kvm-cpu >>>>> savevm that stores this information since it isn't relevant to >>>>> TCG. I think it's arguable whether you want instruction length >>>>> there (can you get it reliably on SVM?). >>>>> >>>>> >>>> We can't get it on SVM without instruction decoding, but it is not required >>>> on SVM. It is absolutely essential for soft interrupt/exception injection >>>> on VMX and has to be a part of migratable state. >>>> >>> We need it in some neutral form so cross-vendor migration can work. >>> >>> >> VMX->SVM No problem. >> SVM->VMX bad luck :) We will have to decode instruction ourself. > > I don't think it's necessary. We can record the software interrupt at > the end of the instruction that generated it, and give it higher > priority than a pending external interrupt. On vmx, decrement RIP and > set entry instruction length = 1 before injection. And get wrong error value when exception happens during soft interrupt delivery? I don't like all those tricks. They work only if everything happens like you expected and breaks completely when it is not. > On svm, use EVENTINJ > and forget about the instruction length. > On SVM we do not re-inject soft int/exception at all, but re-execute the offending instruction. -- Gleb.