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

Daniel P. Berrangé berrange at redhat.com
Fri Sep 16 07:07:56 UTC 2022


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 :|


More information about the libvir-list mailing list