|
From: | Anthony Liguori |
Subject: | [Qemu-devel] Re: [PATCHv2 10/12] tap: add vhost/vhostfd options |
Date: | Mon, 01 Mar 2010 15:54:00 -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/01/2010 01:27 PM, Michael S. Tsirkin wrote:
On Sun, Feb 28, 2010 at 10:39:21PM +0000, Paul Brook wrote:I'm sympathetic to your arguments though. As qemu is today, the above is definitely the right thing to do. But ram is always ram and ram always has a fixed (albeit non-linear) mapping within a guest.I think this assumption is unsafe. There are machines where RAM mappings can change. It's not uncommon for a chip select (i.e. physical memory address region) to be switchable to several different sources, one of which may be RAM. I'm pretty sure this functionality is present (but not actually implemented) on some of the current qemu targets. I agree that changing RAM mappings under an active DMA is a fairly suspect thing to do. However I think we need to avoid cache mappings between separate DMA transactions i.e. when the guest can know that no DMA will occur, and safely remap things. I'm also of the opinion that virtio devices should behave the same as any other device. i.e. if you put a virtio-net-pci device on a PCI bus behind an IOMMU, then it should see the same address space as any other PCI device in that location.It already doesn't. virtio passes physical memory addresses to device instead of DMA addresses.
That's technically a bug.
Apart from anything else, failure to do this breaks nested virtualization.Assigning PV device in nested virtualization? It could work, but not sure what the point would be.
It misses the point really.vhost-net is not a device model and it shouldn't have to care about things like PCI IOMMU. If we did ever implement a PCI IOMMU, then we would perform ring translation (or not use vhost-net).
Regards, Anthony Liguori
While qemu doesn't currently implement an IOMMU, the DMA interfaces have been designed to allow it.void cpu_ram_add(target_phys_addr_t start, ram_addr_t size);We need to support aliased memory regions. For example the ARM RealView boards expose the first 256M RAM at both address 0x0 and 0x70000000. It's also common for systems to create aliases by ignoring certain address bits. e.g. each sim slot is allocated a fixed 256M region. Populating that slot with a 128M stick will cause the contents to be aliased in both the top and bottom halves of that region. Paul
[Prev in Thread] | Current Thread | [Next in Thread] |