From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LmoPk-0007cR-3M for qemu-devel@nongnu.org; Thu, 26 Mar 2009 08:10:28 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LmoPf-0007Yt-0X for qemu-devel@nongnu.org; Thu, 26 Mar 2009 08:10:27 -0400 Received: from [199.232.76.173] (port=57538 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LmoPe-0007Yl-Tz for qemu-devel@nongnu.org; Thu, 26 Mar 2009 08:10:22 -0400 Received: from mx2.redhat.com ([66.187.237.31]:37062) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LmoPe-0000aQ-Ff for qemu-devel@nongnu.org; Thu, 26 Mar 2009 08:10:22 -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 n2QCALcQ014048 for ; Thu, 26 Mar 2009 08:10:21 -0400 Message-ID: <49CB70AC.3060900@redhat.com> Date: Thu, 26 Mar 2009 14:10:20 +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> <49CB5793.4030006@redhat.com> <49CB599D.6000701@eu.citrix.com> <49CB5FA0.10101@redhat.com> <49CB6AF7.3080604@eu.citrix.com> In-Reply-To: <49CB6AF7.3080604@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: > Avi Kivity wrote: > > >> If cpu_physical_memory_map() returns NULL, then dma-helpers.c will stop >> collecting sg entries and submit the I/O. Tuning that will control how >> vectored requests are submitted. >> >> > > > > I understand your suggestion now, something like: > > --- > > diff --git a/dma-helpers.c b/dma-helpers.c > index 96a120c..6c43b97 100644 > --- a/dma-helpers.c > +++ b/dma-helpers.c > @@ -96,6 +96,11 @@ static void dma_bdrv_cb(void *opaque, int ret) > while (dbs->sg_cur_index < dbs->sg->nsg) { > cur_addr = dbs->sg->sg[dbs->sg_cur_index].base + dbs->sg_cur_byte; > cur_len = dbs->sg->sg[dbs->sg_cur_index].len - dbs->sg_cur_byte; > + if (dbs->iov.size + cur_len > DMA_LIMIT) { > + cur_len = DMA_LIMIT - dbs->iov.size; > + if (cur_len <= 0) > + break; > + } > mem = cpu_physical_memory_map(cur_addr, &cur_len, !dbs->is_write); > if (!mem) > break; > > --- > > would work for me. > > However it is difficult to put that code inside cpu_physical_memory_map > since I don't have any reference to link together all the mapping > requests related to the same dma transfer. > It would be fine here, but see below. >> If you problem is specifically with the bdrv_aio_rw_vector bounce >> buffer, then note that this is a temporary measure until vectored aio is >> in place, through preadv/pwritev and/or linux-aio IO_CMD_PREADV. You >> should either convert to that when it is merged, or implement request >> splitting in bdrv_aio_rw_vector. >> >> Can you explain your problem in more detail? >> > > > > My problem is that my block driver has a size limit for read and write > operations. > Then I think the place to split the requests is in your block format driver, not the generic code. If you run with one device using the limited block format driver, and the other device using another, unlimited block format driver, then the second device would be limited by the first device's limitation. I realize your use case will probably not trigger this, but it does indicate you're limiting at the wrong layer. It places the burden on all callers of block format drivers instead of centralizing it. > When preadv/pwritev are in place I could limit the transfer size > directly in raw_aio_preadv\pwritev but I would also have to update the > iovector size field to reflect that and I think is a little bit ugly. > Just copy the iovec for each sub-request. -- error compiling committee.c: too many arguments to function