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] 
> 20240425133745.464091-1-d-tatianin@yandex-team.ru/">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 :|