From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39309) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uzojl-0002kc-Vh for qemu-devel@nongnu.org; Thu, 18 Jul 2013 09:59:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Uzojh-0007Lc-Aw for qemu-devel@nongnu.org; Thu, 18 Jul 2013 09:59:17 -0400 Received: from mx1.redhat.com ([209.132.183.28]:9808) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uzofn-00060v-9b for qemu-devel@nongnu.org; Thu, 18 Jul 2013 09:55:11 -0400 Date: Thu, 18 Jul 2013 15:55:02 +0200 From: Kevin Wolf Message-ID: <20130718135501.GM3582@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> <20130718074108.GA3582@dhcp-200-207.str.redhat.com> <9931658C-2020-42F3-9A0F-7AC3811E8AA5@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9931658C-2020-42F3-9A0F-7AC3811E8AA5@suse.de> 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: Alexander Graf Cc: Mark Cave-Ayland , qemu-devel Am 18.07.2013 um 15:44 hat Alexander Graf geschrieben: > > On 18.07.2013, at 09:41, Kevin Wolf wrote: > > > 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. > > Yes, that's the version that I described as "throw away almost all of > today's code and rewrite it" :). Well, Mark didn't ask me what's easy to implement, but what's the Right Thing to do. :-) > Keep in mind that the same DMA controller can be used for Ethernet, so > coupling it very tightly with IDE doesn't sound overly appealing to me > either. Taking this into consideration will make it even harder, but of course, once designed right, it's also the most useful approach. Kevin