From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:33428) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TBNKZ-0005kk-Nq for qemu-devel@nongnu.org; Tue, 11 Sep 2012 06:04:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TBNKV-0006cO-Gd for qemu-devel@nongnu.org; Tue, 11 Sep 2012 06:04:31 -0400 Received: from goliath.siemens.de ([192.35.17.28]:31283) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TBNKV-0006cB-6y for qemu-devel@nongnu.org; Tue, 11 Sep 2012 06:04:27 -0400 Message-ID: <504F0CA5.5030405@siemens.com> Date: Tue, 11 Sep 2012 12:04:21 +0200 From: Jan Kiszka 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> <504F0A64.9000306@redhat.com> In-Reply-To: <504F0A64.9000306@redhat.com> 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: Avi Kivity Cc: Paolo Bonzini , Marcelo Tosatti , liu ping fan , Anthony Liguori , "qemu-devel@nongnu.org" On 2012-09-11 11:54, Avi Kivity wrote: > 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. We will have to review/rework device models that want to use the new locking scheme in a way that they can drop their own lock while issuing DMA. But that is surely non-trivial. The other option is to keep DMA requests issued by devices synchronous but let them fail if we are about to lock up. Still requires changes, but is probably more comprehensible for device model developers. Jan -- Siemens AG, Corporate Technology, CT RTC ITP SDP-DE Corporate Competence Center Embedded Linux