From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:53391) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TEF8O-0007VY-D3 for qemu-devel@nongnu.org; Wed, 19 Sep 2012 03:55:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TEF8I-0007jx-43 for qemu-devel@nongnu.org; Wed, 19 Sep 2012 03:55:48 -0400 Received: from mx1.redhat.com ([209.132.183.28]:63491) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TEF8H-0007jt-RA for qemu-devel@nongnu.org; Wed, 19 Sep 2012 03:55:42 -0400 Message-ID: <50597A72.6030901@redhat.com> Date: Wed, 19 Sep 2012 10:55:30 +0300 From: Avi Kivity 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 , Jan Kiszka , Marcelo Tosatti , "qemu-devel@nongnu.org" , liu ping fan , Anthony Liguori , Paolo Bonzini , "Edgar E. Iglesias" On 09/19/2012 07:40 AM, 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. You could schedule a bottom half and do the accesses from there. Solves nothing though. > 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. Did you mean loop, or recursion into the memory region that initiates DMA? As this problem already exists I don't think new device models need block on it. Maybe a simple fix is: void my_device_write(...) { if (dma_in_progress) { return; } ... s->dma_in_progress = true; cpu_physical_memory_rw(...) s->dma_in_progress = false; } and we could try to figure out how to move this into common code. -- error compiling committee.c: too many arguments to function