Message-Id: <20220209074109.453116-1-chao.gao@intel.com>
Date:   Wed,  9 Feb 2022 15:41:01 +0800
From:   Chao Gao <chao.gao@...el.com>
To:     kvm@...r.kernel.org, seanjc@...gle.com, pbonzini@...hat.com,
        kevin.tian@...el.com, tglx@...utronix.de
Cc:     Chao Gao <chao.gao@...el.com>, Albert Ou <aou@...s.berkeley.edu>,
        Aleksandar Markovic <aleksandar.qemu.devel@...il.com>,
        Alexander Gordeev <agordeev@...ux.ibm.com>,
        Alexandru Elisei <alexandru.elisei@....com>,
        Anup Patel <anup@...infault.org>,
        Atish Patra <atishp@...shpatra.org>,
        Benjamin Herrenschmidt <benh@...nel.crashing.org>,
        Bharata B Rao <bharata@...ux.ibm.com>,
        Borislav Petkov <bp@...en8.de>,
        Catalin Marinas <catalin.marinas@....com>,
        Christian Borntraeger <borntraeger@...ux.ibm.com>,
        Claudio Imbrenda <imbrenda@...ux.ibm.com>,
        Daniel Lezcano <daniel.lezcano@...aro.org>,
        "Darrick J. Wong" <djwong@...nel.org>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        David Hildenbrand <david@...hat.com>,
        Fabiano Rosas <farosas@...ux.ibm.com>,
        Heiko Carstens <hca@...ux.ibm.com>,
        "H. Peter Anvin" <hpa@...or.com>,
        Huacai Chen <chenhuacai@...nel.org>,
        Ingo Molnar <mingo@...hat.com>,
        James Morse <james.morse@....com>,
        Janosch Frank <frankja@...ux.ibm.com>,
        Jim Mattson <jmattson@...gle.com>,
        Joerg Roedel <joro@...tes.org>,
        John Garry <john.garry@...wei.com>,
        kvmarm@...ts.cs.columbia.edu, kvm-riscv@...ts.infradead.org,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        linux-mips@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org,
        linux-riscv@...ts.infradead.org, linux-s390@...r.kernel.org,
        "Maciej S. Szmigiero" <maciej.szmigiero@...cle.com>,
        Marc Zyngier <maz@...nel.org>,
        Mel Gorman <mgorman@...hsingularity.net>,
        Michael Ellerman <mpe@...erman.id.au>,
        Nicholas Piggin <npiggin@...il.com>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        Palmer Dabbelt <palmer@...belt.com>,
        Paul Mackerras <paulus@...ba.org>,
        Paul Walmsley <paul.walmsley@...ive.com>,
        Ravi Bangoria <ravi.bangoria@...ux.ibm.com>,
        Shaokun Zhang <zhangshaokun@...ilicon.com>,
        Sumanth Korikkar <sumanthk@...ux.ibm.com>,
        Suzuki K Poulose <suzuki.poulose@....com>,
        Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
        Thomas Richter <tmricht@...ux.ibm.com>,
        Tom Zanussi <tom.zanussi@...ux.intel.com>,
        Vasily Gorbik <gor@...ux.ibm.com>,
        Vitaly Kuznetsov <vkuznets@...hat.com>,
        Wanpeng Li <wanpengli@...cent.com>,
        Will Deacon <will@...nel.org>, x86@...nel.org
Subject: [PATCH v3 0/5] Improve KVM's interaction with CPU hotplug

Changes from v2->v3:
 - rebased to the latest kvm/next branch. 
 - patch 1: rename {svm,vmx}_check_processor_compat to follow the name
	    convention
 - patch 3: newly added to provide more information when hardware enabling
	    fails
 - patch 4: reset hardware_enable_failed if hardware enabling fails. And
	    remove redundent kernel log.
 - patch 5: add a pr_err() for setup_vmcs_config() path.

Changes from v1->v2: (all comments/suggestions on v1 are from Sean, thanks)
 - Merged v1's patch 2 into patch 1, and v1's patch 5 into patch 6.
 - Use static_call for check_processor_compatibility().
 - Generate patch 2 with "git revert" and do manual changes based on that.
 - Loosen the WARN_ON() in kvm_arch_check_processor_compat() instead of
   removing it.
 - KVM always prevent incompatible CPUs from being brought up regardless of
   running VMs.
 - Use pr_warn instead of pr_info to emit logs when KVM finds offending
   CPUs.

KVM registers its CPU hotplug callback to CPU starting section. And in the
callback, KVM enables hardware virtualization on hotplugged CPUs if any VM
is running on existing CPUs.

There are two problems in the process:
1. KVM doesn't do compatibility checks before enabling hardware
virtualization on hotplugged CPUs. This may cause #GP if VMX isn't
supported or vmentry failure if some in-use VMX features are missing on
hotplugged CPUs. Both break running VMs.
2. Callbacks in CPU STARTING section cannot fail. So, even if KVM finds
some incompatible CPUs, its callback cannot block CPU hotplug.

This series improves KVM's interaction with CPU hotplug to avoid
incompatible CPUs breaking running VMs. Following changes are made:

1. move KVM's CPU hotplug callback to ONLINE section (suggested by Thomas)
2. do compatibility checks on hotplugged CPUs.
3. abort onlining incompatible CPUs

This series is a follow-up to the discussion about KVM and CPU hotplug
https://lore.kernel.org/lkml/3d3296f0-9245-40f9-1b5a-efffdb082de9@redhat.com/T/

Note: this series is tested only on Intel systems.

Chao Gao (4):
  KVM: x86: Move check_processor_compatibility from init ops to runtime
    ops
  Partially revert "KVM: Pass kvm_init()'s opaque param to additional
    arch funcs"
  KVM: Rename and move CPUHP_AP_KVM_STARTING to ONLINE section
  KVM: Do compatibility checks on hotplugged CPUs

Sean Christopherson (1):
  KVM: Provide more information in kernel log if hardware enabling fails

 arch/arm64/kvm/arm.c               |  2 +-
 arch/mips/kvm/mips.c               |  2 +-
 arch/powerpc/kvm/powerpc.c         |  2 +-
 arch/riscv/kvm/main.c              |  2 +-
 arch/s390/kvm/kvm-s390.c           |  2 +-
 arch/x86/include/asm/kvm-x86-ops.h |  1 +
 arch/x86/include/asm/kvm_host.h    |  2 +-
 arch/x86/kvm/svm/svm.c             |  4 +-
 arch/x86/kvm/vmx/evmcs.c           |  2 +-
 arch/x86/kvm/vmx/evmcs.h           |  2 +-
 arch/x86/kvm/vmx/vmx.c             | 22 +++++----
 arch/x86/kvm/x86.c                 | 16 +++++--
 include/linux/cpuhotplug.h         |  2 +-
 include/linux/kvm_host.h           |  2 +-
 virt/kvm/kvm_main.c                | 73 +++++++++++++++++++-----------
 15 files changed, 83 insertions(+), 53 deletions(-)

-- 
2.25.1

Powered by blists - more mailing lists