From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45265) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VJ5qy-000526-4l for qemu-devel@nongnu.org; Mon, 09 Sep 2013 14:06:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VJ5qs-0003Zq-4i for qemu-devel@nongnu.org; Mon, 09 Sep 2013 14:06:24 -0400 Received: from thoth.sbs.de ([192.35.17.2]:33470) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VJ5qr-0003Yt-RP for qemu-devel@nongnu.org; Mon, 09 Sep 2013 14:06:18 -0400 Message-ID: <522E0E17.2050700@siemens.com> Date: Mon, 09 Sep 2013 20:06:15 +0200 From: Jan Kiszka 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: 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: Peter Maydell Cc: Paolo Bonzini , Anthony Liguori , Marcel Apfelbaum , QEMU Developers , "Michael S. Tsirkin" On 2013-09-09 19:41, Peter Maydell wrote: > On 9 September 2013 18:27, Jan Kiszka wrote: >> On 2013-09-09 19:14, Peter Maydell wrote: >>> On 9 September 2013 18:09, Jan Kiszka wrote: >>>> 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 don't have to do anything -- this already exists and > works fine. If you want to get rid of the big lock > then you need to do something... More to the point, > "all devices involved" is the entire set of QEMU's > device models -- you can't tell what a gpio line is > going to be connected to or restrict it magically to > a subset of devices. We need to do something about specific communication channels, where we do know how can talk to whom - e.g. interrupts. But you can't address this topic generically. Device models interested in BQL-free (or reduced) operation will have to be changed. On a case-by-case base. > >>>> 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. > > I'm not convinced this is sufficient reason to go backwards > on emulation accuracy. You know at flatten-to-address- > space time whether any particular region is going to be > to RAM or MMIO, so it should be possible to fast/slowpath > it at that point... You also have to know the source in order to tell if a transaction can be safely forwarded because BQL takes care or the initiator is holding no locks. This has nothing to do with fast/slow, this is about the risk to deadlock the QEMU process upon guest request. BTW, this was discussed earlier on the list a few times (need to dig the archive, was in the context of lock-less MMIO dispatching), and the consensus back then was that device-to-device DMA is generally a bug that is not worth supporting in all its beauty. But if you know a concrete scenario / guest where it matters, that would bring in a new aspect. Jan -- Siemens AG, Corporate Technology, CT RTC ITP SES-DE Corporate Competence Center Embedded Linux