@Christian,
I'm flagging the libvirt SRUs as Opinion. So far I have done quite a lot
cherry-picks and backports identifying all the structures that have
changed and I'm not currently seeing how this can be done as a SRU (even
for Disco). There are quite a few data model changes to how libvirt was
acquiring CPU features (and, now, missing features) that simply wont fit
into SRU rules.
The base need for the features would be:
commit c145b660b8225f73db16660461077ef931730939
Author: Jiri Denemark <jdene...@redhat.com>
Date: Fri Jun 7 09:07:10 2019
cpu_conf: Introduce virCPUDefFilterFeatures
This new internal API can be used for in place filtering of CPU features
in virCPUDef.
Signed-off-by: Jiri Denemark <jdene...@redhat.com>
Reviewed-by: Ján Tomko <jto...@redhat.com>
----
commit 2a4c23210674b453f91569f0f4b9fd5ebe8d7906
Author: Jiri Denemark <jdene...@redhat.com>
Date: Mon Jun 10 11:46:10 2019
qemu: Probe for max-x86_64-cpu type
We will use it to check whether QEMU supports a specific CPU
property.
Signed-off-by: Jiri Denemark <jdene...@redhat.com>
Reviewed-by: Ján Tomko <jto...@redhat.com>
----
commit 0d254bce4ec6fd62c0277d24e28bf018a4c6cb37
Author: Jiri Denemark <jdene...@redhat.com>
Date: Mon Jun 10 11:49:22 2019
qemu: Probe for "unavailable-features" CPU property
It is similar to "filtered-features" property, which reports CPUID bits
corresponding to disabled features, but more general. The
"unavailable-features" property supports both CPUID and MSR features by
listing their names.
Signed-off-by: Jiri Denemark <jdene...@redhat.com>
Reviewed-by: Ján Tomko <jto...@redhat.com>
----
commit 4e6f58b8d55d44fa9f80736b2745b44710f6e25a
Author: Jiri Denemark <jdene...@redhat.com>
Date: Wed Jun 19 14:01:30 2019
conf: Introduce virCPUDefCheckFeatures
This API can be used to check whether a CPU definition contains features
matching a given filter.
Signed-off-by: Jiri Denemark <jdene...@redhat.com>
Reviewed-by: Ján Tomko <jto...@redhat.com>
----
commit b8e086a570b14b1f83fc07e25df6da758abe7706
Author: Jiri Denemark <jdene...@redhat.com>
Date: Wed Jun 19 16:58:01 2019
cpu_x86: Turn virCPUx86DataIteratorInit into a function
Until now, this was a macro usable for direct initialization when a
variable is defined. Turning the macro into a function makes it more
general.
Signed-off-by: Jiri Denemark <jdene...@redhat.com>
Reviewed-by: Ján Tomko <jto...@redhat.com>
< compiles good >
Then we would need the backport of:
cpu_x86: Introduce virCPUx86DataItem container struct
The following patches introduce CPU features read from MSR in addition
to those queried via CPUID instruction. Let's introduce a container
struct which will be able to describe either feature type.
Signed-off-by: Jiri Denemark <jdene...@redhat.com>
Reviewed-by: Ján Tomko <jto...@redhat.com>
AND all the ones bellow:
fcf4846a6b cpu_x86: Add support for storing MSR features in CPU map
370177e2f6 cpu_x86: Store virCPUx86DataItem content in union
10b80165db cpu_x86: Make x86cpuidMatch more general
2eea67a98e cpu_x86: Make x86cpuidMatchMasked more general
da1efddfa6 cpu_x86: Make x86cpuidAndBits more general
4e3cab2d00 cpu_x86: Make x86cpuidClearBits more general
9c6f00fc33 cpu_x86: Make x86cpuidSetBits more general
559ccd7815 cpu_x86: Introduce virCPUx86DataCmp
0fdc0ad84c cpu_x86: Simplify x86DataAdd
3eff71a2d5 cpu_x86: Rename virCPUx86VendorToCPUID
8f1a8ce397 cpu_x86: Rename virCPUx86DataAddCPUID
ce42042577 cpu_x86: Rename virCPUx86DataAddCPUIDInt
95accfa7fa cpu_x86: Rename virCPUx86CPUIDSorter
609f467f13 cpu_x86: Rename x86DataCpuid
5655b83139 cpu_x86: Rename x86DataCpuidNext function
6c22b329d5 cpu_x86: Rename virCPUx86DataItem variables
c02d70d52e cpu_x86: Rename virCPUx86Vendor.cpuid
AT LEAST to compile the virCPUx86DataItem container feature.
----
Continuing, we would, still, need:
commit bcfed7f1c84cbff21d129a79cbd675b0cd51613c
Author: Jiri Denemark <jdene...@redhat.com>
Date: Wed Jun 19 16:59:12 2019
cpu_x86: Introduce virCPUx86FeatureFilter*MSR
This functions may be used as a virCPUDefFeatureFilter callbacks for
virCPUDefCheckFeatures, virCPUDefFilerFeatures, and similar functions to
select (virCPUx86FeatureFilterSelectMSR) or drop
(virCPUx86FeatureFilterDropMSR) features reported via MSR.
Signed-off-by: Jiri Denemark <jdene...@redhat.com>
Reviewed-by: Ján Tomko <jto...@redhat.com>
commit 56b254dccc96b7339494812c9df07ccf6af3da95
Author: Jiri Denemark <jdene...@redhat.com>
Date: Fri Mar 22 12:52:21 2019
cpu_x86: Read CPU features from IA32_ARCH_CAPABILITIES MSR
This is used by the host capabilities code to construct host CPU
definition.
Signed-off-by: Jiri Denemark <jdene...@redhat.com>
Reviewed-by: Ján Tomko <jto...@redhat.com>
commit c8ec678fd9d97189667c0121f48a220dd26856b7
Author: Jiri Denemark <jdene...@redhat.com>
Date: Thu Mar 14 11:44:38 2019
cpu_map: Introduce IA32_ARCH_CAPABILITIES MSR features
Signed-off-by: Jiri Denemark <jdene...@redhat.com>
Reviewed-by: Ján Tomko <jto...@redhat.com>
commit 8eb4a89f5f7973f50aa8b6fa0b1a45b825dda208
Author: Jiri Denemark <jdene...@redhat.com>
Date: Wed Jun 19 16:59:49 2019
qemu: Forbid MSR features with old QEMU
Without "unavailable-features" CPU property we cannot properly detect
whether a specific MSR feature we asked for (either explicitly or
implicitly via a CPU model) was disabled by QEMU for some reason.
Because this could break migration, snapshots, and save/restore
operaions, it's better to just forbid any use of MSR features with QEMU
which lacks "unavailable-features" CPU property.
Signed-off-by: Jiri Denemark <jdene...@redhat.com>
Reviewed-by: Ján Tomko <jto...@redhat.com>
commit 2674d00ed484091faf2b6e6b1efe58ee9a72b96b
Author: Jiri Denemark <jdene...@redhat.com>
Date: Wed Jun 19 17:22:09 2019
qemu: Drop MSR features from host-model with old QEMU
With QEMU versions which lack "unavailable-features" we use CPUID based
detection of features which were enabled or disabled once QEMU starts.
Thus using MSR features with host-model would result in all of them
being marked as disabled in the active domain definition even though
QEMU did not actually disable them.
Let's make sure we add MSR features to host-model only when
"unavailable-features" property is supported by QEMU.
Signed-off-by: Jiri Denemark <jdene...@redhat.com>
Reviewed-by: Ján Tomko <jto...@redhat.com>
and possibly many others as dependencies to these last.
----
There are some optional things like:
commit 5030a7450b0f0117a7903303572c6bda6c012327
Author: Jiri Denemark <jdene...@redhat.com>
Date: Fri Jun 7 10:00:28 2019
qemu_command: Use canonical names of CPU features
When building QEMU command line, we should use the preferred spelling of
each CPU feature without relying on compatibility aliases (which may be
removed at some point).
The "unavailable-features" CPU property is used as a witness for the
correct names of the features in our translation table.
Signed-off-by: Jiri Denemark <jdene...@redhat.com>
Reviewed-by: Ján Tomko <jto...@redhat.com>
which will change the canonical names for the CPU features (which is
something used by the commits that will create the arch_capabilities and
unavailable-features features).
----
So, IMO, we should keep QEMU cmdline XML arguments for the mitigation
features and tell users to use *at least* Eoan's libvirt for the arch-
capabilities feature in libvirt. Orelse we would have to either backport
tons of libvirt patches OR workaround this by creating or own version,
which is a no-no for SRUs.
Any objection ?
PS: We still need to document the arch-capabilities and all the
mitigations it advertises (and features enabled/disabled in cmdline amd,
possibly, now, in libvirt as cmdline xml extra arguments).
** Changed in: libvirt (Ubuntu Disco)
Status: Confirmed => Opinion
** Changed in: libvirt (Ubuntu Bionic)
Status: Confirmed => Won't Fix
** Changed in: libvirt (Ubuntu Bionic)
Assignee: Rafael David Tinoco (rafaeldtinoco) => (unassigned)
** Changed in: linux (Ubuntu Disco)
Assignee: Rafael David Tinoco (rafaeldtinoco) => (unassigned)
** Changed in: linux (Ubuntu Bionic)
Assignee: Rafael David Tinoco (rafaeldtinoco) => (unassigned)
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1828495
Title:
[KVM][CLX] CPUID_7_0_EDX_ARCH_CAPABILITIES is not enabled in VM.
Status in intel:
New
Status in libvirt package in Ubuntu:
Fix Released
Status in linux package in Ubuntu:
In Progress
Status in qemu package in Ubuntu:
Fix Released
Status in libvirt source package in Bionic:
Won't Fix
Status in linux source package in Bionic:
Confirmed
Status in qemu source package in Bionic:
Fix Released
Status in libvirt source package in Disco:
Opinion
Status in linux source package in Disco:
Confirmed
Status in qemu source package in Disco:
Fix Released
Status in libvirt source package in Eoan:
Fix Released
Status in linux source package in Eoan:
In Progress
Status in qemu source package in Eoan:
Fix Released
Bug description:
[Impact]
* QEMU does not support IceLake and CascadeLake CPUs specific features.
* Most important feature to be supported is: IA32_ARCH_CAPABILITIES MSR.
* With IA32_ARCH_CAPABILITIES, QEMU is able to advertise HW mitigations:
- Rogue Data Cache Load
- Enhanced IBRS
- RSB Alternate
- L1D flush need on VMENTRY
- speculative Store Bypass
to guests, as described in document:
Intel 336996-Speculative-Execution-Side-Channel-Mitigations.pdf
[Test Case]
* From Original Description:
"""
1. Boot up guest using: -cpu Cascadelake-Server
[root@clx-2s2 yexin]# qemu-system-x86_64 -accel kvm -drive
if=virtio,id=hd,file=/home/x/x,format=qcow2 -m 4096 -smp 4 -cpu
Cascadelake-Server -serial stdio
char device redirected to /dev/pts/3 (label serial0)
qemu-system-x86_64: warning: host doesn't support requested feature:
CPUID.07H:ECX [bit 4]
qemu-system-x86_64: warning: host doesn't support requested feature:
CPUID.07H:ECX [bit 4]
qemu-system-x86_64: warning: host doesn't support requested feature:
CPUID.07H:ECX [bit 4]
qemu-system-x86_64: warning: host doesn't support requested feature:
CPUID.07H:ECX [bit 4]
2. To check CPU ID related to features[FEAT_7_0_EDX]
：CPUID_7_0_EDX_ARCH_CAPABILITIES
Expected Result: Both host and guest's CPUID.07H EDX bit 29 should be
1.
Actual Result:
Host's cpuid: 0x00000007 0x00: eax=0x00000000 ebx=0xd39ffffb
ecx=0x00000818 edx=0xbc000000 (EDX bit 29=1)
Guest's cpuid : 0x00000007 0x00: eax=0x00000000 ebx=0xd19f0fb9
ecx=0x00000818 edx=0x84000000 (EDX bit 29=0)
Commit:2bdb76c015df7125783d8394d6339d181cb5bc30
Target Kerned: 5.1
Target Release: 19.10
"""
[Regression Potential]
* Most changes are related to CPU type definitions and its supported
features. They are all based in upstream changes but, for obvious
reasons, backporting and/or cherry-picking those could bring issues.
Biggest concern is breaking something that currently works. Right now,
the parts being changed that could affect other CPU types would be
related to a small refactoring of how the features are organized, and
that would be seen right away when trying to start a new VM after the
package is installed.
* Other tests, related to the features being backported, are being
done by our KVM regression tests, including migration combinations, to
reduce chances that a regression is introduced.
[Other Info]
* N/A
To manage notifications about this bug go to:
https://bugs.launchpad.net/intel/+bug/1828495/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
