Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp92802pxk; Wed, 23 Sep 2020 23:52:13 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx5dsVs+1gGhSBHLwdA8t/ZUW1s47V66OqYnHhgXvg3VcLwGFm4Sf/Z4yv3/d4Hl2QA1AcJ X-Received: by 2002:a50:e3c4:: with SMTP id c4mr3214951edm.90.1600930332698; Wed, 23 Sep 2020 23:52:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1600930332; cv=none; d=google.com; s=arc-20160816; b=lkVVuMzUHgn83cQ+L2vvx0RQRa9wvpJvih81vaX6glZF3u+hskG2b/EztCbGzK1jRt KSjY4SztJvu2I1YCCPDOA5hb87a3hUSL1dIeKn6bBgjNGBUm06K+Vr3YIJuNlRoMXCtx NocpFxRr3RyeLKqqtRsNO/cg/Z4fsVKMdOIOvbxj0MU0pxK/b+qs+90oSXsWbNVBWC7L fDPmzhtzjTW/5bLt6+HaFIFUIvt2Evqo1xZSbboVJzusf9FoZGw8kTJQBKJr47dQ0asS 5HHfrnGerK3PLWO58sT0xbfJ8XTVaPu5Pnr/K5AUs2ZS37m/0laMANCb9uukH8WhF0dG 5ScA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject:dkim-signature; bh=LIKAioeplGLyiuBbUFdtMjnI7W3D9Z3j5vefA4s4ufw=; b=zJdTieX2n0wkdSmmJ0tFLiSuUEkQWKRGxAqsEt+1P03KZaS029lFcIVI1wLIu1CYpA dRa5oorDf2LBX5cUc3TWgpZPTCd8kCuv8WbUuqV1h9HYx/AuYIGu0CBcYysIVmWXtwMJ 1Z3ghzFJVKwHxUzNnHNMqCwCk8efugQ48V59SMin0t1+YEsj9IptHpC3EkWfCO19H4LR MRixQaP+n8lwCJUJaHEUU0ldFld3qY2pw/2G5/U8tKM1PM+Tk2N9qUthihQ0VO6J7067 r1rRQkN4n/i5lzt3cMOog4nYIV0tWQa+DRCeqmjm0fZvrLhqNCBprQU/Cw/TwVIrJQlj a+wQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=SZzgS9bL; 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=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id da1si1522746edb.102.2020.09.23.23.51.49; Wed, 23 Sep 2020 23:52:12 -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=@redhat.com header.s=mimecast20190719 header.b=SZzgS9bL; 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=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727063AbgIXGun (ORCPT + 99 others); Thu, 24 Sep 2020 02:50:43 -0400 Received: from us-smtp-delivery-124.mimecast.com ([63.128.21.124]:56134 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727049AbgIXGum (ORCPT ); Thu, 24 Sep 2020 02:50:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1600930240; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=LIKAioeplGLyiuBbUFdtMjnI7W3D9Z3j5vefA4s4ufw=; b=SZzgS9bLEIxTgi0sBPfv8894zNw3JG1BfHO9HPWPgq4zbMPqPPcJPDOZYvh2FDBn7ckVXF EP8g1rHpBGRMTkpU/joDRxoc7JrEFDgkWfnbMt8yW8A0w6KpGnydzoqqU5m86ko7ScFr7Z QNTf8B3KoXCPnBEKMO0N30bnkDD5yYg= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-300-z2nTcueKNF69RDK-tVkJSQ-1; Thu, 24 Sep 2020 02:50:37 -0400 X-MC-Unique: z2nTcueKNF69RDK-tVkJSQ-1 Received: by mail-wm1-f72.google.com with SMTP id b20so3186387wmj.1 for ; Wed, 23 Sep 2020 23:50:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=LIKAioeplGLyiuBbUFdtMjnI7W3D9Z3j5vefA4s4ufw=; b=A/BGQSDKHhV4fv0J1xiRjP0gUxWNj2NmU29pngHycBm9COPkVu2xfzC5B0rB4ukMHN V4HJWUu1ppoL+cPVOTdwVjpfadpvd1pKEPZx48BEHRL8Z8vcMUEmacn3SZVqDBp5Nb6a hsPlxNLp66P7mzW1IfZs/1OVUm22OOdm0cw7DpxyEUCP7eQUXXkyFO2pRi0MIz4uFwrQ jYJYC2/EgRz9nxl6O73CW2pH6GHgrN8DsVYPNISJdMbP/lXPgCtG8l2We7RHE5ZUhnKf weQv3dNlN/5/ai2GA0JmlQniG9ZKI40fTBXSdNdR7nkf9jCPxn+dI0DW+jZhnP23l0AC B5xw== X-Gm-Message-State: AOAM532VO0fqd02f9FJBoZOOA8wyOSfmNvdRWh2AJY81+iWRA3a/JyTh fLQfcDQyWHWxUkxb7Q0pUi7+irVVyj+LrOwcoPyeDxqcb0wvdYc7J6UWw/+0uGU8IBvDUBQsaOj Man7thb33jGTX9FEubxGY0C/y X-Received: by 2002:adf:dbc3:: with SMTP id e3mr3333439wrj.1.1600930236327; Wed, 23 Sep 2020 23:50:36 -0700 (PDT) X-Received: by 2002:adf:dbc3:: with SMTP id e3mr3333401wrj.1.1600930236064; Wed, 23 Sep 2020 23:50:36 -0700 (PDT) Received: from ?IPv6:2001:b07:6468:f312:d80e:a78:c27b:93ed? ([2001:b07:6468:f312:d80e:a78:c27b:93ed]) by smtp.gmail.com with ESMTPSA id m18sm2283735wrx.58.2020.09.23.23.50.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 23 Sep 2020 23:50:35 -0700 (PDT) Subject: Re: [PATCH] KVM: Enable hardware before doing arch VM initialization To: Huacai Chen , Sean Christopherson Cc: 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 References: <20200923185757.1806-1-sean.j.christopherson@intel.com> From: Paolo Bonzini Message-ID: <11d4e52e-6bc2-934d-0487-561033b3ab87@redhat.com> Date: Thu, 24 Sep 2020 08:50:33 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 > 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 >> >