Received: by 2002:ac0:e350:0:0:0:0:0 with SMTP id g16csp2734163imn; Tue, 2 Aug 2022 13:59:23 -0700 (PDT) X-Google-Smtp-Source: AA6agR5vZkdiwJR0vbmapL0xg/u8OHcnCTqx5fARoHKfuQio7Cj5XtkIs8bflpKtDmjm87rBO6SR X-Received: by 2002:a63:e255:0:b0:41c:c80:53cb with SMTP id y21-20020a63e255000000b0041c0c8053cbmr9532370pgj.448.1659473962879; Tue, 02 Aug 2022 13:59:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1659473962; cv=none; d=google.com; s=arc-20160816; b=yGoytJCpDrPbcyg9JIOJUHLwtk36Pgj25oIT3/QTFnKcrbZqAYvpyLjuL0seoTszWP txJQrJEUUZwrXLtX3l7E4JdHzgb3pI7UHB8cznFiQnktbwW5Fu/9eix6KmcFKwop9r+H MMnUH1A6hXwmPEOV7TakBmAq0NXF+QQEm4SX6Q5rrheM7l0aBW7X9vUvU6X5Wdv8aTA/ yNk+engZAztsG9kTNVW9aOv0drz67/PbjBpn0OGm+LmnbAHI/DjISNF2VhAQS+Kz9K7q AhuCWTlVg2ZJbs4BAMelRMIIG9pjklGIKeyu+kcPNO0R4js3FOWMKI7YkSWD3N6RYmAl Mr0w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=X/WDXK9dhhCu2+RqKxktdTeX2bUeOW08JdNOmeWMcTs=; b=iKfbKIXGYQoIRC7F2SQROnLyYNSrMQUvVfzacY04fgYpb2lCesC/ntKuEdzvJUSXN6 D55vsO98hVausVWKDDjnc7eeb0nuZoNIElz8OUriDn/x1qCFVtv3hCL2a5Tj3ZXAGsiu nLBMGOayXjq9mVqOENQ6Mzh8UjbPZZ7pdY1+qTnaTuMqk6LWqIQQH3MwK9/eyVqORz3J vAgcHL8jdReuBETph8W5mHHDpiogsuC8MgBU2D9/WB8PhP5Lx+Z2k+yNgxrNRukBdkw3 NOtcUvLfJl5u9wz3bItvU8pGwYCRLhBpzRZ473CupDOfVDYM89wfqwksb8HX7ZPNOexT uwLg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=NL5o6kvq; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id d5-20020a634f05000000b0041af5f9df9fsi15765281pgb.430.2022.08.02.13.59.08; Tue, 02 Aug 2022 13:59:22 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=NL5o6kvq; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231918AbiHBTq3 (ORCPT + 99 others); Tue, 2 Aug 2022 15:46:29 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37404 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231317AbiHBTq0 (ORCPT ); Tue, 2 Aug 2022 15:46:26 -0400 Received: from mail-pg1-x531.google.com (mail-pg1-x531.google.com [IPv6:2607:f8b0:4864:20::531]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E8374193E3 for ; Tue, 2 Aug 2022 12:46:25 -0700 (PDT) Received: by mail-pg1-x531.google.com with SMTP id 23so13229797pgc.8 for ; Tue, 02 Aug 2022 12:46:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc; bh=X/WDXK9dhhCu2+RqKxktdTeX2bUeOW08JdNOmeWMcTs=; b=NL5o6kvqAp6CZUASniRtCaOagRjx+QG1iSgvPprEwPYurql8OMpuEZmOFx6m2qf6nA g6AMoPP/k+45Ju4Ums6yL1rIn86JnpdNTZzRB3wR92+ODN4ZDUSq9PRH/ku8m/4pc0VM +xxMU2EBVJ+rQ8pvBGQl+hkeiZYhooAeUMAkmmUSyzr3+oCqb+/ahr3m6x3R4vz4sDfo h4MWBl0XsW/uI+K2gflxhy4RJYOgnbdggtvqZpT6LvHVojnLXKm3AxY1gK65VUdw07kJ ewfvJ0dZJGUZybx+ifbQcyonBPrJBF+W8xZt7uYPwDz5wgP2lbjwTpeXbzIlbcZoY9TQ 0lwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc; bh=X/WDXK9dhhCu2+RqKxktdTeX2bUeOW08JdNOmeWMcTs=; b=qsktZcoitf1ZraDo9F3hTbvudXt0qHebhddutyNPqNQ0fYN4OZLM9dmdMKFIJeyQKh yHdt20VGy+A87rb2rCgXcslY8VvRn73prRyU1QEFNEKjqEuOsCXxXYoUB7oG+Shi94Ni vitLCT5Nas0iai9FEcaqurTsRa4jyMgSGDDaKCqQnBvHstOcA54ZWan/PYxd4wbzDYNR eWP25SFrfwak7mAEBFcUhOHAGPD+KB8xsnZ5xK0hn/IzXQc9KwBgnrXoXkQ2L/JD0dFN Ln7Hjw4MEVRwrj/ACP2UX79B944YtoCa1wXXmRsE6i+0Ozk0qzZWQAd5AB33o8FRmfB9 cZTQ== X-Gm-Message-State: AJIora/HPkCZ+iNC2cfp9iUnqAzh3D1rg3LHQfeax/3rCfWGRH0X4GvA rhSjGftfg3UetMOfrgpKaDvwXA== X-Received: by 2002:a05:6a00:1a0e:b0:52a:cef3:b4a1 with SMTP id g14-20020a056a001a0e00b0052acef3b4a1mr22192466pfv.23.1659469585316; Tue, 02 Aug 2022 12:46:25 -0700 (PDT) Received: from google.com (7.104.168.34.bc.googleusercontent.com. [34.168.104.7]) by smtp.gmail.com with ESMTPSA id b12-20020a17090a6acc00b001f4fb21c11asm5439377pjm.21.2022.08.02.12.46.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 02 Aug 2022 12:46:24 -0700 (PDT) Date: Tue, 2 Aug 2022 19:46:21 +0000 From: Sean Christopherson To: isaku.yamahata@intel.com Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, isaku.yamahata@gmail.com, Paolo Bonzini , Kai Huang , Sagi Shahar Subject: Re: [PATCH v7 022/102] KVM: TDX: create/destroy VM structure Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jun 27, 2022, isaku.yamahata@intel.com wrote: > +int tdx_vm_init(struct kvm *kvm) > +{ > + struct kvm_tdx *kvm_tdx = to_kvm_tdx(kvm); > + cpumask_var_t packages; > + int ret, i; > + u64 err; > + > + /* vCPUs can't be created until after KVM_TDX_INIT_VM. */ > + kvm->max_vcpus = 0; > + > + kvm_tdx->hkid = tdx_keyid_alloc(); > + if (kvm_tdx->hkid < 0) > + return -EBUSY; We (Google) have been working through potential flows for intrahost (copyless) migration, and one of the things that came up is that allocating the HKID during KVM_CREATE_VM will be problematic as HKID are a relatively scarce resource. E.g. if all key IDs are in use, then creating a destination TDX VM will be impossible even though intrahost migration can create succeed since the "new" would reuse the source's HKID. Allocating the various pages is also annoying, e.g. they'd have to be freed, but not as directly problematic. SEV (all flavors) has a similar problem with ASIDs. The solution for SEV was to not allocate an ASID during KVM_CREATE_VM and instead "activate" SEV during KVM_CAP_VM_MOVE_ENC_CONTEXT_FROM. I think we should prepare for a similar future for TDX and move the HKID allocation and all dependent resource allocation to KVM_TDX_INIT_VM. AFAICT (and remember), this should be a fairly simple code movement, but I'd prefer it be done before merging TDX so that if it's not so simple, e.g. requires another sub-ioctl, then we don't have to try and tweak KVM's ABI to enable intrahost migration. > + > + ret = tdx_alloc_td_page(&kvm_tdx->tdr); > + if (ret) > + goto free_hkid; > + > + kvm_tdx->tdcs = kcalloc(tdx_caps.tdcs_nr_pages, sizeof(*kvm_tdx->tdcs), > + GFP_KERNEL_ACCOUNT); > + if (!kvm_tdx->tdcs) > + goto free_tdr; > + for (i = 0; i < tdx_caps.tdcs_nr_pages; i++) { > + ret = tdx_alloc_td_page(&kvm_tdx->tdcs[i]); > + if (ret) > + goto free_tdcs; > + }