On 10/13/17 18:18, 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.
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