From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51464) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UzREO-0003SE-M7 for qemu-devel@nongnu.org; Wed, 17 Jul 2013 08:53:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UzREL-0000PB-Qz for qemu-devel@nongnu.org; Wed, 17 Jul 2013 08:53:20 -0400 Received: from p15195424.pureserver.info ([82.165.34.74]:36021) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UzREL-0000Oa-II for qemu-devel@nongnu.org; Wed, 17 Jul 2013 08:53:17 -0400 Message-ID: <51E69398.6080709@ilande.co.uk> Date: Wed, 17 Jul 2013 13:52:40 +0100 From: Mark Cave-Ayland MIME-Version: 1.0 References: <51E64692.1010407@ilande.co.uk> <20130717081627.GB2458@dhcp-200-207.str.redhat.com> In-Reply-To: <20130717081627.GB2458@dhcp-200-207.str.redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Possibility of unaligned DMA accesses via the QEMU DMA API? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: Alexander Graf , qemu-devel On 17/07/13 09:16, Kevin Wolf wrote: Hi Kevin, Thanks for the reply - CC to qemu-devel as requested. >> I've been testing some of Alex Graf's patches for running Darwin >> under QEMU PPC and have been experiencing some timeout problems on >> block devices. My attention is drawn to this commit in particular: >> https://github.com/qemu/qemu/commit/80fc95d8bdaf3392106b131a97ca701fd374489a. >> >> The reason for this commit is that Darwin programs the DBDMA >> controller to transfer data from the ATA FIFO in chunks that aren't >> sector aligned, e.g. the ATA command requests 0x10000 (256 sectors) >> but transfers the DMA engine to transfer the data to memory as 3 >> chunks of 0xfffe, 0xfffe and 0x4 bytes. > > I'm not familiar with how DMA works for the macio IDE device. Do you > have any pointers to specs or something? It works by setting up a DMA descriptor table (which is a list of commands) which are then "executed" when the RUN status bit is set until a STOP command is reached. Things are slightly more complicated in that commands can have conditional branches set on them. > The one important point I'm wondering about is why you call > dma_bdrv_read() with a single 0xfffe QEMUSGList. Shouldn't it really be > called with a QEMUSGList { 0xfffe, 0xfffe, 0x4 }, which should enable > dma-helpers.c to do the right thing? Hmmm I guess you could perhaps scan down the command list from the current position looking for all INPUT/OUTPUT commands until the next STOP command, and maybe build up a single QEMUSGList from that? I'm not sure exactly how robust that would be with the conditional branching though - Alex? > In any case, it would be good if you could prepare a (yet failing) qtest > case that demonstrates how DMA works on this controller and what the > problematic requests look like. I'll see what I can do, however I've not really looked at qtest before so it could take a little time. In the meantime, you can easily see these transfers by booting an old Darwin installation ISO. >> It seems that the DMA API dma_bdrv_read()/dma_bdrv_write() can't >> handle unaligned transfers in this way, yet I think there is a >> better solution for this that doesn't mix DMA/non-DMA APIs in this >> manner. I'd like to try and come up with a better solution, but >> there seems to be a mix of synchronous/asynchronous/co-routine block >> APIs that could be used. >> >> So my question is: what do you think is the best way to approach >> solving the unaligned data access for MACIO using a DMA-friendly >> API? > > First, as I said above, I'd like to understand why you need to go with > unaligned values into the DMA API. Real hardware also only works on a > sector level. The main culprit for these transfers is Darwin which limits large transfers to 0xfffe (see http://searchcode.com/codesearch/view/23337208 line 382). Hence most large disk transactions get broken down into irregularly-sized chunks which highlights this issue. > The block layer is really designed for working with whole sectors. The > only functions dealing with byte-aligned requests are bdrv_pread/pwrite. > They are synchronous (i.e. block the vcpu while running) and writes are > slow (because they first read the whole sector, copy in the modified > part, and write out the whole sector again), so you want to avoid it. Yeah, I figured this wasn't the most efficient way of doing it. The reason for asking the question was that I'm still struggling with some kind of timing/threading issue with Alex's work here, and I'm wondering if making the unaligned DMA requests more "atomic" by not mixing DMA/non-DMA/synchronous APIs will help solve the issue or not. ATB, Mark.