Re: [libvirt] [Qemu-devel] dynamic DRAM base for ArmVirtQemu
On Fri, Oct 13, 2017 at 05:18:59PM +0100, Peter Maydell wrote:
On 13 October 2017 at 13:51, Laszlo Ersek <lersek(a)redhat.com>
wrote:
> Another idea is to move *the* system DRAM base to a different guest-phys
> address. (Likely using a different version of the "virt" machine type,
> or even a different machine type entirely.) This would not be compatible
> with current ArmVirtQemu, which hard-codes the system DRAM base in
> several, quite brittle / sensitive, locations. (More on this later --
> that's going to be the larger part of my email anyway.) In order to
> handle the new base in ArmVirtQemu, two approaches are possible: change
> the hard-coded address(es), or cope with the address dynamically.
I strongly don't want to move the DRAM base in the "virt" board.
This is one of the few fixed things we've said that guest code
can rely on without having to fish the information out of the
device tree.
OK, if we take the base of DRAM as fixed, then we can either
a) support a split memory for mach-virt, 1G at 1G and the
rest starting at 4G.
or
b) create a new memory map for AArch64 where ECAM and GIC
redistributors are above max-ram (256G), assuming there's
no problem moving them up there.
I actually already started looking into (a), but it was starting
to snowball, which is why I started discussing moving the base
to 3G with Laszlo. I haven't looked at (b) yet, as I was sort
of assuming we'd want IO memory below 4G to avoid bumping into
any issues where drivers, etc. where making those kinds of
assumptions.
Thanks,
drew