Re: [Qemu-devel] [PATCH RFC v2 2/2] hw/pci: handle unassigned pci addresses

["Michael S. Tsirkin" <mst@redhat.com>]

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.kiszka@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