On Thu, 13 Aug 2026 at 16:49, Bin Meng <bin.meng@processmission.com> wrote:
>
>
> Most ARM board files declare their struct arm_boot_info as a static
> object at file scope (or, occasionally, as a function-local static
> inside the machine init function). arm_load_kernel() stashes a pointer
> to that struct in every CPU and dereferences it from do_cpu_reset() on
> each reset, so the boot info conceptually belongs to the machine for the
> lifetime of the VM, not to a static object whose ownership is left
> implicit.
>
> This is a longstanding leftover pattern: modern machines such as virt,
> raspi and xlnx-zcu102 already keep the boot info in their MachineState
> subclass. This series converts the remaining machines that still use
> a static object, moving the struct into their machine state so that its
> lifetime and ownership match how arm_load_kernel() actually uses it.
Yes, I think mostly we have this leftover because converting
machines which don't yet have a state struct to have one seemed
a bit tedious. But it'll be useful to have them for other
cleanup reasons in future I suspect; I like the cleanup.
Rather than commenting on a lot of individual patches, I'll just
list a couple of niggles here:
(1) Can we be consistent about whether we set fields individually,
like this in patch 2:
+ bpms->bootinfo.loader_start = r40->memmap[AW_R40_DEV_SDRAM];
+ bpms->bootinfo.ram_size = machine->ram_size;
+ bpms->bootinfo.psci_conduit = QEMU_PSCI_CONDUIT_SMC;
or via a struct initializer, like this in patch 3:
+ cms->bootinfo = (struct arm_boot_info) {
+ .loader_start = SA_SDCS0,
+ .ram_size = RAM_SIZE,
+ .board_id = 0x208,
+ };
I don't particularly care which you pick, I'd just like to avoid
the needless variation.
(2) Could we use DEFINE_MACHINE_EXTENDED() rather than writing
out all the QOM boilerplate by hand, for the boards which previously
used DEFINE_MACHINE_ARM? (No need to convert to macros if we were
already using hand-written boilerplate, like omap_sx1.c.)
thanks
-- PMM