[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] dynamic DRAM base for ArmVirtQemu
From: |
Laszlo Ersek |
Subject: |
Re: [Qemu-devel] dynamic DRAM base for ArmVirtQemu |
Date: |
Fri, 13 Oct 2017 21:50:33 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 |
On 10/13/17 18:18, 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.
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