qemu-commits
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]