From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NmUPj-0001tO-1y for qemu-devel@nongnu.org; Tue, 02 Mar 2010 10:53:39 -0500 Received: from [199.232.76.173] (port=44917 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NmUPh-0001sw-Nb for qemu-devel@nongnu.org; Tue, 02 Mar 2010 10:53:37 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1NmUPg-0002lS-Ru for qemu-devel@nongnu.org; Tue, 02 Mar 2010 10:53:37 -0500 Received: from mx20.gnu.org ([199.232.41.8]:32832) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NmUPg-0002lI-EK for qemu-devel@nongnu.org; Tue, 02 Mar 2010 10:53:36 -0500 Received: from mail.codesourcery.com ([38.113.113.100]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NmUPe-0006fV-Cm for qemu-devel@nongnu.org; Tue, 02 Mar 2010 10:53:34 -0500 From: Paul Brook Date: Tue, 2 Mar 2010 15:53:30 +0000 References: <201003021455.49620.paul@codesourcery.com> <4B8D2FBE.5010107@codemonkey.ws> In-Reply-To: <4B8D2FBE.5010107@codemonkey.ws> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <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: Anthony Liguori Cc: amit.shah@redhat.com, quintela@redhat.com, kraxel@redhat.com, qemu-devel@nongnu.org, "Michael S. Tsirkin" > >> 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. 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