qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Re: [PATCHv2 10/12] tap: add vhost/vhostfd options


From: Anthony Liguori
Subject: [Qemu-devel] Re: [PATCHv2 10/12] tap: add vhost/vhostfd options
Date: Tue, 02 Mar 2010 09:33:18 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.5) Gecko/20091209 Fedora/3.0-4.fc12 Lightning/1.0pre Thunderbird/3.0

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]