On Mon, Sep 09, 2013 at 07:59:06PM +0100, Peter Maydell wrote: > On 9 September 2013 19:49, Jan Kiszka <jan.kis...@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
