From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44570) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VJ5oO-0003F9-RN for qemu-devel@nongnu.org; Mon, 09 Sep 2013 14:03:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VJ5oJ-0002rt-HA for qemu-devel@nongnu.org; Mon, 09 Sep 2013 14:03:44 -0400 Received: from mail-qa0-x231.google.com ([2607:f8b0:400d:c00::231]:53541) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VJ5oJ-0002rp-Ch for qemu-devel@nongnu.org; Mon, 09 Sep 2013 14:03:39 -0400 Received: by mail-qa0-f49.google.com with SMTP id hu16so378837qab.8 for ; Mon, 09 Sep 2013 11:03:39 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <522E0D7D.7090600@redhat.com> Date: Mon, 09 Sep 2013 20:03:41 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1378732537.3072.49.camel@localhost.localdomain> <1378733344.3072.58.camel@localhost.localdomain> <1378735459.3072.83.camel@localhost.localdomain> <1378738262.3072.99.camel@localhost.localdomain> <20130909160014.GH1930@redhat.com> <20130909163422.GI1930@redhat.com> <522DFD61.10506@siemens.com> <522E00CE.9050400@siemens.com> <522E0514.1070803@siemens.com> In-Reply-To: <522E0514.1070803@siemens.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH RFC v2 2/2] hw/pci: handle unassigned pci addresses List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: Peter Maydell , Anthony Liguori , "Michael S. Tsirkin" , QEMU Developers , Marcel Apfelbaum Il 09/09/2013 19:27, Jan Kiszka ha scritto: > On 2013-09-09 19:14, Peter Maydell wrote: >> On 9 September 2013 18:09, Jan Kiszka wrote: >>> On 2013-09-09 18:58, Peter Maydell wrote: >>>> Why is a DMA request any different from any other communication >>>> between two devices? >>> >>> Other communication between devices requiring to take the target >>> device's lock while holding the one of the initiator will be a no-go as >>> well. But usually these scenarios are clearly defined, not >>> guest-influenceable and can be avoided by the initiator. >> >> How? If I'm a device and I need to raise a GPIO output line >> I have no idea what the other end is connected to. Similarly >> for more interesting device-to-device connections than >> pure on-or-off signal lines. > > Then you will have to write all devices involved in this in a way that > they preserve a clear locking order or drop locks before triggering such > signals - or stay with this communication completely under the BQL. I'm with Peter on this---I'm not sure why DMA-outside-BQL is different from interrupts-outside-BQL. If you drop locks before triggering either, there is no need to forbid DMA between devices. Yes, it is harder, but I'm not sure why it shouldn't work. If it is really needed, we could do things such as wait-wound locks that are used in databases (and in the Linux kernel) to avoid deadlocks. Databases need to take locks in arbitrary order decided by the query planner. Paolo >> >>> DMA is too >>> generic. E.g., the guest can easily program a device to >>> "accidentally" hit another device's MMIO region >> >> This is just a special case of generic device-device interaction. > > DMA is dispatched by the memory core which we would like to move out of > the BQL context soon. > > But you are right, we will have "fun" with interrupts and maybe some > other performance sensitive inter-device channels as well while breaking > up the BQL. Same rules as above will have to applied there. > > Jan >