On 2013-09-09 20:59, 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 :-)
If the deadlock makes the QEMU process unresponsive for management software that tries to reset the machine, or emulated hardware watchdogs... Jan -- Siemens AG, Corporate Technology, CT RTC ITP SES-DE Corporate Competence Center Embedded Linux
