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 10:12:05 -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 09:53 AM, 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.
Technically it's not the unmap that causes badness, it's freeing the
underlying ram.

Let's avoid confusing terminology. We have RAM mappings and then we have PCI BARs that are mapped as IO_MEM_RAM.

PCI BARs mapped as IO_MEM_RAM are allocated by the device and live for the duration of the device. If you did something that changed the BAR's mapping from IO_MEM_RAM to an actual IO memory type, then you'd continue to DMA to the allocated device memory instead of doing MMIO operations.[1]

That's completely accurate and safe. If you did this to bare metal, I expect you'd get very similar results.

This is different from DMA'ing to a RAM region and then removing the RAM region while the IO is in flight. In this case, the mapping disappears and you potentially have the guest writing to an invalid host pointer.

[1] I don't think it's useful to support DMA'ing to arbitrary IO_MEM_RAM areas. Instead, I think we should always bounce to this memory. The benefit is that we avoid the complications resulting from PCI hot unplug and reference counting.

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.

Only if we think it's necessary to support native DMA to arbitrary IO_MEM_RAM. I contend this is never a normal or performance sensitive case and it's not worth supporting.

  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.

You can do the same thing and always bounce IO_MEM_RAM IO regions. It's just a question of whether we think it's worth the effort to do native DMA to this type of memory. I personally don't think it is at least in the beginning.

Regards,

Anthony Liguori

Paul





reply via email to

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