[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] phys_ram_base, direct access to guest memory

From: Avi Kivity
Subject: Re: [Qemu-devel] phys_ram_base, direct access to guest memory
Date: Mon, 17 Mar 2008 19:23:20 +0200
User-agent: Thunderbird (X11/20080226)

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]