From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:43736) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TBPXc-0001oD-4o for qemu-devel@nongnu.org; Tue, 11 Sep 2012 08:26:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TBPXW-0002wt-B0 for qemu-devel@nongnu.org; Tue, 11 Sep 2012 08:26:08 -0400 Received: from goliath.siemens.de ([192.35.17.28]:32937) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TBPXW-0002wf-1Z for qemu-devel@nongnu.org; Tue, 11 Sep 2012 08:26:02 -0400 Message-ID: <504F2DD6.8070807@siemens.com> Date: Tue, 11 Sep 2012 14:25:58 +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> <504F0CA5.5030405@siemens.com> <504F1A8B.3080604@redhat.com> <504F1BBC.3030409@siemens.com> <504F2C80.3040803@redhat.com> In-Reply-To: <504F2C80.3040803@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 14:20, Avi Kivity wrote: > On 09/11/2012 02:08 PM, Jan Kiszka wrote: >> On 2012-09-11 13:03, Avi Kivity wrote: >>> On 09/11/2012 01:04 PM, Jan Kiszka wrote: >>> >>>>> 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. >>> >>> Most DMA today happens without the big qemu lock. We only need to >>> convert the paths that actually access memory, these are the block and >>> network layers (for the respective devices). >> >> ...and the devices themselves, of course. > > Right, for descriptors and stuff. So a guest can set a DMA address to > point at its own BAR, and cause qemu to deadlock. > > The problem is not limited to locking. A guest can also cause a write > to a BAR to initiate a synchronous write with the same address and data, > triggering infinite recursion. > > Perhaps one fix is the mythical DMA API, which will provide each DMA > initiator with its own view of memory (a private MemoryRegion root > node). Even that can be worked around with a pair of devices accessing > each other. Hmm, don't see an alternative to runtime loop detection yet. > >> >>> >>>> 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. >>> >>> How do you handle failures? >> >> By not sending a network frame or dropping an incoming one, e.g., and >> signaling this in a device specific way. > > Doesn't work for block devices. Because the block layer API cannot report errors to the devices? What happens if there is a real I/O error? Jan -- Siemens AG, Corporate Technology, CT RTC ITP SDP-DE Corporate Competence Center Embedded Linux