From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:48331) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TEJ8n-00047E-M1 for qemu-devel@nongnu.org; Wed, 19 Sep 2012 08:12:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TEJ8d-0008JM-R7 for qemu-devel@nongnu.org; Wed, 19 Sep 2012 08:12:29 -0400 Received: from mx1.redhat.com ([209.132.183.28]:4826) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TEJ8d-0008JF-IR for qemu-devel@nongnu.org; Wed, 19 Sep 2012 08:12:19 -0400 Message-ID: <5059B69C.5070302@redhat.com> Date: Wed, 19 Sep 2012 15:12:12 +0300 From: Avi Kivity 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> <20120919043257.GB29439@zapo> <50597A72.6030901@redhat.com> <20120919114647.GA29445@zapo> In-Reply-To: <20120919114647.GA29445@zapo> 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: "Edgar E. Iglesias" Cc: Peter Maydell , Igor Mitsyanko , Jan Kiszka , Marcelo Tosatti , "qemu-devel@nongnu.org" , liu ping fan , Peter Crosthwaite , Anthony Liguori , Paolo Bonzini 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). -- error compiling committee.c: too many arguments to function