On Sun, 16 Aug 2026 at 16:07, Philippe Mathieu-Daudé <[email protected]> wrote: > > On 16/8/26 15:12, Bin Meng wrote: > > arm_load_kernel() keeps a pointer to the boot info struct for the > > lifetime of the VM, so the struct logically belongs to the machine > > rather than to a file scoped static object. > > > > Give both machine types the same VersatileMachineState instance struct > > and store the boot info there. > > > > As in the xlnx-zcu102 and raspi machines, the boot info belongs to > > the machine rather than to a static object: > > > > 4d1ac883a7 ("hw/arm: xlnx-zcu102: Move arm_boot_info into XlnxZCU102") > > 0f15c6e338 ("hw/arm/raspi: Move arm_boot_info structure to > > RaspiMachineState") > > > > Signed-off-by: Bin Meng <[email protected]> > > --- > > > > hw/arm/versatilepb.c | 16 ++++++++++++---- > > 1 file changed, 12 insertions(+), 4 deletions(-) > > > > diff --git a/hw/arm/versatilepb.c b/hw/arm/versatilepb.c > > index c6991a52e6..520af79c80 100644 > > --- a/hw/arm/versatilepb.c > > +++ b/hw/arm/versatilepb.c > > @@ -182,10 +182,16 @@ static void vpb_sic_init(Object *obj) > > peripherals and expansion busses. For now we emulate a subset of the > > PB peripherals and just change the board ID. */ > > > > -static struct arm_boot_info versatile_binfo; > > +typedef struct VersatileMachineState { > > + MachineState parent; > > + > > + struct arm_boot_info bootinfo; > > +} VersatileMachineState; > > > > static void versatile_init(MachineState *machine, int board_id) > > { > > + /* versatilepb and versatileab embed the same state as first member */ > > + VersatileMachineState *vms = (VersatileMachineState *)machine; > > Use OBJECT_DECLARE_SIMPLE_TYPE() and the defined macro?
That doesn't work, unfortunately, because in this file we define two machine types (versatileab and versatilepb) which are separate classes directly inheriting from TYPE_MACHINE but which share a common init function (both classes have an instance_init method which calls versatile_init()). OBJECT_DECLARE_SIMPLE_TYPE wants a 1:1 relation between the state struct and the type. I think to get this into a shape where we could use the standard QOM macros we would probably need to define a common abstract class that both the leaf machine types inherited from. That feels like it's probably a worthwhile cleanup, but I'm OK with what this patch is doing rather than making the "create the abstract parent" refactor a dependency for this series. The same applies for the omap_sx1.c and realview.c patches in this series, which do a similar thing. thanks -- PMM
