From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53721) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uziq6-0005XG-RZ for qemu-devel@nongnu.org; Thu, 18 Jul 2013 03:41:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Uziq4-0002qQ-6l for qemu-devel@nongnu.org; Thu, 18 Jul 2013 03:41:26 -0400 Received: from mx1.redhat.com ([209.132.183.28]:54977) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uziq3-0002qA-VC for qemu-devel@nongnu.org; Thu, 18 Jul 2013 03:41:24 -0400 Date: Thu, 18 Jul 2013 09:41:08 +0200 From: Kevin Wolf Message-ID: <20130718074108.GA3582@dhcp-200-207.str.redhat.com> References: <51E64692.1010407@ilande.co.uk> <20130717081627.GB2458@dhcp-200-207.str.redhat.com> <51E69398.6080709@ilande.co.uk> <47766825-6E23-4404-B06C-2F27A70091DF@suse.de> <20130717133538.GJ2458@dhcp-200-207.str.redhat.com> <51E6FA99.7070508@ilande.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51E6FA99.7070508@ilande.co.uk> 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: Mark Cave-Ayland Cc: Alexander Graf , qemu-devel Am 17.07.2013 um 22:12 hat Mark Cave-Ayland geschrieben: > On 17/07/13 14:35, Kevin Wolf wrote: > > >Okay, so I've had a quick look at that DMA controller, and it seems that > >for a complete emulation, there's no way around using a bounce buffer > >(and calling directly into the block layer instead of using > >dma-helpers.c) for the general case. > > > >You can have a fast path that is triggered if one or more directly > >following INPUT/OUTPUT commands cover the whole IDE command, and that > >creates an QEMUSGList as described above and uses dma-helpers.c to > >implement zero-copy requests. I suspect that your Darwin requests would > >actually fall into this category. > > > >Essentially I think Alex' patches are doing something similar, just not > >implementing the complete DMA controller feature set and with the > >regular slow path hacked as additional code into the fast path. So the > >code could be cleaner, it could use asynchronous block layer functions > >and handle errors, and it could be more complete, but at the end of > >the day you'd still have some fast-path zero-copy I/O and some calls > >into the block layer using bounce buffers. > > I think the key concept to understand here is at what point does the > data hit the disk? From the comments in various parts of > Darwin/Linux, it could be understood that the DMA transfers are > between memory and the ATA drive *buffer*, so for writes especially > there is no guarantee that they even hit the disk until some point > in the future, unless of course the FLUSH flag is set in the control > register. > > So part of me makes me think that maybe we are over-thinking this > and we should just go with Kevin's original suggestion: what about > if we start a new QEMUSGList for each IDE transfer, and just keep > appending QEMUSGList entries until we find an OUTPUT_LAST/INPUT_LAST > command? > > Why is this valid? We can respond with a complete status for the > intermediate INPUT_MORE/OUTPUT_MORE commands without touching the > disk because all that guarantees is that data has been passed > between memory and the drive *buffer* - not that it has actually hit > the disk. And what is the point of having explicit _LAST commands if > they aren't used to signify completion of the whole transfer between > drive and memory? I don't think there is even a clear relation between the DMA controller status and whether the data is on disk or not. It's the IDE register's job to tell the driver when a request has completed. The DMA controller is only responsible for getting the data from the RAM to the device, which might start doing a write only after it has received all data and completed the DMA operation. (cf. PIO operation in core.c where the bytes are gathered in a bounce buffer and only when the last byte arrives, the whole sector is written out) What I would do, however, is to complete even the INPUT/OUTPUT_MORE commands only at the end of the whole request. This is definitely allowed behaviour, and it ensures that a memory region isn't already reused by the OS while e.g. a write request is still running and taking data from this memory. We should only complete the DMA command as soon as we don't touch the memory any more. Kevin