On 2013-09-09 19:41, Peter Maydell wrote: > On 9 September 2013 18:27, Jan Kiszka <jan.kis...@siemens.com> wrote: >> On 2013-09-09 19:14, Peter Maydell wrote: >>> On 9 September 2013 18:09, Jan Kiszka <jan.kis...@siemens.com> 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
