From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:47521) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TBNBI-0002KW-3U for qemu-devel@nongnu.org; Tue, 11 Sep 2012 05:55:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TBNBC-0002x7-A3 for qemu-devel@nongnu.org; Tue, 11 Sep 2012 05:54:56 -0400 Received: from mx1.redhat.com ([209.132.183.28]:6552) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TBNBC-0002x0-0y for qemu-devel@nongnu.org; Tue, 11 Sep 2012 05:54:50 -0400 Message-ID: <504F0A64.9000306@redhat.com> Date: Tue, 11 Sep 2012 12:54:44 +0300 From: Avi Kivity MIME-Version: 1.0 References: <1347349912-15611-1-git-send-email-qemulist@gmail.com> <1347349912-15611-11-git-send-email-qemulist@gmail.com> <504EF7CC.6040900@redhat.com> 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: liu ping fan Cc: Jan Kiszka , Marcelo Tosatti , qemu-devel@nongnu.org, Anthony Liguori , Paolo Bonzini On 09/11/2012 12:44 PM, liu ping fan wrote: > On Tue, Sep 11, 2012 at 4:35 PM, Avi Kivity wrote: >> On 09/11/2012 10:51 AM, Liu Ping Fan wrote: >>> From: Liu Ping Fan >>> >>> The func call chain can suffer from recursively hold >>> qemu_mutex_lock_iothread. We introduce lockmap to record the >>> lock depth. >> >> What is the root cause? io handlers initiating I/O? >> > cpu_physical_memory_rw() can be called nested, and when called, it can > be protected by no-lock/device lock/ big-lock. Then we should look for a solution that is local to exec.c (and the nested dispatch problem). I think we can identify and fix all nested dispatches (converting them to either async dma, or letting the memory core do a single dispatch without indirection through I/O handlers). > I think without big lock, io-dispatcher should face the same issue. > As to main-loop, have not carefully consider, but at least, dma-helper > will call cpu_physical_memory_rw() with big-lock. DMA is inherently asynchronous, so we already drop the lock between initiation and completion; we need to find a way to make it easy to use the API without taking the lock while the transfer takes place. -- error compiling committee.c: too many arguments to function