Re: [Qemu-devel] [PATCH v6 1/4] hw: introduce standard SD host controller

[Peter Crosthwaite]

>>> +            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.