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

[David Hildenbrand]

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?

--
Thanks,

David / dhildenb