On Fri, Oct 13, 2017 at 05:18:59PM +0100, Peter Maydell wrote:
> On 13 October 2017 at 13:51, Laszlo Ersek <lersek@xxxxxxxxxx> 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
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
