On Fri, Apr 11, 2025 at 15:58:54 +0200, Cornelia Huck wrote: > On Fri, Apr 11 2025, Jiri Denemark <jdene...@redhat.com> wrote: > > > On Fri, Apr 11, 2025 at 13:43:39 +0200, 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: > >> >> > 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).
I guess it will be possible for QEMU to actually set something different from what we tell it to do (for example dependency of a specific settings on something else which was not set, etc)? If so, we indeed need both (a) and (b). > Would a dump of the current state of the ID register fields before > starting the vcpus work for (b)? I guess so. Originally for x86_64 we got a dump of CPUID data, but that changed when some features started to be described by MSRs. > Or is that too different from what other archs need/want? Each arch has some specifics in CPU configuration and the way we talk with QEMU about it. So having the same QMP interface is not a requirement. It depends how well the existing interface maps to details that need to be expressed. That said a common interface is better if it makes sense. Jirka
