Re: xilinx-zynq-a9: cannot set up guest memory 'zynq.ext_ram'

[Philippe Mathieu-Daudé]

On 8/20/21 5:47 PM, David Hildenbrand wrote:
> On 20.08.21 17:44, Igor Mammedov wrote:
>> On Fri, 20 Aug 2021 15:39:27 +0100
>> Peter Maydell <peter.maydell@linaro.org> wrote:
>>
>>> On Fri, 20 Aug 2021 at 15:34, David Hildenbrand <david@redhat.com>
>>> wrote:
>>>>
>>>> On 20.08.21 16:22, Bin Meng wrote:
>>>>> Hi Philippe,
>>>>>
>>>>> On Fri, Aug 20, 2021 at 10:10 PM Philippe Mathieu-Daudé
>>>>> <philmd@redhat.com> wrote:
>>>>>>
>>>>>> Hi Bin,
>>>>>>
>>>>>> On 8/20/21 4:04 PM, Bin Meng wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> The following command used to work on QEMU 4.2.0, but is now broken
>>>>>>> with QEMU head.
>>>>>>>
>>>>>>> $ qemu-system-arm -M xilinx-zynq-a9 -display none -m 40000000
>>>>>>> -nographic -serial /dev/null -serial mon:stdio -monitor null -device
>>>>>>> loader,file=u-boot-dtb.bin,addr=0x4000000,cpu-num=0
>>>>>>> qemu-system-arm: cannot set up guest memory 'zynq.ext_ram': Cannot
>>>>>>> allocate memory
>>>
>>>> -m 40000000
>>>>
>>>> corresponds to 38 TB if I am not wrong. Is that really what you want?
>>>
>>> Probably not, because the zynq board's init function does:
>>>
>>>      if (machine->ram_size > 2 * GiB) {
>>>          error_report("RAM size more than 2 GiB is not supported");
>>>          exit(EXIT_FAILURE);
>>>      }
>>>
>>> It seems a bit daft that we allocate the memory before we do
>>> the size check. This didn't use to be this way around...
>>>
>>> Anyway, I think the cause of this change is commit c9800965c1be6c39
>>> from Igor. We used to silently cap the RAM size to 2GB; now we
>>> complain. Or at least we would complain if we hadn't already
>>> tried to allocate the memory and fallen over...
>>
>> That's because RAM (as host resource) is now separated
>> from device model (machine limits) and is allocated as
>> part of memory backend initialization (in this case
>> 'create_default_memdev') before machine_run_board_init()
>> is run.
>>
>> Maybe we can consolidate max limit checks in
>> create_default_memdev() by adding MachineClass::max_ram_size
>> but that can work only in default usecase (only '-m' is used).
> 
> We do have a workaround for s390x already: mc->fixup_ram_size
> 
> That should be called before the memory backend is created and seems to
> do just what we want, no?

Or maybe more explicit adding a MachineClass::check_ram_size() handler?