src/cpu_map/index.xml | 2 + src/cpu_map/x86_Icelake-Server-noMPX.xml | 93 +++++++++++++++++++ .../x86_Icelake-Server-noTSX-noMPX.xml | 91 ++++++++++++++++++ 3 files changed, 186 insertions(+) create mode 100644 src/cpu_map/x86_Icelake-Server-noMPX.xml create mode 100644 src/cpu_map/x86_Icelake-Server-noTSX-noMPX.xml
Intel has removed MPX capabilities from 10nm Icelake CPUs[1], which is
reflected by the new models through the line marking mpx as removed.
The original Icelake Server models have been left alone to avoid regressions.
This adds:
-Icelake-Server-noMPX
-Icelake-Server-noTSX-noMPX
References:
[1] Memory Protection Extensions support removal
https://www.intel.com/content/www/us/en/support/articles/000059823/processors.html
Fixes: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1978064
https://gitlab.com/libvirt/libvirt/-/issues/304
Signed-off-by: Lena Voytek <lena.voytek@canonical.com>
---
src/cpu_map/index.xml | 2 +
src/cpu_map/x86_Icelake-Server-noMPX.xml | 93 +++++++++++++++++++
.../x86_Icelake-Server-noTSX-noMPX.xml | 91 ++++++++++++++++++
3 files changed, 186 insertions(+)
create mode 100644 src/cpu_map/x86_Icelake-Server-noMPX.xml
create mode 100644 src/cpu_map/x86_Icelake-Server-noTSX-noMPX.xml
diff --git a/src/cpu_map/index.xml b/src/cpu_map/index.xml
index 351c2ae4fa..62c3d44a5c 100644
--- a/src/cpu_map/index.xml
+++ b/src/cpu_map/index.xml
@@ -54,6 +54,8 @@
<include filename='x86_Icelake-Client-noTSX.xml'/>
<include filename='x86_Icelake-Server.xml'/>
<include filename='x86_Icelake-Server-noTSX.xml'/>
+ <include filename='x86_Icelake-Server-noMPX.xml'/>
+ <include filename='x86_Icelake-Server-noTSX-noMPX.xml'/>
<include filename='x86_Cooperlake.xml'/>
<include filename='x86_Snowridge.xml'/>
diff --git a/src/cpu_map/x86_Icelake-Server-noMPX.xml b/src/cpu_map/x86_Icelake-Server-noMPX.xml
new file mode 100644
index 0000000000..feaf21f91f
--- /dev/null
+++ b/src/cpu_map/x86_Icelake-Server-noMPX.xml
@@ -0,0 +1,93 @@
+<cpus>
+ <model name='Icelake-Server-noMPX'>
+ <decode host='on' guest='on'/>
+ <signature family='6' model='106'/> <!-- 0606A5 -->
+ <vendor name='Intel'/>
+ <feature name='3dnowprefetch'/>
+ <feature name='abm'/>
+ <feature name='adx'/>
+ <feature name='aes'/>
+ <feature name='apic'/>
+ <feature name='arat'/>
+ <feature name='avx'/>
+ <feature name='avx2'/>
+ <feature name='avx512-vpopcntdq'/>
+ <feature name='avx512bitalg'/>
+ <feature name='avx512bw'/>
+ <feature name='avx512cd'/>
+ <feature name='avx512dq'/>
+ <feature name='avx512f'/>
+ <feature name='avx512vbmi'/>
+ <feature name='avx512vbmi2'/>
+ <feature name='avx512vl'/>
+ <feature name='avx512vnni'/>
+ <feature name='bmi1'/>
+ <feature name='bmi2'/>
+ <feature name='clflush'/>
+ <feature name='clflushopt'/>
+ <feature name='clwb'/>
+ <feature name='cmov'/>
+ <feature name='cx16'/>
+ <feature name='cx8'/>
+ <feature name='de'/>
+ <feature name='erms'/>
+ <feature name='f16c'/>
+ <feature name='fma'/>
+ <feature name='fpu'/>
+ <feature name='fsgsbase'/>
+ <feature name='fxsr'/>
+ <feature name='gfni'/>
+ <feature name='hle'/>
+ <feature name='intel-pt' removed='yes'/>
+ <feature name='invpcid'/>
+ <feature name='la57'/>
+ <feature name='lahf_lm'/>
+ <feature name='lm'/>
+ <feature name='mca'/>
+ <feature name='mce'/>
+ <feature name='mmx'/>
+ <feature name='movbe'/>
+ <feature name='mpx' removed='yes'/>
+ <feature name='msr'/>
+ <feature name='mtrr'/>
+ <feature name='nx'/>
+ <feature name='pae'/>
+ <feature name='pat'/>
+ <feature name='pcid'/>
+ <feature name='pclmuldq'/>
+ <feature name='pdpe1gb'/>
+ <feature name='pge'/>
+ <feature name='pku'/>
+ <feature name='pni'/>
+ <feature name='popcnt'/>
+ <feature name='pse'/>
+ <feature name='pse36'/>
+ <feature name='rdrand'/>
+ <feature name='rdseed'/>
+ <feature name='rdtscp'/>
+ <feature name='rtm'/>
+ <feature name='sep'/>
+ <feature name='smap'/>
+ <feature name='smep'/>
+ <feature name='spec-ctrl'/>
+ <feature name='ssbd'/>
+ <feature name='sse'/>
+ <feature name='sse2'/>
+ <feature name='sse4.1'/>
+ <feature name='sse4.2'/>
+ <feature name='ssse3'/>
+ <feature name='syscall'/>
+ <feature name='tsc'/>
+ <feature name='tsc-deadline'/>
+ <feature name='umip'/>
+ <feature name='vaes'/>
+ <feature name='vme'/>
+ <feature name='vpclmulqdq'/>
+ <feature name='wbnoinvd'/>
+ <feature name='x2apic'/>
+ <feature name='xgetbv1'/>
+ <feature name='xsave'/>
+ <feature name='xsavec'/>
+ <feature name='xsaveopt'/>
+ </model>
+</cpus>
diff --git a/src/cpu_map/x86_Icelake-Server-noTSX-noMPX.xml b/src/cpu_map/x86_Icelake-Server-noTSX-noMPX.xml
new file mode 100644
index 0000000000..e55da83ddf
--- /dev/null
+++ b/src/cpu_map/x86_Icelake-Server-noTSX-noMPX.xml
@@ -0,0 +1,91 @@
+<cpus>
+ <model name='Icelake-Server-noTSX-noMPX'>
+ <decode host='on' guest='off'/>
+ <signature family='6' model='106'/> <!-- 0606A5 -->
+ <vendor name='Intel'/>
+ <feature name='3dnowprefetch'/>
+ <feature name='abm'/>
+ <feature name='adx'/>
+ <feature name='aes'/>
+ <feature name='apic'/>
+ <feature name='arat'/>
+ <feature name='avx'/>
+ <feature name='avx2'/>
+ <feature name='avx512-vpopcntdq'/>
+ <feature name='avx512bitalg'/>
+ <feature name='avx512bw'/>
+ <feature name='avx512cd'/>
+ <feature name='avx512dq'/>
+ <feature name='avx512f'/>
+ <feature name='avx512vbmi'/>
+ <feature name='avx512vbmi2'/>
+ <feature name='avx512vl'/>
+ <feature name='avx512vnni'/>
+ <feature name='bmi1'/>
+ <feature name='bmi2'/>
+ <feature name='clflush'/>
+ <feature name='clflushopt'/>
+ <feature name='clwb'/>
+ <feature name='cmov'/>
+ <feature name='cx16'/>
+ <feature name='cx8'/>
+ <feature name='de'/>
+ <feature name='erms'/>
+ <feature name='f16c'/>
+ <feature name='fma'/>
+ <feature name='fpu'/>
+ <feature name='fsgsbase'/>
+ <feature name='fxsr'/>
+ <feature name='gfni'/>
+ <feature name='intel-pt' removed='yes'/>
+ <feature name='invpcid'/>
+ <feature name='la57'/>
+ <feature name='lahf_lm'/>
+ <feature name='lm'/>
+ <feature name='mca'/>
+ <feature name='mce'/>
+ <feature name='mmx'/>
+ <feature name='movbe'/>
+ <feature name='mpx' removed='yes'/>
+ <feature name='msr'/>
+ <feature name='mtrr'/>
+ <feature name='nx'/>
+ <feature name='pae'/>
+ <feature name='pat'/>
+ <feature name='pcid'/>
+ <feature name='pclmuldq'/>
+ <feature name='pdpe1gb'/>
+ <feature name='pge'/>
+ <feature name='pku'/>
+ <feature name='pni'/>
+ <feature name='popcnt'/>
+ <feature name='pse'/>
+ <feature name='pse36'/>
+ <feature name='rdrand'/>
+ <feature name='rdseed'/>
+ <feature name='rdtscp'/>
+ <feature name='sep'/>
+ <feature name='smap'/>
+ <feature name='smep'/>
+ <feature name='spec-ctrl'/>
+ <feature name='ssbd'/>
+ <feature name='sse'/>
+ <feature name='sse2'/>
+ <feature name='sse4.1'/>
+ <feature name='sse4.2'/>
+ <feature name='ssse3'/>
+ <feature name='syscall'/>
+ <feature name='tsc'/>
+ <feature name='tsc-deadline'/>
+ <feature name='umip'/>
+ <feature name='vaes'/>
+ <feature name='vme'/>
+ <feature name='vpclmulqdq'/>
+ <feature name='wbnoinvd'/>
+ <feature name='x2apic'/>
+ <feature name='xgetbv1'/>
+ <feature name='xsave'/>
+ <feature name='xsavec'/>
+ <feature name='xsaveopt'/>
+ </model>
+</cpus>
--
2.34.1On Mon, Aug 15, 2022 at 14:11:49 -0700, Lena Voytek wrote: > Intel has removed MPX capabilities from 10nm Icelake CPUs[1], which is > reflected by the new models through the line marking mpx as removed. > > The original Icelake Server models have been left alone to avoid regressions. > > This adds: > -Icelake-Server-noMPX > -Icelake-Server-noTSX-noMPX I didn't find this model in qemu, so this looks like you are inventing a new model in libvirt. While I'm not libvirt's expert on CPUs, but as far as I know libvirt does not invent our own CPU model names. In case of the 'noTSX' versions they were present named in such way in qemu. The only reason we keep them is historical, but in qemu such naming was already deprecated. > References: > > [1] Memory Protection Extensions support removal > https://www.intel.com/content/www/us/en/support/articles/000059823/processors.html > > Fixes: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1978064 > https://gitlab.com/libvirt/libvirt/-/issues/304 In this issue I've linked the appropriate qemu commit, but according to the commit message it seems that the MPX feature was dropped just in certain machine types. This will most likely mean that libvirt will not be able to delete it out of the definition, because we need to be able to preserve compatibility and VM ABI.
On Tue, Aug 16, 2022 at 10:01:16 +0200, Peter Krempa wrote: > On Mon, Aug 15, 2022 at 14:11:49 -0700, Lena Voytek wrote: > > Intel has removed MPX capabilities from 10nm Icelake CPUs[1], which is > > reflected by the new models through the line marking mpx as removed. > > > > The original Icelake Server models have been left alone to avoid regressions. > > > > This adds: > > -Icelake-Server-noMPX > > -Icelake-Server-noTSX-noMPX > > I didn't find this model in qemu, so this looks like you are inventing a > new model in libvirt. > > While I'm not libvirt's expert on CPUs, but as far as I know libvirt > does not invent our own CPU model names. > > In case of the 'noTSX' versions they were present named in such way in > qemu. The only reason we keep them is historical, but in qemu such > naming was already deprecated. > > > References: > > > > [1] Memory Protection Extensions support removal > > https://www.intel.com/content/www/us/en/support/articles/000059823/processors.html > > > > Fixes: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1978064 > > https://gitlab.com/libvirt/libvirt/-/issues/304 > > In this issue I've linked the appropriate qemu commit, but according to > the commit message it seems that the MPX feature was dropped just in > certain machine types. > > This will most likely mean that libvirt will not be able to delete it > out of the definition, because we need to be able to preserve > compatibility and VM ABI. Right. Also the feature is only removed from 10nm CPUs, while 14nm CPUs of the same generation still support it. So what is the actual issue you're trying to fix here? In other words, what steps did you do and what error or incorrect behavior did you see? Jirka
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. 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? Thanks, Lena Voytek On Tue, Aug 16, 2022 at 1:59 AM Jiri Denemark <jdenemar@redhat.com> wrote: > On Tue, Aug 16, 2022 at 10:01:16 +0200, Peter Krempa wrote: > > On Mon, Aug 15, 2022 at 14:11:49 -0700, Lena Voytek wrote: > > > Intel has removed MPX capabilities from 10nm Icelake CPUs[1], which is > > > reflected by the new models through the line marking mpx as removed. > > > > > > The original Icelake Server models have been left alone to avoid > regressions. > > > > > > This adds: > > > -Icelake-Server-noMPX > > > -Icelake-Server-noTSX-noMPX > > > > I didn't find this model in qemu, so this looks like you are inventing a > > new model in libvirt. > > > > While I'm not libvirt's expert on CPUs, but as far as I know libvirt > > does not invent our own CPU model names. > > > > In case of the 'noTSX' versions they were present named in such way in > > qemu. The only reason we keep them is historical, but in qemu such > > naming was already deprecated. > > > > > References: > > > > > > [1] Memory Protection Extensions support removal > > > > https://www.intel.com/content/www/us/en/support/articles/000059823/processors.html > > > > > > Fixes: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1978064 > > > https://gitlab.com/libvirt/libvirt/-/issues/304 > > > > In this issue I've linked the appropriate qemu commit, but according to > > the commit message it seems that the MPX feature was dropped just in > > certain machine types. > > > > This will most likely mean that libvirt will not be able to delete it > > out of the definition, because we need to be able to preserve > > compatibility and VM ABI. > > Right. Also the feature is only removed from 10nm CPUs, while 14nm CPUs > of the same generation still support it. > > So what is the actual issue you're trying to fix here? In other words, > what steps did you do and what error or incorrect behavior did you see? > > Jirka > >
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. > 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. 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. In other words, the change would need to fix some real issue (not just reporting the right CPU to users) to outweigh the disadvantages. Jirka
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
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 :|
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@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 :| > >
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
(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
[...]
--
/kashyap
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 > > [...] >
On Wed, Jan 04, 2023 at 11:55:01AM -0700, Lena Voytek wrote: > 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 That nova code is incorrect. It is comparing a host CPU to a guest CPUI. Nova needs to use the new CPU APIs, to validate whether the configured guest CPU is compatible with KVM guests. 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 :|
© 2016 - 2024 Red Hat, Inc.