From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:39528) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TEK0e-0004Iq-IK for qemu-devel@nongnu.org; Wed, 19 Sep 2012 09:08:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TEK0U-00067Z-PM for qemu-devel@nongnu.org; Wed, 19 Sep 2012 09:08:08 -0400 Received: from mailout3.w1.samsung.com ([210.118.77.13]:60829) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TEK0U-00067D-JD for qemu-devel@nongnu.org; Wed, 19 Sep 2012 09:07:58 -0400 Received: from eusync3.samsung.com (mailout3.w1.samsung.com [210.118.77.13]) by mailout3.w1.samsung.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTP id <0MAL00IR5LU2EU10@mailout3.w1.samsung.com> for qemu-devel@nongnu.org; Wed, 19 Sep 2012 14:08:26 +0100 (BST) Received: from [106.109.9.185] by eusync3.samsung.com (Oracle Communications Messaging Server 7u4-23.01(7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPA id <0MAL00849LT6IZ50@eusync3.samsung.com> for qemu-devel@nongnu.org; Wed, 19 Sep 2012 14:07:55 +0100 (BST) Message-id: <5059C3AA.6030608@samsung.com> Date: Wed, 19 Sep 2012 17:07:54 +0400 From: Igor Mitsyanko MIME-version: 1.0 References: <504F0A64.9000306@redhat.com> <504F0CA5.5030405@siemens.com> <504F1A8B.3080604@redhat.com> <504F1BBC.3030409@siemens.com> <504F2C80.3040803@redhat.com> <504F2DD6.8070807@siemens.com> <504F2EE6.8060606@redhat.com> <504F3021.5090802@siemens.com> <504F3113.1000708@redhat.com> <20120919043257.GB29439@zapo> <50597AE0.7010406@siemens.com> In-reply-to: <50597AE0.7010406@siemens.com> Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit Subject: Re: [Qemu-devel] [PATCH V3 10/11] vcpu: introduce lockmap List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: Peter Maydell , Marcelo Tosatti , "qemu-devel@nongnu.org" , liu ping fan , Peter Crosthwaite , Avi Kivity , Anthony Liguori , Paolo Bonzini , "Edgar E. Iglesias" On 09/19/2012 11:57 AM, Jan Kiszka wrote: > On 2012-09-19 06:40, Peter Crosthwaite wrote: >> On Wed, Sep 19, 2012 at 2:32 PM, Edgar E. Iglesias >> wrote: >>> On Wed, Sep 19, 2012 at 02:25:48PM +1000, Peter Crosthwaite wrote: >>>> Ping for PMM, >>>> >>>> This is the root case of your block on the SDHCI series - this is a >>>> discussion on resolution to bogus infinite looping DMA. For current >>>> participants in this discussion, heres our thread on the same topic >>>> over in SD land: >>>> >>>> http://lists.gnu.org/archive/html/qemu-devel/2012-08/msg01017.html >>>> >>>> With the findings here and acknowledgement that this is a general >>>> problem, we either need to declare this issue of scope for SDHCI, or >>>> work with these guys (in the immediate future) on the DMA infinite >>>> loop problem flagged here. I dont mind if SDHCI+ADMA is the guinea pig >>>> here, but can we get a decisive plan for going forward with this issue >>>> if it is going to continue to block SDHCI. >>>> >>>> Thanks to Igor for identifying the overlap between these discussions. >>> Hi, >>> >>> A couple of dumb questions. >>> >>> What is the reason for the blocker? that possible guest dos is worse >>> than no functionality at all? >>> >>> Can't you put the DMA/IO processing into the background? >> I dont know a way do do asynchronous DMA unless I am missing something >> here. So what happens is we have a device that walks a SG list >> synchronously while holding all the locks and stuff being discussed >> here. If that SG list infinite loops then crash. > We could switch to async DMA, but most DMA-capable devices aren't > prepared for rescheduling points in the middle of their code. This will > require quite a bit of code review. From what I understand, we can't switch to async DMA while SD card model doesn't support it. And introducing this support would require to convert every existing SD card user in QEMU. I can recall that such a conversion was already suggested in a mailing list a while ago, but no one (including me) volunteered to do it :) >>> what's the diff between setup of bad descriptors and writing a >>> while (1) loop in the guest CPU? >>> >> While(1) in guest doesnt freeze all of QEMU (monitor still works and >> stuff), wheras the DMA ops going in circles does, as locks are taken >> by an infinite loop. > That's the point. If we loop, we need at least a way to stop it by > issuing a device or system reset. But I tend to think that detecting > loops and failing/ignoring requests is easier implementable. > > Jan >