On 12/15/2010 11:23 AM, Paul Brook wrote:
This adds a minimum chunk of Anthony's RAM API support so that we
can identify actual VM RAM versus all the other things that make
use of qemu_ram_alloc.
Why do we care? How are you defining "actual VM RAM"?
Surely the whole point of qemu_ram_alloc is to allocate a chunk of memory that
can be mapped into the guest physical address space, so all uses of
qemu_ram_alloc should be using this API.
"actual VM RAM" == the DIMM devices. This address has exactly a 1-1
mapping between memory content and an address. It doesn't change during
program execution.
It may be mapped in the CPU in weird ways, it may be visibly different
to devices, but that's a different interface.
Why do we care about differentiating "actual VM RAM" from things that
behave like RAM but are not actually RAM (like device ROM)? Because the
semantics are different. ROM is non-volatile and RAM is volatile. If
we don't make that distinction in our interfaces, we loose the ability
to model the behavioral differences.
For things like paravirtual devices, we can take short cuts (to optimize
performance) by saying the device is directly connecting to RAM (and
doesn't go through the normal translation hierarchy).
Regards,
Anthony Liguori
Paul
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
