Re: Issue with vl.c: move -m parsing after memory backends has been processed. Commit a1b18df9a4848fc8a906e40c275063bfe9ca2047

[BALATON Zoltan]

Hello,

On Wed, 26 Feb 2020, Howard Spoelstra wrote:
> Hi all,
>
> Commit a1b18df9a4848fc8a906e40c275063bfe9ca2047 on the ppc-for-50 branch
> makes qemu-system-ppc running Mac OS 9 extremely slow. I bisected to the
> result below.
>
> Command line used:
> ./qemu-system-ppc -L pc-bios -M mac99,via=pmu -m 512 -boot c \
> -hda 9.2.img \
> -serial stdio -sdl
>
> Best,
> Howard
>
> a1b18df9a4848fc8a906e40c275063bfe9ca2047 is the first bad commit
> commit a1b18df9a4848fc8a906e40c275063bfe9ca2047
> Author: Igor Mammedov <address@hidden>

Isn't this the same as what's discussed in

https://lists.nongnu.org/archive/html/qemu-devel/2020-02/msg07229.html

Regards,
BALATON Zoltan

> Date:   Wed Feb 19 11:08:40 2020 -0500
>
>    vl.c: move -m parsing after memory backends has been processed
>
>    It will be possible for main RAM to come from memory-backend
>    and we should check that size specified in -m matches the size
>    of the backend and [MachineState::]ram_size also matches
>    backend's size.
>
>    However -m parsing (set_memory_options()) happens before backends
>    are intialized (object_create_delayed()) which complicates it.
>    Consolidate set_memory_options() and assigning parsed results to
>    current_machine after backends are initialized, so it would be
>    possible access the initialized backend instance to compare
>    sizes.
>
>    This patch only consolidates scattered places touching ram_size
>    within vl.c. And follow up patch will integrate backend handling
>    to set_memory_options().
>
>    Signed-off-by: Igor Mammedov <address@hidden>
>    Message-Id: <address@hidden>
>
> vl.c | 27 ++++++++++++++-------------
> 1 file changed, 14 insertions(+), 13 deletions(-)