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/8a476061c5e034016668cd9e5a20c4430e...
(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
[...]