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