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