qemu-devel
[Top][All Lists]
Advanced

[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.

[...]




reply via email to

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