On Thu, Dec 11, 2025 at 05:29:37PM +0100, Cédric Le Goater wrote:
> On 12/9/25 17:28, Peter Xu wrote:
> > [This is an RFC series, as being marked out. It is trying to collect
> > opinions. It's not for merging yet]
> >
> > Background
> > ==========
> >
> > It all starts with machine compat properties..
> >
> > Machine compat properties are the major weapon we use currently in QEMU to
> > define a proper guest ABI, so that whenever we migration a VM instance from
> > whatever QEMU version1 to another QEMU version2, as long as the machine
> > type is the same, logically the ABI is guaranteed, and migration should
> > succeed. If it didn't, it's a bug.
>
> On the PPC pseries machines, we had to introduce a capability concept
> and infrastructure on top of the machine versions to handle cases where
> the features advertised to the guest (also visible to the OS) could
> differ from one host to another and generate migration errors. See :
>
> hw/ppc/spapr_caps.c
>
> These capabilities can be tweaked on the command line to adjust source
> and target host support. It's mostly related to CPU and MM features.
> Initially these difference were related to CPU bugs IIRC and different
> FW levels on the host.
>
> Is your proposal doing something similar ? Is my understanding correct ?
Maybe not exactly.
I only roughly read through SPAPR_CAP_HTM as an example, please help double
check if I misread it - I think such falls more into what Dan mentioned on
query-platform.
I am guessing CPU class of other archs should use similar concept, but I'm
not familiar with how it was done right now with QEMU/Libvirt.
So we have two standard categories of problems:
(1) A new feature, the feature should almost always be enabled on new
QEMUs, but need to be kept disabled when it can be migrated from old
QEMUs. It has nothing to do with the host / platform.
(2) A new feature, the feature should normally be enabled only whenever
the host HW/kernel supports it.
This series should try to solve problem (1) on non-qdev objects; it was
working properly for TYPE_DEVICE even before this series. It doesn't yet
solve problem (2). Problem (2), as a generic approach, may need something
like query-platform as Dan used to suggest.
IIUC all the spapr caps will still be needed, and I believe Libvirt knows
how to query caps in this case for spapr. It's a matter of if we should
have an unified interface to probe all of host capabilities, which should
not only include things like kvmppc_has_cap_htm(), but all the rest
platform info like TAP USO supports, in one batch to Libvirt. So Libvirt
takes it as "host information", plus user decisions to further decide the
QEMU cmdlines (or QMP commands used to create the system emulation).
That'll also include the -M cap-htm=XX properties to be used.
Considering that we should have ways Libvirt probing these.. maybe we do
not need to merge everything into a new QMP query-platform, but we can
consider putting all the new host info into that one command from now on.
Thanks,
--
Peter Xu
