Re: [Qemu-devel] dynamic DRAM base for ArmVirtQemu

[Andrew Jones]

On Fri, Oct 13, 2017 at 05:18:59PM +0100, Peter Maydell wrote:
> On 13 October 2017 at 13:51, Laszlo Ersek <address@hidden> 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