From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1M0WPa-0002lC-9L
	for qemu-devel@nongnu.org; Sun, 03 May 2009 03:46:58 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1M0WPV-0002kW-Na
	for qemu-devel@nongnu.org; Sun, 03 May 2009 03:46:57 -0400
Received: from [199.232.76.173] (port=46606 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1M0WPV-0002kS-Jh
	for qemu-devel@nongnu.org; Sun, 03 May 2009 03:46:53 -0400
Received: from mx2.redhat.com ([66.187.237.31]:47914)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <gleb@redhat.com>) id 1M0WPV-00079x-5e
	for qemu-devel@nongnu.org; Sun, 03 May 2009 03:46:53 -0400
Date: Sun, 3 May 2009 10:46:48 +0300
From: Gleb Natapov <gleb@redhat.com>
Subject: Re: [Qemu-devel] Re: [PATCH  0/8] kvm: Fixes, cleanups and live
	migration
Message-ID: <20090503074648.GI9795@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>
	<20090503060502.GH9795@redhat.com> <49FD4996.9060606@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <49FD4996.9060606@redhat.com>
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Avi Kivity <avi@redhat.com>
Cc: Anthony Liguori <aliguori@us.ibm.com>, Jan Kiszka <jan.kiszka@web.de>, qemu-devel@nongnu.org

On Sun, May 03, 2009 at 10:36:54AM +0300, Avi Kivity wrote:
> Gleb Natapov wrote:
>>> 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.
>>
>>   
>
> Er, yes.
>
>>>                                                     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.
>>   
>
> Maybe we should unexecute the software interrupt instruction on Intel  
> and get the same effect.
>
We don't need to unexecute anything. We get exit with RIP pointing to
the offending instruction. The right thing on VMX to do is to inject
software interrupt with correct instruction length. Processor will do
the rest. Remind me please why do we try to find problems where there is
none? We will do right thing and fix migration code to do right thing.

--
			Gleb.