From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NmU6B-0001ZV-J7 for qemu-devel@nongnu.org; Tue, 02 Mar 2010 10:33:27 -0500 Received: from [199.232.76.173] (port=51724 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NmU6A-0001Z0-Mh for qemu-devel@nongnu.org; Tue, 02 Mar 2010 10:33:26 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1NmU69-0001m8-4o for qemu-devel@nongnu.org; Tue, 02 Mar 2010 10:33:26 -0500 Received: from qw-out-1920.google.com ([74.125.92.145]:63945) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NmU68-0001lz-R9 for qemu-devel@nongnu.org; Tue, 02 Mar 2010 10:33:25 -0500 Received: by qw-out-1920.google.com with SMTP id 5so52718qwf.4 for ; Tue, 02 Mar 2010 07:33:21 -0800 (PST) Message-ID: <4B8D2FBE.5010107@codemonkey.ws> Date: Tue, 02 Mar 2010 09:33:18 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <201003021433.51987.paul@codesourcery.com> <4B8D2320.8000608@codemonkey.ws> <201003021455.49620.paul@codesourcery.com> In-Reply-To: <201003021455.49620.paul@codesourcery.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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, kraxel@redhat.com, qemu-devel@nongnu.org, "Michael S. Tsirkin" On 03/02/2010 08:55 AM, Paul Brook wrote: >>>> With a new api, cpu_physical_memory_map() changes semantics. It only >>>> returns pointers for static ram mappings. Everything else is bounced >>>> which guarantees that an address can't change during DMA. >>>> >>> Doesn't this mean that only the initial RAM is directly DMA-able? >>> >>> While memory hotplug(and unplug) may be an infrequent event, having the >>> majority of ram be hotplug seems much more likely. >>> >> Hotplug works fine for direct DMA'ing. map/unmap would maintain a >> reference count on the registered RAM region and hot unplug would not be >> allowed until that reference dropped to zero. For something like >> virtio, it means that the driver has to be unloaded in the guest before >> you hot unplug the region of memory if it happens to be using that >> region of memory for the ring storage. >> >> 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. Regards, Anthony Liguori > Paul >