qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Peter Xu
Subject: Re: [PULL 04/49] hw: Add QOM parentship relation with CPUs
Date: Wed, 15 Jan 2025 12:44:54 -0500

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]