From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:53772) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TEFA2-0000BG-9t for qemu-devel@nongnu.org; Wed, 19 Sep 2012 03:57:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TEFA1-0008M1-4Z for qemu-devel@nongnu.org; Wed, 19 Sep 2012 03:57:30 -0400 Received: from goliath.siemens.de ([192.35.17.28]:28120) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TEFA0-0008Lu-R3 for qemu-devel@nongnu.org; Wed, 19 Sep 2012 03:57:29 -0400 Message-ID: <50597AE0.7010406@siemens.com> Date: Wed, 19 Sep 2012 09:57:20 +0200 From: Jan Kiszka 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> In-Reply-To: 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Crosthwaite Cc: Peter Maydell , Igor Mitsyanko , Marcelo Tosatti , "qemu-devel@nongnu.org" , liu ping fan , Avi Kivity , Anthony Liguori , Paolo Bonzini , "Edgar E. Iglesias" 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. > >> >> 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 -- Siemens AG, Corporate Technology, CT RTC ITP SDP-DE Corporate Competence Center Embedded Linux