Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp119920pxk; Thu, 24 Sep 2020 00:49:40 -0700 (PDT) X-Google-Smtp-Source: ABdhPJylqYpBeNNysmAK8ZvCq93RwZIYK+/GVEc8VYM/KLfxg87/v0zE3HsDxTZe0snEeRi5TSCZ X-Received: by 2002:a17:906:c447:: with SMTP id ck7mr3299840ejb.358.1600933780556; Thu, 24 Sep 2020 00:49:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1600933780; cv=none; d=google.com; s=arc-20160816; b=FDo8vzUe0fQ8+LSrJ31xTooKoE9s327DHop4TGAeCtbjcdY/DSxw4tUPuHKDNOEp2J w5NlT7eVsYBoE79iDZpPjAdbQ51R9ZsQLpiYW9taF7DeF5Iie2A7+pVq6SjPPRjG4UtR PIrGNSaF7flapWw7jK0XsXAKdGd8mMxazYDBjfsuHwdTy+dRytlBp0PcssdNAPauAMAD YUL+xi2przEFsCAMsUNAe5+Vz48NEruwFCXOO+vg44iYGP2qjgoYagwUaBOQNsCeArl3 0Y/wmvrp8fdiDxJBRo3/wYeHmIoyuRYDqoYFqxuf8ia5dXssQHocyR0AzcuNkeiFsOiU QEmw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=IxTyfqdQxLsGAMyRUvmRffvJyTeVBIXZuLoIIydSIMs=; b=P2aW0o4i6+CPpL28ZZ1F7DcKSnAu4YnPt1KtMqdiMeWCO1Z1L4/qVcDE8YST53Nfdc pCQIoDQEUu+9//PPy2kmUSg6hogiNrLr+lT2dVHMSCnqWf+Ic0tM6HpIYrCSKxBUH9Vn BxQawySyuKMZ2flfELrOT+lcYgeOwMiOqaXOEA+9JUWEK/Zgzqvi7iDRhKHteF1WJqEh GO2B0Mm9k6Zg6ypHmGcEa/bcOk4XfPJCwxSserKqutr5tV0DlFVnOUHnpYKjBBU0QqpM sTYrX5ZzDTefMCkwP0EG6TejCqwwbmupTmXIR7A97JPusxAIiw1Fkkl6UY8zomozEC9K +KzQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=L41Sz9Yz; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id f24si1565470edr.375.2020.09.24.00.49.17; Thu, 24 Sep 2020 00:49:40 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=L41Sz9Yz; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727166AbgIXHpZ (ORCPT + 99 others); Thu, 24 Sep 2020 03:45:25 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51782 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727013AbgIXHpY (ORCPT ); Thu, 24 Sep 2020 03:45:24 -0400 Received: from mail-il1-x142.google.com (mail-il1-x142.google.com [IPv6:2607:f8b0:4864:20::142]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AE497C0613CE; Thu, 24 Sep 2020 00:45:24 -0700 (PDT) Received: by mail-il1-x142.google.com with SMTP id h2so2166605ilo.12; Thu, 24 Sep 2020 00:45:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IxTyfqdQxLsGAMyRUvmRffvJyTeVBIXZuLoIIydSIMs=; b=L41Sz9YzaRenimIvko0cU8wwGfr7axecHDVXquVtPxNplBENOLzJAYg2IL9GaVUJ3i ntU0cx8dImDvNIZNvlPxt/ApaKQvmP+swKYbK4olUGDJquS1h2iHEoVstipvyGh1qjc0 qd56UpqhXezSnGi07/FMvcgZOqdbOfz5zb6O7dChp61LZjuCzzJ570TzvVxOwKGtecsh ldTDFKT1pfdmdVvD3nPdi94L6EkuwpnTSVWSXEoLnOPp/j81CkGe5yUscPC2f3p522lm 0rz8K2Zi36Z/ZLRF+JGQ9M/6z+z71XCtW4ud1vWNBHlSTzf7yBDDOcR8oQBk4VqkWmhW FORA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=IxTyfqdQxLsGAMyRUvmRffvJyTeVBIXZuLoIIydSIMs=; b=RG1Qf5M7U3ZE3ipNi3JcSBIQ0c4s/rrvgJeZcPPAw4pCWtEdBkpbaeORgqn6u93alj E98BS5LQI8KtVj2dn8VjIUX/dgcQqs3OBcU/Rk7qwVfP0xVtXW/q6rSitjl2eKzz3d8f dX9v6JWWCXSyq16XbKGt6V3sC1RrUwvrfLNSbk8hkIpkNSvex+UmajvpuC1E6HlvxMOI cz/wcNc758rTtCK0T4z3HDEZ+HW3aH2ZpMzvj4Tjdm3fUvEnovB3ZcIQ6wQdB+cUxeWy M9s8JcTsUNTSTlbt5aZowWcgfb5Ik8rN4vFGSuVU4kD+sr0Ih50eNPAOFmQwW/ZjoSzU yW0w== X-Gm-Message-State: AOAM530+RH5smy4vLdQvaarBP7bS2zIOj4nJYFmLv+dDQoXNCAvkxobw DEeiHOr9BUCcWgboKmEHPizxRj6J23VJwkX1FKo= X-Received: by 2002:a05:6e02:d48:: with SMTP id h8mr2976131ilj.251.1600933524016; Thu, 24 Sep 2020 00:45:24 -0700 (PDT) MIME-Version: 1.0 References: <20200923185757.1806-1-sean.j.christopherson@intel.com> <11d4e52e-6bc2-934d-0487-561033b3ab87@redhat.com> In-Reply-To: <11d4e52e-6bc2-934d-0487-561033b3ab87@redhat.com> From: Huacai Chen Date: Thu, 24 Sep 2020 15:45:12 +0800 Message-ID: Subject: Re: [PATCH] KVM: Enable hardware before doing arch VM initialization To: Paolo Bonzini Cc: Sean Christopherson , kvm , LKML , Marc Zyngier , James Morse , Julien Thierry , Suzuki K Poulose , linux-arm-kernel , Aleksandar Markovic , "open list:MIPS" , Paul Mackerras , kvm-ppc@vger.kernel.org, Christian Borntraeger , Janosch Frank , David Hildenbrand , Cornelia Huck , Claudio Imbrenda , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, Paolo, On Thu, Sep 24, 2020 at 2:50 PM Paolo Bonzini wrote: > > On 24/09/20 08:31, Huacai Chen wrote: > > Hi, Sean, > > > > On Thu, Sep 24, 2020 at 3:00 AM Sean Christopherson > > wrote: > >> > >> Swap the order of hardware_enable_all() and kvm_arch_init_vm() to > >> accommodate Intel's Trust Domain Extension (TDX), which needs VMX to be > >> fully enabled during VM init in order to make SEAMCALLs. > >> > >> This also provides consistent ordering between kvm_create_vm() and > >> kvm_destroy_vm() with respect to calling kvm_arch_destroy_vm() and > >> hardware_disable_all(). > > Do you means that hardware_enable_all() enable VMX, kvm_arch_init_vm() > > enable TDX, and TDX depends on VMX enabled at first? If so, can TDX be > > also enabled at hardware_enable_all()? > > kvm_arch_init_vm() enables TDX *for the VM*, and to do that it needs VMX > instructions (specifically SEAMCALL, which is a hypervisor->"ultravisor" > call). Because that action is VM-specific it cannot be done in > hardware_enable_all(). > > Paolo OK, I know. Reviewed-by: Huacai Chen > > > The swapping seems not affect MIPS, but I observed a fact: > > kvm_arch_hardware_enable() not only be called at > > hardware_enable_all(), but also be called at kvm_starting_cpu(). Even > > if you swap the order, new starting CPUs are not enabled VMX before > > kvm_arch_init_vm(). (Maybe I am wrong because I'm not familiar with > > VMX/TDX). > > > > Huacai > >> > >> Cc: Marc Zyngier > >> Cc: James Morse > >> Cc: Julien Thierry > >> Cc: Suzuki K Poulose > >> Cc: linux-arm-kernel@lists.infradead.org > >> Cc: Huacai Chen > >> Cc: Aleksandar Markovic > >> Cc: linux-mips@vger.kernel.org > >> Cc: Paul Mackerras > >> Cc: kvm-ppc@vger.kernel.org > >> Cc: Christian Borntraeger > >> Cc: Janosch Frank > >> Cc: David Hildenbrand > >> Cc: Cornelia Huck > >> Cc: Claudio Imbrenda > >> Cc: Vitaly Kuznetsov > >> Cc: Wanpeng Li > >> Cc: Jim Mattson > >> Cc: Joerg Roedel > >> Signed-off-by: Sean Christopherson > >> --- > >> > >> Obviously not required until the TDX series comes along, but IMO KVM > >> should be consistent with respect to enabling and disabling virt support > >> in hardware. > >> > >> Tested only on Intel hardware. Unless I missed something, this only > >> affects x86, Arm and MIPS as hardware enabling is a nop for s390 and PPC. > >> Arm looks safe (based on my mostly clueless reading of the code), but I > >> have no idea if this will cause problem for MIPS, which is doing all kinds > >> of things in hardware_enable() that I don't pretend to fully understand. > >> > >> virt/kvm/kvm_main.c | 16 ++++++++-------- > >> 1 file changed, 8 insertions(+), 8 deletions(-) > >> > >> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c > >> index cf88233b819a..58fa19bcfc90 100644 > >> --- a/virt/kvm/kvm_main.c > >> +++ b/virt/kvm/kvm_main.c > >> @@ -766,7 +766,7 @@ static struct kvm *kvm_create_vm(unsigned long type) > >> struct kvm_memslots *slots = kvm_alloc_memslots(); > >> > >> if (!slots) > >> - goto out_err_no_arch_destroy_vm; > >> + goto out_err_no_disable; > >> /* Generations must be different for each address space. */ > >> slots->generation = i; > >> rcu_assign_pointer(kvm->memslots[i], slots); > >> @@ -776,19 +776,19 @@ static struct kvm *kvm_create_vm(unsigned long type) > >> rcu_assign_pointer(kvm->buses[i], > >> kzalloc(sizeof(struct kvm_io_bus), GFP_KERNEL_ACCOUNT)); > >> if (!kvm->buses[i]) > >> - goto out_err_no_arch_destroy_vm; > >> + goto out_err_no_disable; > >> } > >> > >> kvm->max_halt_poll_ns = halt_poll_ns; > >> > >> - r = kvm_arch_init_vm(kvm, type); > >> - if (r) > >> - goto out_err_no_arch_destroy_vm; > >> - > >> r = hardware_enable_all(); > >> if (r) > >> goto out_err_no_disable; > >> > >> + r = kvm_arch_init_vm(kvm, type); > >> + if (r) > >> + goto out_err_no_arch_destroy_vm; > >> + > >> #ifdef CONFIG_HAVE_KVM_IRQFD > >> INIT_HLIST_HEAD(&kvm->irq_ack_notifier_list); > >> #endif > >> @@ -815,10 +815,10 @@ static struct kvm *kvm_create_vm(unsigned long type) > >> mmu_notifier_unregister(&kvm->mmu_notifier, current->mm); > >> #endif > >> out_err_no_mmu_notifier: > >> - hardware_disable_all(); > >> -out_err_no_disable: > >> kvm_arch_destroy_vm(kvm); > >> out_err_no_arch_destroy_vm: > >> + hardware_disable_all(); > >> +out_err_no_disable: > >> WARN_ON_ONCE(!refcount_dec_and_test(&kvm->users_count)); > >> for (i = 0; i < KVM_NR_BUSES; i++) > >> kfree(kvm_get_bus(kvm, i)); > >> -- > >> 2.28.0 > >> > > >