On Mon, Sep 09, 2013 at 08:49:53PM +0200, Jan Kiszka wrote: > On 2013-09-09 20:03, Paolo Bonzini wrote: > > 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 <jan.kis...@siemens.com> 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. > > Well, even if you resolve the locking issues in all the interesting > devices (not impossible, just pretty costly in several regards), you > cannot reasonably allow device A talking to device B triggering a > request on A issuing a command to B... in the general case. If such > recursions are programmable, we need to stop them before QEMU's stack > explodes.
Actually in PCI, spec explicitly outlaws hardware that blocks an incoming request because an outgoing one is pending. So I don't think one can get away with doing DMA directly from a memory op and still claim strict PCI spec compliance. > Interrupts do not have the potential to cause this, at least with > existing machines. If a guest can configure GPIO loops between devices > models on some machine, this likely has to be addressed as well. > > > > > 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. > > Please not. Such lock semantics make it very hard - if not impossible - > to apply priority inversion avoidance protocols. Not to speak of the > massive changes on the code base to implement safe rollback. Just > because one domain can benefit from it doesn't make it a generally > useful tool. > > Jan > > -- > Siemens AG, Corporate Technology, CT RTC ITP SES-DE > Corporate Competence Center Embedded Linux