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