On Fri, 20 Aug 2021 17:53:41 +0200 Philippe Mathieu-Daudé <[email protected]> wrote:
> 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 <[email protected]> wrote: > >> > >>> On Fri, 20 Aug 2021 at 15:34, David Hildenbrand <[email protected]> > >>> wrote: > >>>> > >>>> On 20.08.21 16:22, Bin Meng wrote: > >>>>> Hi Philippe, > >>>>> > >>>>> On Fri, Aug 20, 2021 at 10:10 PM Philippe Mathieu-Daudé > >>>>> <[email protected]> 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? On the first glance, just max_size field should be sufficient with checking code being generic, which should remove code duplication such checks introduce across tree. Is there a specific board for which call back is 'must to have'?
