From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:38801) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SydK2-0000Vq-DA for qemu-devel@nongnu.org; Tue, 07 Aug 2012 02:31:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SydK0-00068Z-AY for qemu-devel@nongnu.org; Tue, 07 Aug 2012 02:31:18 -0400 Received: from mail-ob0-f173.google.com ([209.85.214.173]:49609) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SydK0-00068U-5a for qemu-devel@nongnu.org; Tue, 07 Aug 2012 02:31:16 -0400 Received: by obbta14 with SMTP id ta14so6620769obb.4 for ; Mon, 06 Aug 2012 23:31:15 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <501FAE65.1060504@samsung.com> References: <501FAE65.1060504@samsung.com> Date: Tue, 7 Aug 2012 16:31:15 +1000 Message-ID: From: Peter Crosthwaite Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Qemu-devel] [PATCH v6 1/4] hw: introduce standard SD host controller List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Igor Mitsyanko Cc: Peter Maydell , Anthony Liguori , Stefan Hajnoczi , e.voevodin@samsung.com, qemu-devel@nongnu.org, kyungmin.park@samsung.com, d.solodkiy@samsung.com, edgar.iglesias@gmail.com, m.kozlov@samsung.com, john.williams@petalogix.com >>> + 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.