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.
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..
--
Peter Xu
