From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1L75HB-0006z7-V1 for qemu-devel@nongnu.org; Mon, 01 Dec 2008 04:41:10 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1L75H9-0006xm-3x for qemu-devel@nongnu.org; Mon, 01 Dec 2008 04:41:09 -0500 Received: from [199.232.76.173] (port=52805 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L75H8-0006xg-Vq for qemu-devel@nongnu.org; Mon, 01 Dec 2008 04:41:07 -0500 Received: from mx2.redhat.com ([66.187.237.31]:47337) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1L75H8-0005Mi-Gr for qemu-devel@nongnu.org; Mon, 01 Dec 2008 04:41:06 -0500 Message-ID: <4933B13C.6070205@redhat.com> Date: Mon, 01 Dec 2008 11:41:16 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] [RFC 1/1] pci-dma-api-v2 References: <20081127123538.GC10348@random.random> <20081128015602.GA31011@random.random> <20081128185001.GD31011@random.random> <20081130174133.GC32172@random.random> <493318B0.7020506@codemonkey.ws> In-Reply-To: <493318B0.7020506@codemonkey.ws> 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 Cc: Blue Swirl , Andrea Arcangeli Anthony Liguori wrote: > > I think you need something more sophisticated that can split up a > scatter/gather list into a set of partial bounce buffers and partial > direct copies. Just checking the vector once is a bit hackish. > That code path would never be used or tested. As it is, bouncing will only be invoked by dma to or from mmio, and I expect most guests never to invoke it. Why would we complicate the code even more? > > What should be fixed? Are these emulated functions wrong? > > There's a lack of symmetry here. We should have a bdrv_readv and > bdrv_aio_readv. bdrv_read and bdrv_aio_read should disappear. We can > maintain wrappers that create a compatible interface for older code > but just adding a new API is wrong. > It was understood a real aio readv/writev was being worked on, so the emulation could be a temporary step. >> +BlockDriverAIOCB *bdrv_aio_readv(BlockDriverState *bs, int64_t >> sector_num, >> + struct iovec *iov, int iovcnt, size_t len, >> + BlockDriverCompletionFunc *cb, void *opaque) >> +{ >> > > struct iovec does not exist on Windows. I also don't think you've got > the abstraction right. Reading and writing may require actions to > happen. I don't think you can just introduce something as simple as > an iovec here. I think we need something more active. > Can you elaborate? Actions happen in the completion callback. This is just an straightforward extension of the block API, I don't think a dma api should materially change the block api. > > I think you missed the mark here. This API needs to go through the > PCIBus and be pluggable at that level. There can be a default > implementation but it may differ for each PCI bus. > I think this can serve as the default implementation. Perhaps when a concrete user of pluggable dma emerges we can understand the requirements better. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.