Re: [PATCH v2 19/20] hw/arm: versatilepb: Store boot info in the machine state

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