QEMU Community Call Agenda Items (April 30th, 2024)

QEMU Community Call Agenda Items (April 30th, 2024)

[Philippe Mathieu-Daudé]

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?


Alex maintains the invite on our Linaro project calendar here:

https://calendar.google.com/calendar/event?action=TEMPLATE&tmeid=MWd2dWI5NDM1bzdocnJlbTBhMHJhbG5sNWlfMjAyNDAyMjBUMTQwMDAwWiBjX2s1cDJscGd2YnB0ZGlya3U1c2kwMWJsbW5rQGc&tmsrc=c_k5p2lpgvbptdirku5si01blmnk%40group.calendar.google.com&scp=ALL

If you want to be added to the invite list let him know and you can get
spammed by your calendar app as well 😉

Regards,

Phil.

Re: QEMU Community Call Agenda Items (April 30th, 2024)

[Philippe Mathieu-Daudé]

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?

2/ Is it safe to broadcast a QAPI event to all type of device/object?
    ------------------------------------------------------------------

    We have QMP commands such @rtc-reset-reinjection or @inject-nmi
    which expect a single RTC / NMI listener in the machine.

    When using heterogeneous machines, we might end with multiple RTC
    or NMI-aware devices. Should these commands be broadcasted to all
    devices, or should we explicitly pass a list of paths to devices
    we want to notify. Maybe we want both options.

    See threads around NMI [2] and RTC [3].

[1] https://lore.kernel.org/qemu-devel/87o7d1i7ky.fsf@pond.sub.org/
[2] 
https://lore.kernel.org/qemu-devel/f4a6492b-cff4-439d-8f34-cdf04cb747ee@redhat.com/
[3] 
https://lore.kernel.org/qemu-devel/20240425133745.464091-1-d-tatianin@yandex-team.ru/

Regards,

Phil.

Re: QEMU Community Call Agenda Items (April 30th, 2024)

[Daniel P. Berrangé]

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

 * "/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 to get the rtc-time property value

> 2/ Is it safe to broadcast a QAPI event to all type of device/object?
>    ------------------------------------------------------------------
> 
>    We have QMP commands such @rtc-reset-reinjection or @inject-nmi
>    which expect a single RTC / NMI listener in the machine.
> 
>    When using heterogeneous machines, we might end with multiple RTC
>    or NMI-aware devices. Should these commands be broadcasted to all
>    devices, or should we explicitly pass a list of paths to devices
>    we want to notify. Maybe we want both options.
> 
>    See threads around NMI [2] and RTC [3].
> 
> [1] https://lore.kernel.org/qemu-devel/87o7d1i7ky.fsf@pond.sub.org/
> [2] https://lore.kernel.org/qemu-devel/f4a6492b-cff4-439d-8f34-cdf04cb747ee@redhat.com/
> [3] https://lore.kernel.org/qemu-devel/20240425133745.464091-1-d-tatianin@yandex-team.ru/
> 
> Regards,
> 
> Phil.
> 

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: QEMU Community Call Agenda Items (April 30th, 2024)

[Markus Armbruster]

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.

[...]

Re: QEMU Community Call Agenda Items (April 30th, 2024)

[Peter Maydell]

On Tue, 30 Apr 2024 at 08:36, Markus Armbruster <armbru@redhat.com> wrote:
>
> Daniel P. Berrangé <berrange@redhat.com> writes:
> >  * /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.

Do we really want to call that stable, though? If we ever
wanted to refactor the devices internally it might change.

My gut feeling is that exposing something we want to
be stable as a specific "this is obviously an externally
exposed identifier" (e.g. in the way we do by having an
rtc-time property alias on the machine object) is more
likely to be reliable than trusting that a QOM path all
the way down to a specific device is never going to be
rearranged.

thanks
-- PMM

Re: QEMU Community Call Agenda Items (April 30th, 2024)

[Daniel P. Berrangé]

On Tue, Apr 30, 2024 at 10:44:20AM +0100, Peter Maydell wrote:
> On Tue, 30 Apr 2024 at 08:36, Markus Armbruster <armbru@redhat.com> wrote:
> >
> > Daniel P. Berrangé <berrange@redhat.com> writes:
> > >  * /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.
> 
> Do we really want to call that stable, though? If we ever
> wanted to refactor the devices internally it might change.
> 
> My gut feeling is that exposing something we want to
> be stable as a specific "this is obviously an externally
> exposed identifier" (e.g. in the way we do by having an
> rtc-time property alias on the machine object) is more
> likely to be reliable than trusting that a QOM path all
> the way down to a specific device is never going to be
> rearranged.

Yes, the ideal would be that anything libvirt needs apriori knowledge
of should be accessible via an 'id' value assigned by libvirt. QOM
paths should only be used by libvirt if they're obtained dynamically
from a prior QMP query, not hardcoded in libvirt source. That would
avoid the QOM tree paths becoming API/ABI. The challenge is that it
is hard to predict what we might need to access, that does not yet
have an 'id' alias assigned, which is how we ended up using QOM
paths for a few things, where 99% of the timee we use 'id' aliases.


With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|