Re: [PULL 04/49] hw: Add QOM parentship relation with CPUs

[Igor Mammedov <imammedo@redhat.com>]

On Wed, 15 Jan 2025 12:44:54 -0500
Peter Xu <peterx@redhat.com> wrote:

> On Wed, Jan 15, 2025 at 11:19:28AM +0100, Igor Mammedov wrote:
> > Another question is if it's safe to move/rename device withing QOM tree
> > wrt migration (i.e. when 1st instance has old QOM tree and 2nd a modified one)
> > 
> > quick smoke test works (migrating from old qemu to a new one with this patch)
> > But it's better to ask to be safe.  
> 
> I had a quick look, taking the simplest qemu64 cpu, I see two vmsds: "cpu"
> + "cpu_common", provided with different "instance_id" for each.  That's the
> ABI for the migration stream so far to match devices on two sides.
> 
> From that POV it's okay to move CPU devices within the qom-tree, hence not
> yet part of the ABI.  It matches with above tests that it would pass.
> 
> Though I'm not 100% sure this is wise either from migration POV.. because I
> think we need to rely on strictly below on both sides of QEMU src/dst:
> 
>   - Exactly the same QEMU cmdlines to be used (e.g. -smp X should be the
>     same on src/dst, or anything that creates the CPUs in cmdlines)
>   - Exactly the same QMP command to do device_add / device_del on CPUs,
>     with exactly the same parameters.


-smp X must be the same, but -device/device_(add|del) don't need to be
in the same order as ('cpu' and 'cpu_common') take it from cpu_index,
which is overridden to stable value (-smp topo based) by machines
that care about cpu hotplug and migration.

For machines that do not have cpu hotplug and do not override cpu_index
only -smp X matters and it stays the same.
That will break only if order of vCPUs creation is changed in a board code
(not impossible but for boards where we care about migration we usually
would pay attention to such reordering) and pretty soon get reports about
broken migration if it get merged.
To test for such case, we basically need to keep old QEMU binaries
and test cross version migration. 

> 
> I suppose only above be guaranteed by the user (or, libvirt), could the
> instance_id to be assigned be identical on both src/dst.  But I'm not 100%
> sure Libvirt can guarantee that.  E.g., we have vhost-user bug that can see
> different instance_id of some slirp instances after some plug/unplugs:
> 
> https://issues.redhat.com/browse/RHEL-56331
> 
> That might be slightly different topic, though, so the movement in the qom
> tree so far looks ok..
>