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

[Lena Voytek]

Hello,

On Thu, 2022-12-08 at 11:16 +0100, Kashyap Chamarthy wrote:
> On Wed, Dec 07, 2022 at 10:23:17AM -0700, Lena Voytek wrote:
> > Hello all,
> > 
> > Over the past few months there have been a few more reports of
> > users unable
> > to use Openstack Nova on their Icelake CPU. Updating virsh
> > capabilities to
> > properly display that mpx is unavailable fixes it. Is there an
> > ideal way to
> > update this change such that it gets accepted into libvirt?
> 
> I'm just curious if you tried deploying instances by explicitly
> disbaling the "mpx" flag on the compute nodes:
> 
>     [libvirt]
>     cpu_mode = custom
>     cpu_models = Icelake-Server
>     cpu_model_extra_flags = -mpx
> 

Unfortunately this does not work for Openstack Nova users because virsh
detects the processor as Broadwell-noTSX-IBRS rather than Icelake-
Server. It depends on virsh to provide the correct processor
information to assert that the guest is compatible with the host -
https://github.com/openstack/nova/blob/8a476061c5e034016668cd9e5a20c4430ef6b68d/nova/virt/libvirt/driver.py#L987

> (As Jiri points out an additional complication elsewhere in this
> thread,
> apparently Intel disabled "mpx" only on 10nm CPUs, while 14nm CPUs of
> the same generation still retain it.)
> 
> And this was the decision[1] that Daniel was pointing out about
> QEMU's
> decision to not include more named CPU models with specific flags
> enabled or disabled:
> 
>     "[...] Then a recently along came the Speculative Store Bypass
>     hardware vulnerability requiring addition of yet another CPU flag
> to
>     guest configs. This required use of 'ssbd' on Intel and 'virt-
> ssbd'
>     on AMD.  While QEMU could have now added yet more CPU models, eg
>     Westmere-SSBD, this does not feel like a winning strategy long
> term.
>     Looking at the models how would a user have any clue whether the
>     -IBRS or -SSBD or -NEXT-FLAW or -YET-ANOTHER-FLAW suffix is
> "better"
>     ? So QEMU and libvirt took the joint decision to stop adding new
>     named CPU models when CPU vulnerabilities are discovered from
> this
>     point forwards. Applications / users would be expected to turn on
>     CPU features explicitly as needed and are considered broken if
> they
>     don't provide this functionality."
> 
> 
> [1]
> https://lists.gnu.org/archive/html/qemu-devel/2018-06/msg08422.html
> 
> [...]
>