* QEMU Community Call Agenda Items (April 30th, 2024) @ 2024-04-28 22:25 Philippe Mathieu-Daudé 2024-04-29 15:06 ` Philippe Mathieu-Daudé 0 siblings, 1 reply; 6+ messages in thread From: Philippe Mathieu-Daudé @ 2024-04-28 22:25 UTC (permalink / raw) To: QEMU Developers Cc: Alex Bennée, afaerber, ale, alistair.francis, Anton Johansson, armbru, bbauman, bcain, berrange, Chao Peng, cjia, clg, cw, Damien Hedde, eblake, edgar.iglesias, eduardo, Elena Ufimtseva, eric.auger, felipe, iggy, imp, jan.kiszka, jgg, jidong.xiao, jim.shu, jjherne, Joao Martins, konrad.wilk, Luc Michel, mburton, mdean, mimu, paul.walmsley, pbonzini, Peter Maydell, Richard Henderson, Shameerali Kolothum Thodi, shentey, stefanha, wei.w.wang, z.huo, LIU Zhiwei, zwu.kernel, eblot, max.chou 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: QEMU Community Call Agenda Items (April 30th, 2024) 2024-04-28 22:25 QEMU Community Call Agenda Items (April 30th, 2024) Philippe Mathieu-Daudé @ 2024-04-29 15:06 ` Philippe Mathieu-Daudé 2024-04-29 15:55 ` Daniel P. Berrangé 0 siblings, 1 reply; 6+ messages in thread From: Philippe Mathieu-Daudé @ 2024-04-29 15:06 UTC (permalink / raw) To: QEMU Developers, Daniil Tatianin, armbru Cc: Alex Bennée, afaerber, ale, alistair.francis, Anton Johansson, bbauman, bcain, berrange, Chao Peng, cjia, clg, cw, Damien Hedde, eblake, edgar.iglesias, eduardo, Elena Ufimtseva, eric.auger, felipe, iggy, imp, jan.kiszka, jgg, jidong.xiao, jim.shu, jjherne, Joao Martins, konrad.wilk, Luc Michel, mburton, mdean, mimu, paul.walmsley, pbonzini, Peter Maydell, Richard Henderson, Shameerali Kolothum Thodi, shentey, stefanha, wei.w.wang, z.huo, LIU Zhiwei, zwu.kernel, eblot, max.chou 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: QEMU Community Call Agenda Items (April 30th, 2024) 2024-04-29 15:06 ` Philippe Mathieu-Daudé @ 2024-04-29 15:55 ` Daniel P. Berrangé 2024-04-30 7:36 ` Markus Armbruster 0 siblings, 1 reply; 6+ messages in thread From: Daniel P. Berrangé @ 2024-04-29 15:55 UTC (permalink / raw) To: Philippe Mathieu-Daudé Cc: QEMU Developers, Daniil Tatianin, armbru, Alex Bennée, afaerber, ale, alistair.francis, Anton Johansson, bbauman, bcain, Chao Peng, cjia, clg, cw, Damien Hedde, eblake, edgar.iglesias, eduardo, Elena Ufimtseva, eric.auger, felipe, iggy, imp, jan.kiszka, jgg, jidong.xiao, jim.shu, jjherne, Joao Martins, konrad.wilk, Luc Michel, mburton, mdean, mimu, paul.walmsley, pbonzini, Peter Maydell, Richard Henderson, Shameerali Kolothum Thodi, shentey, stefanha, wei.w.wang, z.huo, LIU Zhiwei, zwu.kernel, eblot, max.chou 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 :| ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: QEMU Community Call Agenda Items (April 30th, 2024) 2024-04-29 15:55 ` Daniel P. Berrangé @ 2024-04-30 7:36 ` Markus Armbruster 2024-04-30 9:44 ` Peter Maydell 0 siblings, 1 reply; 6+ messages in thread From: Markus Armbruster @ 2024-04-30 7:36 UTC (permalink / raw) To: Daniel P. Berrangé Cc: Philippe Mathieu-Daudé, QEMU Developers, Daniil Tatianin, Alex Bennée, afaerber, ale, alistair.francis, Anton Johansson, bbauman, bcain, Chao Peng, cjia, clg, cw, Damien Hedde, eblake, edgar.iglesias, eduardo, Elena Ufimtseva, eric.auger, felipe, iggy, imp, jan.kiszka, jgg, jidong.xiao, jim.shu, jjherne, Joao Martins, konrad.wilk, Luc Michel, mburton, mdean, mimu, paul.walmsley, pbonzini, Peter Maydell, Richard Henderson, Shameerali Kolothum Thodi, shentey, stefanha, wei.w.wang, z.huo, LIU Zhiwei, zwu.kernel, eblot, max.chou 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. [...] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: QEMU Community Call Agenda Items (April 30th, 2024) 2024-04-30 7:36 ` Markus Armbruster @ 2024-04-30 9:44 ` Peter Maydell 2024-04-30 10:01 ` Daniel P. Berrangé 0 siblings, 1 reply; 6+ messages in thread From: Peter Maydell @ 2024-04-30 9:44 UTC (permalink / raw) To: Markus Armbruster Cc: Daniel P. Berrangé, Philippe Mathieu-Daudé, QEMU Developers, Daniil Tatianin, Alex Bennée, afaerber, ale, alistair.francis, Anton Johansson, bbauman, bcain, Chao Peng, cjia, clg, cw, Damien Hedde, eblake, edgar.iglesias, eduardo, Elena Ufimtseva, eric.auger, felipe, iggy, imp, jan.kiszka, jgg, jidong.xiao, jim.shu, jjherne, Joao Martins, konrad.wilk, Luc Michel, mburton, mdean, mimu, paul.walmsley, pbonzini, Richard Henderson, Shameerali Kolothum Thodi, shentey, stefanha, wei.w.wang, z.huo, LIU Zhiwei, zwu.kernel, eblot, max.chou 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: QEMU Community Call Agenda Items (April 30th, 2024) 2024-04-30 9:44 ` Peter Maydell @ 2024-04-30 10:01 ` Daniel P. Berrangé 0 siblings, 0 replies; 6+ messages in thread From: Daniel P. Berrangé @ 2024-04-30 10:01 UTC (permalink / raw) To: Peter Maydell Cc: Markus Armbruster, Philippe Mathieu-Daudé, QEMU Developers, Daniil Tatianin, Alex Bennée, afaerber, ale, alistair.francis, Anton Johansson, bbauman, bcain, Chao Peng, cjia, clg, cw, Damien Hedde, eblake, edgar.iglesias, eduardo, Elena Ufimtseva, eric.auger, felipe, iggy, imp, jan.kiszka, jgg, jidong.xiao, jim.shu, jjherne, Joao Martins, konrad.wilk, Luc Michel, mburton, mdean, mimu, paul.walmsley, pbonzini, Richard Henderson, Shameerali Kolothum Thodi, shentey, stefanha, wei.w.wang, z.huo, LIU Zhiwei, zwu.kernel, eblot, max.chou 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 :| ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2024-04-30 10:02 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2024-04-28 22:25 QEMU Community Call Agenda Items (April 30th, 2024) Philippe Mathieu-Daudé 2024-04-29 15:06 ` Philippe Mathieu-Daudé 2024-04-29 15:55 ` Daniel P. Berrangé 2024-04-30 7:36 ` Markus Armbruster 2024-04-30 9:44 ` Peter Maydell 2024-04-30 10:01 ` Daniel P. Berrangé
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).