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

[Lena Voytek]

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?

Thanks,
Lena Voytek

On Fri, Sep 16, 2022 at 12:08 AM Daniel P. Berrangé <berrange at redhat.com>
wrote:

> On Thu, Sep 15, 2022 at 11:00:29AM -0700, Lena Voytek wrote:
> > 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.
>
> On the QEMU side, after the Spectre debacle, anticipating a never
> ending stream of further CPU flaws, we decided that adding new
> CPU variants with further "-xxxx" suffixes was not a sustainable
> idea.  Thus QEMU introduced the idea of versioning CPUs, where a
> bare 'Icelake-Server' CPU would have multiple versions, each with
> distinct set of flags. The idea was that if the user requested
> 'Icelake-Server', libvirt should expand it to the best Icelake-Server-vNN
> version that matched the host the VM was launched on.  Users would not
> need to care about versions, unless they wished to pick a specific
> version for live migration compat reasons. It is unfinished work
> on the libvirt side to do this automatic expansion and handling
> of versioned CPUs.
>
>
> With regards,
> Daniel
> --
> |: https://berrange.com      -o-
> https://www.flickr.com/photos/dberrange :|
> |: https://libvirt.org         -o-
> https://fstop138.berrange.com :|
> |: https://entangle-photo.org    -o-
> https://www.instagram.com/dberrange :|
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20221207/02d038b6/attachment.htm>