[PATCH] cpu_map: Add -noMPX models for x86 Icelake Server

[Lena Voytek]

Sorry for the delayed response. 

On Wed, 2022-08-17 at 14:13 +0200, Jiri Denemark wrote:
> 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.

The main issue being caused is that end users are unable to deploy
systems using libvirt without modification to x86_Icelake-Server-
noTSX.xml on 10nm Icelake. Having an additional definition that
specifies noMPX, similar to noTSX, would make the deployment process
much more convenient. This fix allows software such as OpenStack to
work by default on these systems. 

> 
> > 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.
> 
I agree that changing an existing model would be a bad idea, especially
since the current ones work correctly for 14nm Icelake processors.

> 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.
> 
It's fair if this change is not worth the compatibility issues of older
versions. The new models should work with QEMU's Icelake-Server CPU
definition if they need to be translated.

> In other words, the change would need to fix some real issue (not
> just
> reporting the right CPU to users) to outweigh the disadvantages.
> 
This fix would help end users running systems that use libvirt as a
base. I understand if the disadvantages outweigh the benefits mostly
seen in external software though.

> Jirka
> 

Thanks,
Lena Voytek