On 10/13/17 18:18, Peter Maydell wrote: > On 13 October 2017 at 13:51, Laszlo Ersek <ler...@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.
You really cannot *not* want it more strongly than I :) (See my answer to Ard for why I went to such lengths nonetheless in mapping out the consequences for the firmware -- I knew and feared I'd find monsters there, but when I'm invited to look, it's only honest to look.) > 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. And, as one co-maintainer of one guest firmware, I'm immensely relieved to learn about, and benefit from, this guarantee. Thanks, Laszlo -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
