From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Lru2e-0006JN-1c for qemu-devel@nongnu.org; Thu, 09 Apr 2009 09:11:40 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Lru2Z-0006Hi-DH for qemu-devel@nongnu.org; Thu, 09 Apr 2009 09:11:39 -0400 Received: from [199.232.76.173] (port=51227 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Lru2Y-0006HX-Mt for qemu-devel@nongnu.org; Thu, 09 Apr 2009 09:11:34 -0400 Received: from yw-out-1718.google.com ([74.125.46.157]:9575) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Lru2Y-0004XI-Bk for qemu-devel@nongnu.org; Thu, 09 Apr 2009 09:11:34 -0400 Received: by yw-out-1718.google.com with SMTP id 9so361671ywk.82 for ; Thu, 09 Apr 2009 06:11:33 -0700 (PDT) Message-ID: <49DDF3FF.8050706@codemonkey.ws> Date: Thu, 09 Apr 2009 08:11:27 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] buffer alignment for block backends References: <49DCA80A.1020808@eu.citrix.com> <49DCF2C0.9070704@codemonkey.ws> <49DDC66F.2000404@eu.citrix.com> In-Reply-To: <49DDC66F.2000404@eu.citrix.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Stefano Stabellini wrote: > Anthony Liguori wrote: > > >>> If you do not want to do that, another possible solution is to create a >>> new function called "qemu_blockalign" that would be implemented as >>> qemu_memalign(512, size); >>> >> This is fine, but this is purely an optimization, it cannot be relied >> upon in the general case. >> > > > > well, there aren't many places that allocate buffers for the block > backends, I can count only the following for dma operations: > > - block.c:bdrv_aio_rw_vector > This bounces a scatter/gather list into a single linear buffer since not all backends handle scatter/gather lists today. > and this one for other ide read and write operations: > > - ide.c:ide_init2 > This buffer is only used when not doing DMA. When doing DMA, we are able to do zero-copy IO so the alignment of the request depends on how the guest aligned the request. I suspect you'll find a lot of guests that, in practice, do not align requests at 4k boundaries. I don't know what the requirements are for IDE but I would be surprised if it was 4k. > I think it would be important at least for dma operations. > We have a lot of places with explicit memalign's because the block raw backend code degrades into synchronous IO when performing non-aligned IO with cache=off. I've never liked this much personally. That's not saying that I think we shouldn't try to align DMA buffers when we're allocating them in QEMU. A block level function to do this would be pretty nice in fact. >>> so we don't have to write 512 bytes everywhere >>> but only in one place, thus making life easier to people like me that >>> have to change the value for a special case. >>> >>> Thanks in advance for your sympathy :) >>> >>> >> Why does your backend requirement page alignment and who's notion of page? >> >> > > my backend (block-vbd) needs page aligned buffers because blkfront needs > page aligned buffers. I could allocate a new page aligned buffer every > time and the memcpy but it is just a waste. > You'll need to check the alignment of the request and bounce it if necessary. In the case that you have zero-copy requests coming from the guest that aren't page aligned, someone has to bounce the thing to make it page aligned. So I presume you're implementing blkfront in userspace? Does minios provide a userspace interface for grant tables that looks similar to the interfaces on Linux? Were you planning on submitting this for inclusion in upstream QEMU? I think it's a reasonable thing to include provided it's relatively self-contained. Regards, Anthony Liguori