On Fri, Oct 08, 2021 at 10:01:45 +0100, Daniel P. Berrangé wrote: > The "canonical CPU features" capability is a derivative of the > "unavailable features" capability, which is exposed when seeing > the "max" CPU models has the "unavailable-features" property. > > This property was actually added back in QEMU version 2.8.0 per > the QAPI schema > > @unavailable-features: List of properties that prevent > the CPU model from running in the current > host. (since 2.8) > > so given our minimum QEMU version 2.11 there is no need to > query this. > > XXX strangely when we stop querying this, the domain > capabilities data for CPUs changes significantly for QEMU > versions less than 4.1.0. This suggests this code was masking > a need for some other capability check that would trigger for > QEMU < 4.1.0 ? This is because QEMU_CAPS_CANONICAL_CPU_FEATURES was not enabled in the capabilities data files for QEMU < 4.1.0. And since this feature is just an alias for QEMU_CAPS_CPU_UNAVAILABLE_FEATURES, the situation is caused by missing this UNAVAILABLE_FEATURES capability. And indeed qom-list-properties on max-x86_64-cpu does not list unavailable-features This property is only supported by query-cpu-definitions, which is what you found in the QAPI schema. Similarly named property of a CPU class was apparently added only in 4.1.0. Fortunately QEMU_CAPS_CPU_UNAVAILABLE_FEATURES was only selected as a conservative witness for QEMU which supports hyphens in all feature names at the time I implemented this in libvirt. That said, I believe it is safe to apply this patch. But please, rewrite the misleading commit message. And I think there's one more patch missing as we can now remove QEMU_CAPS_CANONICAL_CPU_FEATURES completely (well, by adding the X_ prefix). Jirka
