From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:60597)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <avi@redhat.com>) id 1TEJwP-0001qF-9I
	for qemu-devel@nongnu.org; Wed, 19 Sep 2012 09:03:51 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <avi@redhat.com>) id 1TEJwH-0003Xj-CJ
	for qemu-devel@nongnu.org; Wed, 19 Sep 2012 09:03:45 -0400
Received: from mx1.redhat.com ([209.132.183.28]:28363)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <avi@redhat.com>) id 1TEJwH-0003XU-0D
	for qemu-devel@nongnu.org; Wed, 19 Sep 2012 09:03:37 -0400
Message-ID: <5059C2A1.4050208@redhat.com>
Date: Wed, 19 Sep 2012 16:03:29 +0300
From: Avi Kivity <avi@redhat.com>
MIME-Version: 1.0
References: <504F1BBC.3030409@siemens.com> <504F2C80.3040803@redhat.com>
	<504F2DD6.8070807@siemens.com> <504F2EE6.8060606@redhat.com>
	<504F3021.5090802@siemens.com> <504F3113.1000708@redhat.com>
	<CAEgOgz6zEHJCE20Vtjjwq1Py8_Ux3vbH+=2U46rwp7i4HkEDHw@mail.gmail.com>
	<20120919043257.GB29439@zapo>
	<CAEgOgz4ws4+7VXiMtpgH7NG92i_twjmAGOBYyBG_nUdruzHbnA@mail.gmail.com>
	<50597A72.6030901@redhat.com> <20120919114647.GA29445@zapo>
	<5059B69C.5070302@redhat.com> <5059C221.5060606@samsung.com>
In-Reply-To: <5059C221.5060606@samsung.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH V3 10/11] vcpu: introduce lockmap
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Igor Mitsyanko <i.mitsyanko@samsung.com>
Cc: Peter Maydell <peter.maydell@linaro.org>, Jan Kiszka <jan.kiszka@siemens.com>, Marcelo Tosatti <mtosatti@redhat.com>, "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>, liu ping fan <qemulist@gmail.com>, Peter Crosthwaite <peter.crosthwaite@petalogix.com>, Anthony Liguori <anthony@codemonkey.ws>, Paolo Bonzini <pbonzini@redhat.com>, "Edgar E. Iglesias" <edgar.iglesias@gmail.com>

On 09/19/2012 04:01 PM, Igor Mitsyanko wrote:
>>> That would avoid the lockups and allow the device to be reset at
>>> any time. Or am I missing something?
>>>
>> Not that I can see.  If real hardware can be looped, so can qemu.  I'm
>> only worried about recursion and deadlocks (while real hardware can
>> deadlock, we'd prefer to avoid that).
>>
>>
> 
> So, I think the idea here is that if real hardware can be locked we
> should lock too, but provide a guest CPU a possibility to abort locked
> operation. For this particular example, SD card controller can deadlock
> on recursive descriptor LINK entries, but CPU can abort ongoing
> transaction at any time by issuing ABORT command. And if guest CPU
> busy-waits in infinite while() loop for a TRANSFER OVER flag to be set,
> then it had it coming.

If real hardware would lock up so should we (in the guest's eyes) but
the qemu monitor should remain responsive.  It is not part of emulated
hardware.


-- 
error compiling committee.c: too many arguments to function