From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:40168) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TEJDd-0006zD-TJ for qemu-devel@nongnu.org; Wed, 19 Sep 2012 08:17:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TEJDX-00030h-Qc for qemu-devel@nongnu.org; Wed, 19 Sep 2012 08:17:29 -0400 Received: from mail-lb0-f173.google.com ([209.85.217.173]:40372) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TEJDX-0002zT-IH for qemu-devel@nongnu.org; Wed, 19 Sep 2012 08:17:23 -0400 Received: by lbbgm13 with SMTP id gm13so744785lbb.4 for ; Wed, 19 Sep 2012 05:17:22 -0700 (PDT) Date: Wed, 19 Sep 2012 14:17:10 +0200 From: "Edgar E. Iglesias" Message-ID: <20120919121710.GB29445@zapo> References: <504F2DD6.8070807@siemens.com> <504F2EE6.8060606@redhat.com> <504F3021.5090802@siemens.com> <504F3113.1000708@redhat.com> <20120919043257.GB29439@zapo> <50597A72.6030901@redhat.com> <20120919114647.GA29445@zapo> <5059B69C.5070302@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5059B69C.5070302@redhat.com> Subject: Re: [Qemu-devel] [PATCH V3 10/11] vcpu: introduce lockmap List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Peter Maydell , Igor Mitsyanko , Jan Kiszka , Marcelo Tosatti , "qemu-devel@nongnu.org" , liu ping fan , Peter Crosthwaite , Anthony Liguori , Paolo Bonzini On Wed, Sep 19, 2012 at 03:12:12PM +0300, Avi Kivity wrote: > On 09/19/2012 02:46 PM, Edgar E. Iglesias wrote: > > On Wed, Sep 19, 2012 at 10:55:30AM +0300, Avi Kivity wrote: > >> 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? > > > > I think we were discussing the loop issue (I hadn't thought of recursion > > issues before) :) > > > > Jan's point of resetability was interesting. > > > > Processing a finite amount of dma descriptors and scheduling bh's > > to continously get back and continue processing should be OK no? > > > > Yes. > > > 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). Agreed, thanks