>>> + sdhci_update_irq(s); >>> + break; >>> + } >>> + } >>> +} >> >> So I think the guest can make this loop never terminate if it sets up >> a loop of ACT_LINK descriptors, right? I don't know how we should >> handle this but I'm pretty sure "make qemu sit there forever not >> responding >> to anything and not resettable" isn't it. >>
Can I suggest that this is a general problem, that needs to be solved by the AIO layer. The AIO+block layer uses coroutines to do chunk-by-chunk non-blocking IO. I dont see how this is different. The problem is solved by setting up asynchronous DMA transactions or even better, arbitrary asynchronous hardware events. AIO DMA would have a similar api to the block layer and would solve this problem once, rather than having to put ptimers or coroutine-foo in every SGDMA capable devices to watchdog for infinite loops. >> -- PMM >> > > That could only happen if guest would do this on purpose, but I see your > point. There's no way for us to tell if SD card read/write succeeded or not, I think we are talking about corner cases here. If there is major infrastructural developments needed to do this properly (which I think there might very well be), then can we declare this issue out of scope of this series and come back to this as an incremental development. To summarise, its a hard problem to solve with minimal reward. Regards, Peter > so I think the only way to to this is to suspend transfer after some > reasonable amount of loops and resume it by qemu_timer, giving CPU time to > do something useful. > I've never seen long ADMA loops, so it wouldn't reflect on performance in > any way.