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

[Avi Kivity <avi@qumranet.com>]

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