Re: Management applications and CPU feature flags
On Fri, Apr 11 2025, Jiri Denemark <jdenemar(a)redhat.com> wrote:
On Fri, Apr 11, 2025 at 13:43:39 +0200, Markus Armbruster wrote:
> Daniel P. Berrangé <berrange(a)redhat.com> writes:
> > On Fri, Apr 11, 2025 at 12:40:46PM +0200, Markus Armbruster wrote:
> >> Daniel P. Berrangé <berrange(a)redhat.com> 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? How much wriggle room do we have for special
handling (different commands, different output, ...?)