On 09/19/2012 04:01 PM, Igor Mitsyanko wrote: >>> That would avoid the lockups and allow the device to be reset at >>> any time. Or am I missing something? >>> >> Not that I can see. If real hardware can be looped, so can qemu. I'm >> only worried about recursion and deadlocks (while real hardware can >> deadlock, we'd prefer to avoid that). >> >> > > So, I think the idea here is that if real hardware can be locked we > should lock too, but provide a guest CPU a possibility to abort locked > operation. For this particular example, SD card controller can deadlock > on recursive descriptor LINK entries, but CPU can abort ongoing > transaction at any time by issuing ABORT command. And if guest CPU > busy-waits in infinite while() loop for a TRANSFER OVER flag to be set, > then it had it coming.
If real hardware would lock up so should we (in the guest's eyes) but the qemu monitor should remain responsive. It is not part of emulated hardware. -- error compiling committee.c: too many arguments to function
