[PATCH] cpu_map: Add -noMPX models for x86 Icelake Server
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/processor... 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.1
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/processor...
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/processor...
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/processor...
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/8a476061c5e034016668cd9e5a20c4430ef6b...
(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/8a476061c5e034016668cd9e5a20c4430ef6b...
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 :|
participants (5)
-
Daniel P. Berrangé -
Jiri Denemark -
Kashyap Chamarthy -
Lena Voytek -
Peter Krempa