From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:57320) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S7QGZ-0004x1-I8 for qemu-devel@nongnu.org; Tue, 13 Mar 2012 07:51:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S7QGX-00027I-OY for qemu-devel@nongnu.org; Tue, 13 Mar 2012 07:51:47 -0400 Received: from mx1.redhat.com ([209.132.183.28]:57733) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S7QGX-000275-97 for qemu-devel@nongnu.org; Tue, 13 Mar 2012 07:51:45 -0400 Message-ID: <4F5F3598.70102@redhat.com> Date: Tue, 13 Mar 2012 12:55:04 +0100 From: Kevin Wolf MIME-Version: 1.0 References: <1331269308-22372-1-git-send-email-david@gibson.dropbear.id.au> <1331269308-22372-8-git-send-email-david@gibson.dropbear.id.au> <4F59D0C7.9040708@redhat.com> <20120313104224.GP24916@truffala.fritz.box> In-Reply-To: <20120313104224.GP24916@truffala.fritz.box> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 07/13] iommu: Make sglists and dma_bdrv helpers use new universal DMA helpers List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org, agraf@suse.de, eduard.munteanu@linux360.ro, mst@redhat.com, rth@twiddle.net Am 13.03.2012 11:42, schrieb David Gibson: > On Fri, Mar 09, 2012 at 10:43:35AM +0100, Kevin Wolf wrote: >> Am 09.03.2012 06:01, schrieb David Gibson: > [snip] >>> @@ -104,10 +104,20 @@ static void dma_complete(DMAAIOCB *dbs, int ret) >>> } >>> } >>> >>> +static void dma_bdrv_cancel(void *opaque) >>> +{ >>> + DMAAIOCB *dbs = opaque; >>> + >>> + bdrv_aio_cancel(dbs->acb); >>> + dma_bdrv_unmap(dbs); >>> + qemu_iovec_destroy(&dbs->iov); >>> + qemu_aio_release(dbs); >>> +} >> >> I'm lacking the context to know when this is actually called, but it >> looks suspicious. Did you consider that bdrv_aio_cancel() can actually >> invoke the completion callback? >> >> What's the difference between the existing dma_aio_cancel() and the >> function that you need here? > > So, first thing to note is that as I said in another sub-thread, there > are several approaches we could take for handling invalidation of > IOMMU mappings while they're in use by drivers, and I'm not sure which > is best yet. > > Second is that this piece of code comes from Eduard - Gabriel's > original and I haven't actually understood it as well as I should have > :). > > So, examining in more detail it looks like dma_aio_cancel() is the > right thing to do (I don't know if it existed when Eduard - Gabriel > wrote the initial version). I'm pretty sure that it's older than these patches. > The semantics of the callback are that after it's complete, there > should be no further access to the dma_memory_map()ed memory areas. I > haven't yet understood the bdrv stuff sufficiently well to be > completely sure that's true. Yes, I think it is. Once bdrv_aio_cancel() returns, the block layer doesn't do anything with the request any more. The caller (e.g. IDE) can't use the memory areas either because it doesn't even know them. Kevin