qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Peter Crosthwaite
Subject: Re: [Qemu-devel] [PATCH v6 1/4] hw: introduce standard SD host controller
Date: Fri, 10 Aug 2012 21:56:33 +1000

Ping!

Any further thoughts here?

There seem to be a few minor correction for PPM, but the sore-thumb
issue is the long/infinite ADMA. Is there an (easy) AIO based solution
to be had or do we need to do some sort of ptimer hack?

Regards,
Peter

On Tue, Aug 7, 2012 at 4:31 PM, Peter Crosthwaite
<address@hidden> wrote:
>>>> +            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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]