From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NmUVo-0003xi-NN for qemu-devel@nongnu.org; Tue, 02 Mar 2010 10:59:56 -0500 Received: from [199.232.76.173] (port=41131 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NmUVn-0003x8-Vl for qemu-devel@nongnu.org; Tue, 02 Mar 2010 10:59:56 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1NmUVm-0003A0-Bd for qemu-devel@nongnu.org; Tue, 02 Mar 2010 10:59:55 -0500 Received: from mx1.redhat.com ([209.132.183.28]:27978) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NmUVl-00039r-Uu for qemu-devel@nongnu.org; Tue, 02 Mar 2010 10:59:54 -0500 Date: Tue, 2 Mar 2010 17:56:24 +0200 From: "Michael S. Tsirkin" Message-ID: <20100302155624.GA8495@redhat.com> References: <201003021455.49620.paul@codesourcery.com> <4B8D2FBE.5010107@codemonkey.ws> <201003021553.31042.paul@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201003021553.31042.paul@codesourcery.com> Subject: [Qemu-devel] Re: [PATCHv2 10/12] tap: add vhost/vhostfd options List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook Cc: amit.shah@redhat.com, quintela@redhat.com, qemu-devel@nongnu.org, kraxel@redhat.com On Tue, Mar 02, 2010 at 03:53:30PM +0000, Paul Brook wrote: > > >> The key difference is that these regions are created and destroyed > > >> rarely and in such a way that the destruction is visible to the guest. > > > > > > So you're making ram unmap an asynchronous process, and requiring that > > > the address space not be reused until that umap has completed? > > > > It technically already would be. If you've got a pending DMA > > transaction and you try to hot unplug badness will happen. This is > > something that is certainly exploitable. > > Hmm, I guess we probably want to make this work with all mappings then. DMA to > a ram backed PCI BAR (e.g. video ram) is certainly feasible. This used to be possible with PCI/PCI-X. But as far as I know, with PCI Express, devices can not access each other's BARs. > Technically it's not the unmap that causes badness, it's freeing the > underlying ram. > > For these reasons I'm tempted to push the refcounting down to the ram > allocation level. This has a couple of nice properties. > > Firstly we don't care about dynamic allocation any more. We just say that > mapping changes may not effect active DMA transactions. If virtio chooses to > define that the vring DMA transaction starts when the device is enabled and > ends when disabled, that's fine by me. This probably requires revisiting the > memory barrier issues - barriers are pointless if you don't guarantee cache > coherence (i.e. no bounce buffers). > > Secondly, ram deallocation is not guest visible. The guest visible parts > (memory unmapping) can happen immediately, and we avoid a whole set of > unplug/replug race conditions. We may want to delay the completion of a > monitor hotplug command until the actual deallocation occurs, but that's a > largely separate issue. > > Paul