On Tue, Aug 16, 2022 at 06:38:59 -0700, Lena Voytek wrote:
With the current setup, a 10nm Icelake CPU, such as the Intel Xeon
Gold
6338, will be incorrectly recognized by libvirt as a 14nm broadwell CPU due
to the mpx label. See
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1978064.
Right, but what actual issue is this causing? The CPU model in host
capabilities is not used for anything by libvirt. The CPU model shown in
domain capabilities (virsh domcapabilities) is the one used by libvirt
and it should correctly show Icelake-Server.
When adding the removed tag to mpx in the Icelake xml definition, it
is then correctly determined. Would there be a better way of going
about making this distinction for 10nm Icelake processors?
Changing an existing CPU model can only be done when the removed CPU
feature did not ever work and there was no chance a domain could
actually be started with this feature enabled. Removing other features
causes migration issues and ABI breakage during migration,
save/restore, and snapshots, which is definitely much worse than not
seeing the expected CPU model in host capabilities.
Adding a new CPU model is not that serious, but it's not good either as
it causes unnecessary compatibility issues with older versions of
libvirt. Especially adding a new CPU model which does not exist in QEMU
does not make any sense, as libvirt would need to translate it to
something else when starting QEMU.
In other words, the change would need to fix some real issue (not just
reporting the right CPU to users) to outweigh the disadvantages.
Jirka