[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
- [PULL 00/49] Misc HW patches for 2025-01-12, Philippe Mathieu-Daudé, 2025/01/12
- [PULL 01/49] pc-bios/meson.build: Silent unuseful DTC warnings, Philippe Mathieu-Daudé, 2025/01/12
- [PULL 02/49] target: Replace DEVICE(object_new) -> qdev_new(), Philippe Mathieu-Daudé, 2025/01/12
- [PULL 05/49] hw/usb: Inline usb_try_new(), Philippe Mathieu-Daudé, 2025/01/12
- [PULL 04/49] hw: Add QOM parentship relation with CPUs, Philippe Mathieu-Daudé, 2025/01/12
- Re: [PULL 04/49] hw: Add QOM parentship relation with CPUs, Zhao Liu, 2025/01/14
- Re: [PULL 04/49] hw: Add QOM parentship relation with CPUs, Igor Mammedov, 2025/01/15
- Re: [PULL 04/49] hw: Add QOM parentship relation with CPUs, Zhao Liu, 2025/01/15
[PULL 03/49] hw: Replace DEVICE(object_new) -> qdev_new(), Philippe Mathieu-Daudé, 2025/01/12
[PULL 07/49] hw/microblaze: Restrict MemoryRegionOps are implemented as 32-bit, Philippe Mathieu-Daudé, 2025/01/12
[PULL 06/49] hw/usb: Inline usb_new(), Philippe Mathieu-Daudé, 2025/01/12
[PULL 08/49] hw/net/xilinx_ethlite: Map MDIO registers (as unimplemented), Philippe Mathieu-Daudé, 2025/01/12
[PULL 09/49] hw/net/xilinx_ethlite: Introduce txbuf_ptr() helper, Philippe Mathieu-Daudé, 2025/01/12
[PULL 10/49] hw/net/xilinx_ethlite: Introduce rxbuf_ptr() helper, Philippe Mathieu-Daudé, 2025/01/12
[PULL 11/49] hw/net/xilinx_ethlite: Access TX_GIE register for each port, Philippe Mathieu-Daudé, 2025/01/12