From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id B22FEC001DC for ; Mon, 17 Jul 2023 17:13:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230013AbjGQRM7 (ORCPT ); Mon, 17 Jul 2023 13:12:59 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34556 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230405AbjGQRMn (ORCPT ); Mon, 17 Jul 2023 13:12:43 -0400 Received: from mail-pl1-x635.google.com (mail-pl1-x635.google.com [IPv6:2607:f8b0:4864:20::635]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5706E1B5; Mon, 17 Jul 2023 10:12:41 -0700 (PDT) Received: by mail-pl1-x635.google.com with SMTP id d9443c01a7336-1bb1baf55f5so25365515ad.0; Mon, 17 Jul 2023 10:12:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1689613961; x=1692205961; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=Su4c46X8cRa6PHlO4wAUnjVZ+C+9OAGrRoJ7Aqgs5cU=; b=WhyYIPZO2p/YK6SgdYh6KiwmnlwFGuP6x4o8fFwfjzP+k6nWK6x2EQrcUhIMLtG4Mx Whm04pBT4llFHDRUKvbjL0pDnzPiWOCd/ANwoVihiOr3NeNeZHJRYz0SiP5iIDYNIjJg PmgNSHJFfg1lwtCaKM591/qkZ/cYCDZ1TjeOybC+bVwttAqPs6U1Fmle4dPAXzrMlTGS Z6SA5nrmWax6/N8LUJOUjn4e2BsXzJeu0Ksg/n6Joopb4MpWdOyoV/pkAb/95N1JFM5c X6LeAWmt4mA3kiYVq5eRRer7lQUjtG2K7gtpBKq+38Dq2qO1PxQn/EY9BL/t/YMzuFUl GRpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689613961; x=1692205961; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Su4c46X8cRa6PHlO4wAUnjVZ+C+9OAGrRoJ7Aqgs5cU=; b=X70VBmRqRHBgjXsHMlk/Sw7cpn5uX7zTa7j+QKZAI1WgIbbdKpj4kHFMn5qk3ADD0v QDTL9X+19KKsi+CLcm5ZkHJL73aKwNVDfpx74GKk06Gi0UBMjspCgo8Qy3Ufas5Sp3fU MNkk1IkS8gDiq0zKX+buuZAI4ZuR0Po1+QtIzW23M2zMcDrrmv+yZAgyD9tQU+zbiGwz t9UxHhxvHmxeYzwDTnGSEvmGsKu0hPpOTUtcFVVF19zImqg3PUgt8oX9kE/1sJzWPFT2 RcImfmeZQ4fDZKpXcs5rrNjUjkC4GRYz2M8n9ExaKcUfT+1dNAn9O0bSNbplVP9UHsl2 Ii3Q== X-Gm-Message-State: ABy/qLaGESUUwe4s17WxxSvzc8huoysC3xenTFqWeuVpOoViyzAKbs6q eXdCIRPm+3ZryBoGMKJzGiVH0Iv2ehc= X-Google-Smtp-Source: APBJJlFKrg3zrMVnT4y3lM3F/XIOZCnHovdC25gxGLpXATGcGi9mXUoOJGZ6EIElYox6qUlWKCmNIg== X-Received: by 2002:a17:902:e550:b0:1b8:7e53:704 with SMTP id n16-20020a170902e55000b001b87e530704mr14859904plf.27.1689613960688; Mon, 17 Jul 2023 10:12:40 -0700 (PDT) Received: from localhost ([192.55.54.50]) by smtp.gmail.com with ESMTPSA id j17-20020a170902da9100b001b9d88a4d1asm112268plx.289.2023.07.17.10.12.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 17 Jul 2023 10:12:40 -0700 (PDT) Date: Mon, 17 Jul 2023 10:12:38 -0700 From: Isaku Yamahata To: "Wen, Qian" Cc: isaku.yamahata@intel.com, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, isaku.yamahata@gmail.com, Paolo Bonzini , erdemaktas@google.com, Sean Christopherson , Sagi Shahar , David Matlack , Kai Huang , Zhi Wang , chen.bo@intel.com Subject: Re: [PATCH v14 072/113] KVM: TDX: handle vcpu migration over logical processor Message-ID: <20230717171238.GA25699@ls.amr.corp.intel.com> References: <7a57603a0668ec51a7ac324ab3d1a8acb9863e7b.1685333728.git.isaku.yamahata@intel.com> <48951fc1-4e98-b32a-af4f-343b7ea2d44d@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <48951fc1-4e98-b32a-af4f-343b7ea2d44d@intel.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jul 12, 2023 at 02:08:15PM +0800, "Wen, Qian" wrote: > On 5/29/2023 12:19 PM, isaku.yamahata@intel.com wrote: > > From: Isaku Yamahata > > > > For vcpu migration, in the case of VMX, VMCS is flushed on the source pcpu, > > and load it on the target pcpu. There are corresponding TDX SEAMCALL APIs, > > call them on vcpu migration. The logic is mostly same as VMX except the > > TDX SEAMCALLs are used. > > > > When shutting down the machine, (VMX or TDX) vcpus needs to be shutdown on > > each pcpu. Do the similar for TDX with TDX SEAMCALL APIs. > > > > Signed-off-by: Isaku Yamahata > > --- > > arch/x86/kvm/vmx/main.c | 32 ++++++- > > arch/x86/kvm/vmx/tdx.c | 168 +++++++++++++++++++++++++++++++++++++ > > arch/x86/kvm/vmx/tdx.h | 2 + > > arch/x86/kvm/vmx/x86_ops.h | 4 + > > 4 files changed, 203 insertions(+), 3 deletions(-) > > > > diff --git a/arch/x86/kvm/vmx/main.c b/arch/x86/kvm/vmx/main.c > > index 17fb1515e56a..29ebd171dbe3 100644 > > ... > > > @@ -455,6 +606,19 @@ void tdx_vcpu_free(struct kvm_vcpu *vcpu) > > return; > > } > > > > + /* > > + * kvm_free_vcpus() > > + * -> kvm_unload_vcpu_mmu() > > + * > > + * does vcpu_load() for every vcpu after they already disassociated > > + * from the per cpu list when tdx_vm_teardown(). So we need to > > + * disassociate them again, otherwise the freed vcpu data will be > > + * accessed when do list_{del,add}() on associated_tdvcpus list > > + * later. > > + */ > > Nit: kvm_free_vcpus() and tdx_vm_teardown() are typos? I don't find these functions. kvm_free_vcpus() => kvm_destroy_vcpus() tdx_vm_teardown() => tdx_mmu_release_hkid() Will fix the comment. -- Isaku Yamahata