From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LmvQa-00053B-Ly for qemu-devel@nongnu.org; Thu, 26 Mar 2009 15:39:48 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LmvQV-0004w1-Vt for qemu-devel@nongnu.org; Thu, 26 Mar 2009 15:39:48 -0400 Received: from [199.232.76.173] (port=43311 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LmvQV-0004vj-IZ for qemu-devel@nongnu.org; Thu, 26 Mar 2009 15:39:43 -0400 Received: from mx2.redhat.com ([66.187.237.31]:57095) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LmvQV-0004wf-2j for qemu-devel@nongnu.org; Thu, 26 Mar 2009 15:39:43 -0400 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n2QJdgHO030851 for ; Thu, 26 Mar 2009 15:39:42 -0400 Message-ID: <49CBDA22.3070600@redhat.com> Date: Thu, 26 Mar 2009 21:40:18 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] honor IDE_DMA_BUF_SECTORS References: <49CA6E4A.4080408@eu.citrix.com> <49CB5793.4030006@redhat.com> <49CB599D.6000701@eu.citrix.com> <49CB5FA0.10101@redhat.com> <49CB6AF7.3080604@eu.citrix.com> <49CB70AC.3060900@redhat.com> <20090326124719.GL5642@const.bordeaux.inria.fr> <49CB7C0F.7010507@redhat.com> <20090326153021.GP5642@const.bordeaux.inria.fr> <49CBCA3C.2030909@redhat.com> <20090326184814.GC5458@const.famille.thibault.fr> In-Reply-To: <20090326184814.GC5458@const.famille.thibault.fr> Content-Type: text/plain; charset=ISO-8859-1; 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 Samuel Thibault wrote: >>>>> it should be centralized in the block layer instead of placing the >>>>> burden on all block format drivers ;) >>>>> >>>>> >>>> If other drivers need to do that, certainly. >>>> >>> In our case the other driver is specific to Xen. >>> >> I'm confused. I can only count one driver which has limited dma size. >> > > Then you are not looking at the same place as I am. The Xen tree is at > http://xenbits.xensource.com/git-http/qemu-xen-unstable.git > I wasn't looking at any tree. I count one driver with limited DMA sizes - block-vbd. What's the other one? Forgive me for not cloning and rummaging in qemu-xen. >>>>> One thing for instance that still have been overlooked although patches >>>>> have been sent is block-raw-posix' read/write_pread_aligned() that >>>>> consider partial read/writes as an error. That's a bug. >>>>> >>>>> >>>> Right. Unrelated topic though? >>>> >>> Nope. It's exactly the issue: read/write() may not be able to perform >>> the whole operation in just one go, and qemu should continue in that >>> case. >>> >> Oh, you're overloading block-raw-posix? >> > > I'm not. Actually, I am _also_ implementing the read/write() functions, > but that's another matter. In the xen tree, there is an addition > block-vbd.c driver. I'm here just pointing out that the problem is not > _only_ in the xen-specific driver, but also in the posix driver, on any > OS that doesn't necessarily do all the work the caller asked for (which > is _allowed_ by POSIX). > But that's not limited DMA (or at least, not limited up-front). And it's easily corrected, place a while loop around preadv/pwritev, no need to split a request a priori somewhere up the stack. IDE_MAX_DMA_BUFFER (or however it's called) wouldn't help here. And it wouldn't be right for block-vbd - you should split your requests as late as possible, IMO. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.