> 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. Apart from anything else, failure to do this breaks nested virtualization. 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
