Re: [PATCH 00/33] hw/cpu/arm: Remove one use of qemu_get_cpu() in A7/A15 MPCore priv

[Cédric Le Goater]

On 1/3/24 20:53, Fabiano Rosas wrote:
> Philippe Mathieu-Daudé <philmd@linaro.org> writes:
>
> > +Peter/Fabiano
> >
> > On 2/1/24 17:41, Cédric Le Goater wrote:
> > > On 1/2/24 17:15, Philippe Mathieu-Daudé wrote:
> > > > Hi Cédric,
> > > >
> > > > On 2/1/24 15:55, Cédric Le Goater wrote:
> > > > > On 12/12/23 17:29, Philippe Mathieu-Daudé wrote:
> > > > > > Hi,
> > > > > >
> > > > > > When a MPCore cluster is used, the Cortex-A cores belong the the
> > > > > > cluster container, not to the board/soc layer. This series move
> > > > > > the creation of vCPUs to the MPCore private container.
> > > > > >
> > > > > > Doing so we consolidate the QOM model, moving common code in a
> > > > > > central place (abstract MPCore parent).
> > > > >
> > > > > Changing the QOM hierarchy has an impact on the state of the machine
> > > > > and some fixups are then required to maintain migration compatibility.
> > > > > This can become a real headache for KVM machines like virt for which
> > > > > migration compatibility is a feature, less for emulated ones.
> > > >
> > > > All changes are either moving properties (which are not migrated)
> > > > or moving non-migrated QOM members (i.e. pointers of ARMCPU, which
> > > > is still migrated elsewhere). So I don't see any obvious migration
> > > > problem, but I might be missing something, so I Cc'ed Juan :>
>
> FWIW, I didn't spot anything problematic either.
>
> I've ran this through my migration compatibility series [1] and it
> doesn't regress aarch64 migration from/to 8.2. The tests use '-M
> virt -cpu max', so the cortex-a7 and cortex-a15 are not covered. I don't
> think we even support migration of anything non-KVM on arm.

it happens we do.

> 1- https://gitlab.com/farosas/qemu/-/jobs/5853599533

yes it depends on the QOM hierarchy and virt seems immune to the changes.
Good.

However, changing the QOM topology clearly breaks migration compat,
at least on the Aspeed SoC. The question is : do we care ? For Aspeed
probably not, but the series should say so.

Thanks,

C.



 
> > > We broke migration compatibility by moving the IC object in the QOM
> > > hierarchy of the pseries machines in the past. These changes might
> > > be different. Here is the QOM tree of the ast2600 SoC.
> > >
> > > before :
> > >
> > >     /soc (ast2600-a3)
> > >       /a7mpcore (a15mpcore_priv)
> > >         /a15mp-priv-container[0] (memory-region)
> > >         /gic (arm_gic)
> > >           /gic_cpu[0] (memory-region)
> > >           /gic_cpu[1] (memory-region)
> > >           /gic_cpu[2] (memory-region)
> > >           /gic_dist[0] (memory-region)
> > >           /gic_vcpu[0] (memory-region)
> > >           /gic_viface[0] (memory-region)
> > >           /gic_viface[1] (memory-region)
> > >           /gic_viface[2] (memory-region)
> > >       /cpu[0] (cortex-a7-arm-cpu)
> > >       /cpu[1] (cortex-a7-arm-cpu)
> > >
> > > after :
> > >
> > >     /soc (ast2600-a3)
> > >       /a7mpcore (a7mpcore_priv)
> > >         /cpu[0] (cortex-a7-arm-cpu)
> > >         /cpu[1] (cortex-a7-arm-cpu)
> > >         /gic (arm_gic)
> > >           /gic_cpu[0] (memory-region)
> > >           /gic_cpu[1] (memory-region)
> > >           /gic_cpu[2] (memory-region)
> > >           /gic_dist[0] (memory-region)
> > >         /mpcore-priv-container[0] (memory-region)
> > >
> > >
> > > Thanks,
> > >
> > > C.