From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LmuN9-0000iF-Ek for qemu-devel@nongnu.org; Thu, 26 Mar 2009 14:32:11 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LmuN4-0000gP-Kb for qemu-devel@nongnu.org; Thu, 26 Mar 2009 14:32:11 -0400 Received: from [199.232.76.173] (port=36908 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LmuN4-0000gK-FF for qemu-devel@nongnu.org; Thu, 26 Mar 2009 14:32:06 -0400 Received: from mx2.redhat.com ([66.187.237.31]:39513) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LmuN3-0001NG-VH for qemu-devel@nongnu.org; Thu, 26 Mar 2009 14:32:06 -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 n2QIW4kI008151 for ; Thu, 26 Mar 2009 14:32:05 -0400 Message-ID: <49CBCA3C.2030909@redhat.com> Date: Thu, 26 Mar 2009 20:32:28 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] honor IDE_DMA_BUF_SECTORS References: <49CA5F9F.5040203@redhat.com> <49CA60BA.5060704@eu.citrix.com> <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> In-Reply-To: <20090326153021.GP5642@const.bordeaux.inria.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable 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: > Avi Kivity, le Thu 26 Mar 2009 14:58:55 +0200, a =E9crit : > =20 >> Samuel Thibault wrote: >> =20 >>> Avi Kivity, le Thu 26 Mar 2009 14:10:20 +0200, a =E9crit : >>> =20 >>> =20 >>>> I realize your use case will probably not trigger this, but it does=20 >>>> indicate you're limiting at the wrong layer. It places the burden o= n=20 >>>> all callers of block format drivers instead of centralizing it. >>>> =20 >>>> =20 >>> Then it should be centralized in the block layer instead of placing t= he >>> burden on all block format drivers ;) >>> =20 >>> =20 >> If other drivers need to do that, certainly. >> =20 > > In our case the other driver is specific to Xen. > =20 I'm confused. I can only count one driver which has limited dma size. > =20 >>> One thing for instance that still have been overlooked although patch= es >>> have been sent is block-raw-posix' read/write_pread_aligned() that >>> consider partial read/writes as an error. That's a bug. >>> =20 >>> =20 >> Right. Unrelated topic though? >> =20 > > 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. > =20 Oh, you're overloading block-raw-posix? Isn't it more natural for you=20 to implement block-raw-xen-pv-block-frontend? You'd be able to use=20 asynchronous requests instead of a thread pool (much like=20 block-raw-linux-aio). --=20 I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.