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 07:59:06PM +0100, Peter Maydell wrote:
> On 9 September 2013 19:49, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> > 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.
> 
> Typically on real hardware configuring things this way causes
> either (a) a memory transaction abort or (b) a deadlock. I
> think we could reasonably model that by deadlocking our
> device model, though as you say we should avoid actually
> crashing :-)
> 
> -- PMM

That's not really true.  The PCI spec says:

The target and master state machines in the PCI interface of a simple
device are completely independent. A device cannot make the completion
of any transaction (either posted or non-posted) as a target contingent
upon the prior completion of any other transaction as a master.


But it is certainly legal for a device to complete
a transaction and then start another transaction
in response. There's no reason this should deadlock
on real hardware if implemented according to the
above spec rule.

The spec-compliant way to emulate this therefore would be
to do exactly as spec says, and make handling of incoming
IO requests and DMA independent of each other.
Locking issues would then be solved automaticlly.

-- 
MST