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.
But I presume this is more about switching a dim to point at a different
region in memory. It's a rare event similar to memory hot plug.
Approximately that, yes. One use is to start with ROM at address zero, then
switch to RAM once you've initialised the DRAM controller (using a small
internal SRAM as a trampoline).
Either way, if there are platforms where we don't treat ram with the new
ram api, that's okay.
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.
One thing I like about having a new ram api is it gives us a stronger
interface than what we have today. Today, we don't have a strong
guarantee that mappings won't be changed during a DMA transaction.
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.