From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Lmmk8-0003Fv-Vf for qemu-devel@nongnu.org; Thu, 26 Mar 2009 06:23:25 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Lmmk3-0003AV-36 for qemu-devel@nongnu.org; Thu, 26 Mar 2009 06:23:23 -0400 Received: from [199.232.76.173] (port=39464 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Lmmk2-0003AS-TI for qemu-devel@nongnu.org; Thu, 26 Mar 2009 06:23:18 -0400 Received: from mx2.redhat.com ([66.187.237.31]:51015) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Lmmk2-0006jq-Hj for qemu-devel@nongnu.org; Thu, 26 Mar 2009 06:23:18 -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 n2QANHSK024782 for ; Thu, 26 Mar 2009 06:23:17 -0400 Message-ID: <49CB5793.4030006@redhat.com> Date: Thu, 26 Mar 2009 12:23:15 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] honor IDE_DMA_BUF_SECTORS References: <49CA3591.1010309@eu.citrix.com> <49CA4C3D.1070705@redhat.com> <49CA59AE.8060605@eu.citrix.com> <49CA5F9F.5040203@redhat.com> <49CA60BA.5060704@eu.citrix.com> <49CA6E4A.4080408@eu.citrix.com> In-Reply-To: <49CA6E4A.4080408@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: > I checked the ide driver in the kernel and it assumes that the max > sectors is either 256 or 64K depending on lba support, exactly as qemu does. > > > So now my question is: if I want to reduce the maximum dma request size > inside qemu, given that I must fill correctly the guest provided sg > list, is it OK to use IDE_DMA_BUF_SECTORS in dma_buf_prepare as I have > done in my patch? > > I don't see any other possible solution, but if you have any other > suggestion you are welcome to let me know. > Look at the DMA API (dma-helpers.c) which already knows how to split large dma requests. Splitting is controlled by cpu_physical_memory_map() (which I'm guessing is your real limitation), so you might want to look at that. The advantage of this approach is that it will apply to scsi and virtio once they are ported to use the DMA API. -- error compiling committee.c: too many arguments to function