Daniel P. Berrangé <berra...@redhat.com> writes: > On Mon, Apr 29, 2024 at 05:06:36PM +0200, Philippe Mathieu-Daudé wrote: >> Hi, >> >> On 29/4/24 00:25, Philippe Mathieu-Daudé wrote: >> > Hi, >> > >> > The KVM/QEMU community call is at: >> > >> > https://meet.jit.si/kvmcallmeeting >> > @ >> > 30/4/2024 14:00 UTC >> > >> > Are there any agenda items for the sync-up? >> >> I'd like to discuss two issues: >> >> 1/ Stability of QOM path >> --------------------- >> >> Currently we have 3 QOM containers: >> - /machine >> QOM objects properly parented go there >> - /machine/unattached >> Orphan QOM objects. Missing parent is usually easy >> to figure out, but we need to post patches to fix them. >> - /machine/peripheral[-anon] >> Devices created at runtime with CLI -device or QAPI device_add. >> (-anon is for devices with no explicit bus ID). >> See "Problem 4: The /machine/unattached/ orphanage" in [1]. >> >> The /machine and /machine/unattached trees are stable, although >> by adding parent to orphan objects, their path will change. >> >> Objects in /machine/peripheral[-anon] depend on the order of >> the device_add commands / arguments used. >> >> In a dynamically created machine, everything depend on how the >> device_add commands are processed. >> >> How can be expect to easily reference a QOM object by its path? > > FYI, for reference libvirt uses a couple of QOM paths > > * "/machine/unattached/device[0]" - path of first vCPU, but > this is an historical artifact - nowdays we query the > paths from query-cpus-fast
This is the only iffy use. The numbering of devices in /machine/unattached/ is not stable in practice. #0 may well be stable enough, though. > * "/machine/peripheral/%s/virtio-backend" where '%s' is the > ID we give the virtio device, for virtio-blk disks > > * /machine/peripheral/%s/%s.0/legacy[0] where both '%s' are > the ID we give the USB defvice, for USB disks > > * /machine/peripheral when enumerating devices we've > assigned ID aliases to. /machine/peripheral/ID is ABI. No worries. > * /machine to get the rtc-time property value This is an alias to the RTC device's "rtc-time" property. Only some machines define it. Useful because the actual property depends on machine type and configuration. For q35, it's /machine/unattached/device[N]/rtc/date, where N can vary. If we moved the southbridge out of the /machine/unattached dump, we'd have something like /machine/q35/ich9-lpc/rtc/date. Stable, but you have to know the machine type to find it. [...]
