Re: [PULL 14/14] hw/arm/aspeed: Add Fuji machine type

From: "Cédric Le Goater" <clg@kaod.org>
To: Richard Henderson <richard.henderson@linaro.org>,
	Peter Maydell <peter.maydell@linaro.org>,
	Joel Stanley <joel@jms.id.au>
Cc: Andrew Jeffery <andrew@aj.id.au>,
	"qemu-arm@nongnu.org" <qemu-arm@nongnu.org>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Peter Delevoryas <pdel@fb.com>
Subject: Re: [PULL 14/14] hw/arm/aspeed: Add Fuji machine type
Date: Thu, 16 Sep 2021 14:29:12 +0200	[thread overview]
Message-ID: <d00d7eeb-a50c-c039-046c-7749fde25af8@kaod.org> (raw)
In-Reply-To: <1949e204-1bce-f15b-553b-1b42b41e3e08@linaro.org>

On 9/14/21 17:22, Richard Henderson wrote:
> On 9/14/21 5:26 AM, Peter Maydell wrote:
>> (2) RAM blocks should have a length that fits inside a
>>      signed 32-bit type on 32-bit hosts (at least I assume this
>>      is where the 2047MB limit is coming from; in theory this ought
>>      to be improveable but auditing the code for mishandling of
>>      RAMblock sizes to ensure we weren't accidentally stuffing
>>      their size into a signed 'long' somewhere would be kind
>>      of painful)
> 
> Recalling that the win64 abi model is p64, i.e. 'long' is still 32-bit while pointers are 64-bit, how close do we think we are to this being fixed already?

I removed the check from softmmu/vl.c and "all" tests on gitlab ran
fine. But, there is still a problem indeed. When running the Fuji
machine with a flash device to boot from  :

     $ gdb --args qemu-system-arm -M fuji-bmc -drive file=./flash-fuji,format=raw,if=mtd
     Thread 1 "qemu-system-arm" received signal SIGTRAP, Trace/breakpoint trap.
     _g_log_abort (breakpoint=1) at ../../../glib/gmessages.c:554
     554	../../../glib/gmessages.c: No such file or directory.
     (gdb) bt
     #0  _g_log_abort (breakpoint=1) at ../../../glib/gmessages.c:554
     #1  0xb7ae351d in g_logv
         (log_domain=0xb7b2d00e "GLib", log_level=G_LOG_LEVEL_ERROR, format=0xb7b36730 "%s: failed to allocate %u bytes", args=0xbfffed8c "\260f\263\267") at ../../../glib/gmessages.c:1373
     #2  0xb7ae36b9 in g_log (log_domain=0xb7b2d00e "GLib", log_level=G_LOG_LEVEL_ERROR, format=0xb7b36730 "%s: failed to allocate %u bytes")
         at ../../../glib/gmessages.c:1415
     #3  0xb7ae1e6a in g_malloc0 (n_bytes=134217728) at ../../../glib/gmem.c:137
     #4  0x006af2b7 in rom_add_blob
         (name=0xd65c67 "aspeed.boot_rom", blob=0xa3fa010, len=134217728, max_len=134217728, addr=0, fw_file_name=0x0, fw_callback=0x0, callback_opaque=0x0, as=0x0, read_only=true) at ../hw/core/loader.c:1068
     #5  0x0084b714 in write_boot_rom (addr=0, errp=<optimized out>, rom_size=134217728, dinfo=0x1766570) at ../hw/arm/aspeed.c:267
     #6  aspeed_machine_init (machine=0xb67c3010) at ../hw/arm/aspeed.c:397
     #7  0x0060e6d9 in machine_run_board_init (machine=<optimized out>) at ../hw/core/machine.c:1276
     #8  0x0099be9b in qemu_init_board () at ../softmmu/vl.c:2618
     ...

The last allocation of the machine (which is the boot ramblock) fails.

However, when using the 'execute-in-place' option of the Aspeed machine
which fetches directly instructions to execute from the flash MMIO region,
the machine boots correctly. No extra allocation for the ramblock.

>> Even if we did fix (2) we'd need to compromise on (3)
>> sometimes still -- if a board has 4GB of RAM that's
>> not going to fit in 32 bits regardless. But we would be
>> able to let boards with 2GB have 2GB.
> 
> I'm not opposed to deprecating 32-bit hosts...  ;-)

Until then, I am willing to make the following compromise for the fuji  :

     mc->default_ram_size = (HOST_LONG_BITS == 32 ? 1 : 2) * GiB;

Thanks,

C.