From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:36472) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TBOKp-00012R-8v for qemu-devel@nongnu.org; Tue, 11 Sep 2012 07:08:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TBOKo-0002VV-6O for qemu-devel@nongnu.org; Tue, 11 Sep 2012 07:08:51 -0400 Received: from thoth.sbs.de ([192.35.17.2]:21338) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TBOKn-0002VR-Ss for qemu-devel@nongnu.org; Tue, 11 Sep 2012 07:08:50 -0400 Message-ID: <504F1BBC.3030409@siemens.com> Date: Tue, 11 Sep 2012 13:08:44 +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> In-Reply-To: <504F1A8B.3080604@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 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. > >> 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. Jan -- Siemens AG, Corporate Technology, CT RTC ITP SDP-DE Corporate Competence Center Embedded Linux