Ian Jackson wrote:
As I think has been mentioned here a few times before, Xen is able to
support guests with more RAM than the host's (strictly, dom0's)
address space. For example, 64-bit guests with >4G RAM on 32-bit
hosts. For this and for other reasons, guest physical RAM is not
mapped into any host process.
I don't expect qemu to take the Xen mapcache, which has been
extensively discussed and is apparently not well-regarded here.
However, it would be very helpful if where reasonable parts of qemu
would avoid assuming that they can get at guest physical memory by use
of phys_ram_base.
For example, in the loader in pc.c, simply adding phys_ram_base does
not work and we have to have a rather large patch to convert things to
use cpu_physical_memory_rw. The result is no more cumbersome -
indeed, it's slightly tidier in a few ways because there's less need
to constantly add and subtract phys_ram_base; the code can just deal
with guest physical addresses directly, as numbers, and leave the
actual memory access to the existing physical memory abstraction.
So I think it would be nice to have that change in qemu upstream.
While it doesn't directly enable anything useful right away, the
result is slightly cleaner. I'll submit a proper patch shortly.
Actually it is quite useful, with the 4GB+ support qemu memory is not
linear since the pci hole is skipped in phys_ram_base.
--
error compiling committee.c: too many arguments to function
