[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-commits] [qemu/qemu] 485b1d: i386: kvm: Disable arch_capabilities
From: |
Peter Maydell |
Subject: |
[Qemu-commits] [qemu/qemu] 485b1d: i386: kvm: Disable arch_capabilities if MSR can't ... |
Date: |
Fri, 22 Mar 2019 03:39:11 -0700 |
Branch: refs/heads/master
Home: https://github.com/qemu/qemu
Commit: 485b1d256bcb0874bcde0223727c159b6837e6f8
https://github.com/qemu/qemu/commit/485b1d256bcb0874bcde0223727c159b6837e6f8
Author: Eduardo Habkost <address@hidden>
Date: 2019-03-20 (Wed, 20 Mar 2019)
Changed paths:
M target/i386/kvm.c
Log Message:
-----------
i386: kvm: Disable arch_capabilities if MSR can't be set
KVM has two bugs in the handling of MSR_IA32_ARCH_CAPABILITIES:
1) Linux commit commit 1eaafe91a0df ("kvm: x86: IA32_ARCH_CAPABILITIES
is always supported") makes GET_SUPPORTED_CPUID return
arch_capabilities even if running on SVM. This makes "-cpu
host,migratable=off" incorrectly expose arch_capabilities on CPUID on
AMD hosts (where the MSR is not emulated by KVM).
2) KVM_GET_MSR_INDEX_LIST does not return MSR_IA32_ARCH_CAPABILITIES if
the MSR is not supported by the host CPU. This makes QEMU not
initialize the MSR properly at kvm_put_msrs() on those hosts.
Work around both bugs on the QEMU side, by checking if the MSR
was returned by KVM_GET_MSR_INDEX_LIST before returning the
feature flag on kvm_arch_get_supported_cpuid().
This has the unfortunate side effect of making arch_capabilities
unavailable on hosts without hardware support for the MSR until bug #2
is fixed on KVM, but I can't see another way to work around bug #1
without that side effect.
Signed-off-by: Eduardo Habkost <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Eduardo Habkost <address@hidden>
Commit: 014018e19b3c54dd1bf5072bc912ceffea40abe8
https://github.com/qemu/qemu/commit/014018e19b3c54dd1bf5072bc912ceffea40abe8
Author: Eduardo Habkost <address@hidden>
Date: 2019-03-20 (Wed, 20 Mar 2019)
Changed paths:
M target/i386/cpu.c
Log Message:
-----------
i386: Make arch_capabilities migratable
Now that kvm_arch_get_supported_cpuid() will only return
arch_capabilities if QEMU is able to initialize the MSR properly,
we know that the feature is safely migratable.
Signed-off-by: Eduardo Habkost <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Eduardo Habkost <address@hidden>
Commit: bb4928c7cafe50ab2137a0034e350ef1bfa044d9
https://github.com/qemu/qemu/commit/bb4928c7cafe50ab2137a0034e350ef1bfa044d9
Author: Eduardo Habkost <address@hidden>
Date: 2019-03-20 (Wed, 20 Mar 2019)
Changed paths:
M target/i386/cpu.c
A tests/acceptance/cpu_queries.py
Log Message:
-----------
i386: Disable OSPKE on CPU model definitions
Currently, the Cascadelake-Server, Icelake-Client, and
Icelake-Server are always generating the following warning:
qemu-system-x86_64: warning: \
host doesn't support requested feature: CPUID.07H:ECX [bit 4]
This happens because OSPKE was never returned by
GET_SUPPORTED_CPUID or x86_cpu_get_supported_feature_word().
OSPKE is a runtime flag automatically set by the KVM module or by
TCG code, was always cleared by x86_cpu_filter_features(), and
was not supposed to appear on the CPU model table.
Remove the OSPKE flag from the CPU model table entries, to avoid
the bogus warning and avoid returning invalid feature data on
query-cpu-* QMP commands. As OSPKE was always cleared by
x86_cpu_filter_features(), this won't have any guest-visible
impact.
Include a test case that should detect the problem if we introduce
a similar bug again.
Fixes: c7a88b52f62b ("i386: Add new model of Cascadelake-Server")
Fixes: 8a11c62da914 ("i386: Add new CPU model Icelake-{Server,Client}")
Cc: Tao Xu <address@hidden>
Cc: Robert Hoo <address@hidden>
Signed-off-by: Eduardo Habkost <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Eduardo Habkost <address@hidden>
Commit: 174a78a8a5c0cf421236fe14efc5559717f050df
https://github.com/qemu/qemu/commit/174a78a8a5c0cf421236fe14efc5559717f050df
Author: Daniel P. Berrangé <address@hidden>
Date: 2019-03-20 (Wed, 20 Mar 2019)
Changed paths:
M docs/qemu-cpu-models.texi
Log Message:
-----------
docs: clarify that spec-ctrl is only needed for Spectre v2
The docs currently say that the spec-ctrl feature is needed for both
Spectre variants, but it is only used to address Spectre v2. Also
remove the note about retpolines. The guest OS is usually treated
as a blackbox from host mgmt pov, so it won't have knowledge about
use of retpolines and thus should unconditionally expose spec-ctrl,
allowing the guest to decide whether to use it or not.
Signed-off-by: Daniel P. Berrangé <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Eduardo Habkost <address@hidden>
Commit: 21ee4787e53367590f284915bf4c30c684e65bdf
https://github.com/qemu/qemu/commit/21ee4787e53367590f284915bf4c30c684e65bdf
Author: Daniel P. Berrangé <address@hidden>
Date: 2019-03-20 (Wed, 20 Mar 2019)
Changed paths:
M docs/qemu-cpu-models.texi
Log Message:
-----------
docs: add note about stibp CPU feature for spectre v2
While the stibp CPU feature is not commonly used by guest OS for spectre
mitigation due to its performance impact, it is none the less best
practice to expose it to all guest OS. This allows the guest OS to
decide whether to make use or it.
Signed-off-by: Daniel P. Berrangé <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Eduardo Habkost <address@hidden>
Commit: d97a39d903fe33c45be83ac6943a2f82a3649a11
https://github.com/qemu/qemu/commit/d97a39d903fe33c45be83ac6943a2f82a3649a11
Author: Peter Maydell <address@hidden>
Date: 2019-03-22 (Fri, 22 Mar 2019)
Changed paths:
M docs/qemu-cpu-models.texi
M target/i386/cpu.c
M target/i386/kvm.c
A tests/acceptance/cpu_queries.py
Log Message:
-----------
Merge remote-tracking branch 'remotes/ehabkost/tags/x86-next-pull-request'
into staging
x86 queue for -rc1
A few fixes that missed -rc0:
* CPU model documentation updates (Daniel P. Berrangé)
* Fix bogus OSPKE warnings (Eduardo Habkost)
* Work around KVM bugs when handing arch_capabilities
(Eduardo Habkost)
# gpg: Signature made Thu 21 Mar 2019 19:32:02 GMT
# gpg: using RSA key 2807936F984DC5A6
# gpg: Good signature from "Eduardo Habkost <address@hidden>" [full]
# Primary key fingerprint: 5A32 2FD5 ABC4 D3DB ACCF D1AA 2807 936F 984D C5A6
* remotes/ehabkost/tags/x86-next-pull-request:
docs: add note about stibp CPU feature for spectre v2
docs: clarify that spec-ctrl is only needed for Spectre v2
i386: Disable OSPKE on CPU model definitions
i386: Make arch_capabilities migratable
i386: kvm: Disable arch_capabilities if MSR can't be set
Signed-off-by: Peter Maydell <address@hidden>
Compare: https://github.com/qemu/qemu/compare/c692931cda9d...d97a39d903fe
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Qemu-commits] [qemu/qemu] 485b1d: i386: kvm: Disable arch_capabilities if MSR can't ...,
Peter Maydell <=