[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: QEMU Community Call Agenda Items (April 30th, 2024)
From: |
Markus Armbruster |
Subject: |
Re: QEMU Community Call Agenda Items (April 30th, 2024) |
Date: |
Tue, 30 Apr 2024 09:36:07 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
Daniel P. Berrangé <berrange@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.
[...]