Re: Management applications and CPU feature flags

On Fri, Apr 11 2025, Jiri Denemark <jdenemar(a)redhat.com&gt; wrote: > On Fri, Apr 11, 2025 at 13:43:39 +0200, Markus Armbruster wrote: >> Daniel P. Berrangé <berrange(a)redhat.com&gt; writes: >> > On Fri, Apr 11, 2025 at 12:40:46PM +0200, Markus Armbruster wrote: >> >> Daniel P. Berrangé <berrange(a)redhat.com&gt; writes: >> >> > 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' >> >> 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. > > The existing commands (query-cpu-definitions, query-cpu-model-expansion) > are useful for probing before starting a domain. But what we use qom-get > for is to get a view of the currently instantiated virtual CPU created > by QEMU according to -cpu when we're starting a domain. In other words, > we start QEMU with -S and before starting vCPUs we need to know exactly > what features were enabled and if any feature we requested was disabled > by QEMU. Currently we query QOM for CPU properties as that's what we > were advised to use ages ago. > > The reason behind querying such info is ensuring stable guest ABI during > migration. Asking QEMU for a specific CPU model and features does not > mean we'll get exactly what we asked for (this is not a bug) so we need > to record the differences so that we can start QEMU for incoming > migration with a CPU matching exactly the one provided on the source. > > As Peter said, the current way is terribly inefficient as it requires > several hundreds of QMP commands so the goal is to have a single QMP > command that would tell us all we need to know about the virtual CPU. > That is all enabled features and all features that could not be enabled > even though we asked for them. Wandering in here from the still-very-much-in-progress Arm perspective (current but not yet posted QEMU code at https://gitlab.com/cohuck/qemu/-/tree/arm-cpu-model-rfcv3?ref_type=heads): We're currently operating at the "writable ID register fields" level with the idea of providing features (FEAT_xxx) as an extra layer on top (as they model a subset of what we actually need) and have yet to come up with a good way to do named models for KVM. The query-cpu-model-expansion command will yield a list of all writable ID register fields and their values (as for now, for the 'host' model.) IIUC you want to query (a) what is actually available for configuration (before starting a domain) and (b) what you actually got (when starting a domain).

Would a dump of the current state of the ID register fields before starting the vcpus work for (b)?

Or is that too different from what other archs need/want?