On 11.04.25 13:43, Markus Armbruster wrote:
Daniel P. Berrangé <berra...@redhat.com> writes:
On Fri, Apr 11, 2025 at 12:40:46PM +0200, Markus Armbruster wrote:
Daniel P. Berrangé <berra...@redhat.com> writes:
On Wed, Apr 09, 2025 at 09:58:13AM +0200, Peter Krempa via Devel wrote:
On Wed, Apr 09, 2025 at 09:39:02 +0200, Markus Armbruster via Devel wrote:
Hi Steve, I apologize for the slow response.
Steve Sistare <steven.sist...@oracle.com> writes:
Using qom-list and qom-get to get all the nodes and property values in a
QOM tree can take multiple seconds because it requires 1000's of individual
QOM requests. Some managers fetch the entire tree or a large subset
of it when starting a new VM, and this cost is a substantial fraction of
start up time.
"Some managers"... could you name one?
libvirt is at ~500 qom-get calls during an average startup ...
To reduce this cost, consider QAPI calls that fetch more information in
each call:
* qom-list-get: given a path, return a list of properties and values.
* qom-list-getv: given a list of paths, return a list of properties and
values for each path.
* qom-tree-get: given a path, return all descendant nodes rooted at that
path, with properties and values for each.
Libvirt developers, would you be interested in any of these?
YES!!!
Not neccessarily, see below... !!!!
The getter with value could SO MUCH optimize the startup sequence of a
VM where libvirt needs to probe CPU flags:
(note the 'id' field in libvirt's monitor is sequential)
buf={"execute":"qom-get","arguments":{"path":"/machine/unattached/device[0]","property":"realized"},"id":"libvirt-8"}
buf={"execute":"qom-get","arguments":{"path":"/machine/unattached/device[0]","property":"hotplugged"},"id":"libvirt-9"}
buf={"execute":"qom-get","arguments":{"path":"/machine/unattached/device[0]","property":"hotpluggable"},"id":"libvirt-10"}
[...]
buf={"execute":"qom-get","arguments":{"path":"/machine/unattached/device[0]","property":"hv-apicv"},"id":"libvirt-470"}
buf={"execute":"qom-get","arguments":{"path":"/machine/unattached/device[0]","property":"xd"},"id":"libvirt-471"}
buf={"execute":"qom-get","arguments":{"path":"/machine/unattached/device[0]","property":"sse4_1"},"id":"libvirt-472"}
buf={"execute":"qom-get","arguments":{"path":"/machine/unattached/device[0]","property":"unavailable-features"},"id":"libvirt-473"}
First and last line's timestamps:
2025-04-08 14:44:28.882+0000: 1481190: info : qemuMonitorIOWrite:340 : QEMU_MONITOR_IO_WRITE: mon=0x7f4678048360
buf={"execute":"qom-get","arguments":{"path":"/machine/unattached/device[0]","property":"realized"},"id":"libvirt-8"}
2025-04-08 14:44:29.149+0000: 1481190: info : qemuMonitorIOWrite:340 : QEMU_MONITOR_IO_WRITE: mon=0x7f4678048360
buf={"execute":"qom-get","arguments":{"path":"/machine/unattached/device[0]","property":"unavailable-features"},"id":"libvirt-473"}
Libvirt spent ~170 ms probing cpu flags.
One thing I would point out is that qom-get can be considered an
"escape hatch" to get information when no better QMP command exists.
In this case, libvirt has made the assumption that every CPU feature
is a QOM property.
Adding qom-list-get doesn't appreciably change that, just makes the
usage more efficient.
Considering the bigger picture QMP design, when libvirt is trying to
understand QEMU's CPU feature flag expansion, I would ask why we don't
have something like a "query-cpu" command to tell us the current CPU
expansion, avoiding the need for poking at QOM properties directly.
How do the existing query-cpu-FOO fall short of what management
applications such as libvirt needs?
It has been along while since I looked at them, but IIRC they were
returning static info about CPU models, whereas libvirt wanted info
on the currently requested '-cpu ARGS'
Not sure what the exact requirements and other archs, but at least on
s390x I think that's exactly what we do.
If you expand a non-static model (e.g., z14) you'd get the expansion as
if you would specify "-cpu z14" on the cmdline for a specific QEMU machine.
Looking at CPU properties is really a nasty hack.
Libvirt developers, please work with us on design of new commands or
improvements to existing ones to better meet libvirt's needs in this
area.
Yes, knowing about requirements and why the existing APIs don't work
would be great.
--
Cheers,
David / dhildenb
