As an example, one of QMP commands used by libvirt are:

{"execute":"qom-get","arguments":{"path":"/machine/unattached/device[0]","property":"unavailable-features"},"id":"libvirt-395"}

based on the qemu commit above the path above will not be valid any more and '/machine/cpu[0]' is likely going to be the new one.

In general for verification it should be sufficient that libvirt is running correctly with qemu-7.0 or newer which will have the commit.

commit a7743c60268e706699d4aa53ac0c45683ea84954
Author: Peter Krempa <pkrempa>
Date:   Mon Feb 7 12:29:47 2022 +0100

    qemu: process: Don't use hardcoded QOM path for cpu for probing flags
    
    Modify 'qemuProcessGetVCPUQOMPath' to take the detected QOM path of the
    first vCPU which is always present as the QOM path used our code probing
    CPU flags via 'qom-get'.
    
    This is needed as upcoming qemu will change it.
    
    Resolves: https://gitlab.com/libvirt/libvirt/-/issues/272
    Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2051451
    Signed-off-by: Peter Krempa <pkrempa>
    Reviewed-by: Ján Tomko <jtomko>

v8.0.0-314-ga7743c6026

Verify this bug with libvirt-8.3.0-1.el9.x86_64 and qemu-kvm-7.0.0-4.el9.x86_64:

Since downstream qemu not have the commit mentioned in comment 0, I will use gdb to make sure libvirt use QOM path instead of the hard coding:

1. start a guest and check virtqemud debug log and the first cpu's qom-path still is "/machine/unattached/device[0]"

2022-06-01 03:31:19.639+0000: 91187: info : qemuMonitorIOWrite:383 : QEMU_MONITOR_IO_WRITE: mon=0x7f60bc084d00 buf={"execute":"query-cpus-fast","id":"libvirt-9"}^M
 len=48 ret=48 errno=0
2022-06-01 03:31:19.640+0000: 91187: debug : qemuMonitorJSONIOProcessLine:199 : Line [{"return": [{"thread-id": 91192, "props": {"core-id": 0, "thread-id": 0, "socket-id": 0}, "qom-path": "/machine/unattached/device[0]", "cpu-index": 0, "target": "x86_64"}, {"thread-id": 91195, "props": {"core-id": 0, "thread-id": 0, "socket-id": 1}, "qom-path": "/machine/peripheral/vcpu1", "cpu-index": 1, "target": "x86_64"}], "id": "libvirt-9"}]

2. destroy guest and open a new terminal to use gdb attach virtqemud:

# gdb virtqemud -p `pidof virtqemud`
...
(gdb) br qemuProcessFetchGuestCPU.constprop.0
Breakpoint 1 at 0x7f61002479d0: file ../src/qemu/qemu_process.c, line 4247.
...

3. start a guest:
# virsh start vm1

4. check the trace of the code in qemuProcessGetVCPUQOMPath() function

Thread 6 "rpc-virtqemud" hit Breakpoint 1, qemuProcessFetchGuestCPU.constprop.0 (driver=0x7f60bc023330, vm=0x7f60bc2b6050, asyncJob=VIR_ASYNC_JOB_START, 
    enabled=0x7f6101ad2460, disabled=0x7f6101ad2468) at ../src/qemu/qemu_process.c:4247
4247	qemuProcessFetchGuestCPU(virQEMUDriver *driver,
(gdb) s
4256	    const char *cpuQOMPath = qemuProcessGetVCPUQOMPath(vm);
...
(gdb) n
4237	    if (vcpu &&
(gdb) n
4238	        (vcpupriv = QEMU_DOMAIN_VCPU_PRIVATE(vcpu)) &&
(gdb) n
4237	    if (vcpu &&
(gdb) n
4239	        vcpupriv->qomPath)
(gdb) n
4242	    return "/machine/unattached/device[0]";
(gdb) p vcpupriv->qomPath
$11 = 0x7f60b400f9f0 "/machine/unattached/device[0]"
(gdb) n
qemuProcessFetchGuestCPU.constprop.0 (driver=0x7f60bc023330, vm=0x7f60bc2b6050, asyncJob=VIR_ASYNC_JOB_START, enabled=0x7f6101ad2460, 
    disabled=0x7f6101ad2468) at ../src/qemu/qemu_process.c:4260
4260	    *enabled = NULL;
(gdb) p cpuQOMPath
$12 = 0x7f60b400f9f0 "/machine/unattached/device[0]"



And I will keep tracking qemu's change and retest this bug when qemu have the commit mentioned in comment 0.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Low: libvirt security, bug fix, and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2022:8003