From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f202.google.com (mail-pf1-f202.google.com [209.85.210.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E59E147D93B for ; Tue, 16 Jun 2026 17:07:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.202 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781629622; cv=none; b=BwVWeNX1pflj9Db3ytndMd1QOoYHLzAHkKjRVgAR0TbE5BfB7r/UAt2lIIXX2FgzJsV+MZls9m0Q2ZLvSM1uovjHMq4kFHFpxSyqfVTAVYKPDKw6x8M9PHIHbfiCLZxvpQ+0K7KUYR2WefWBJMkoreQwbA3fn/SNE+QqtjPykN4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781629622; c=relaxed/simple; bh=7g+3VFOqzLTevM//CB6btZhXREAjis1zBYeItrSo5zk=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=OGCwtgx/RUsmshsjDjqk16jFK7jYpQD8OMRW4zPTB/T8Qn6spXBTP7u0WXCKjCHz0wVgMp6/0gSNnxV9KI/obaDnWhEanrNvmbDbPz/AZ6NqDxFI1qdey9uWmsYeXzDzu/LswkCXV2Z8Eg8Vl1CMMZLssaAwT/t6dQmRcA2LQgc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=Xa1EgxqC; arc=none smtp.client-ip=209.85.210.202 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="Xa1EgxqC" Received: by mail-pf1-f202.google.com with SMTP id d2e1a72fcca58-84247fed609so2605686b3a.0 for ; Tue, 16 Jun 2026 10:07:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1781629620; x=1782234420; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=MuFT5oHokDW0bk02xVZpBpyZ66QlfdjnHGkLbhNe2ho=; b=Xa1EgxqCs881RK9mo+li2JPIv6hqLAnUJVmI10LlJHZc2Q669sKY6VB4NK5wLuatlf DpRAmwG2FN0HvWt/MCuCVrFPjDzICyawOIwlBlVIeDwe0WYjA/lkFzzC/w+dt7HaOWRU miLsY23TifR77ygF7HgHycW0MyKER2X9JotN8QII5stO19OoYOyVEKlFUqOUVH282p4Y oXHZwbSXGik/J+SNgKAFTv3Sg5DXRdBuW+NMmxVpJOGNMbE9K4d1ZeMebJBlv+CsxnCR ZE5IYx9mCv0EZTO6ol0BZ1eWco6lQ7EaBsVZzduOxYaj1yHp0l8Z45760zy0EUZGb7AP spaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781629620; x=1782234420; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=MuFT5oHokDW0bk02xVZpBpyZ66QlfdjnHGkLbhNe2ho=; b=P0a5H/YOy7lk6W+3K++mWpVDSguzyH0hOaq44gZec9zK+tuY+I+3b160v23pfdAi1o f1X5T9ixaXeSjbjKtLmarU7rMT45mMZsILLnzJ9Lv1JoPVbw4ymEE2jbtr4wIamJ6DpC paT0hNyiNeFxGtNAe4wEWFlP7R1ojzFDhoyq3yGoOcUN6DG4865piAcIM2Ftq5CwD199 xUYrsAquO95mJy0jadaxihmCWGDec4xjiybXjeylMb/jgS2Un6A/x59qSJWegEq3kai5 HM0rLw8jLABlVCxjsQr4D2gJjL0w1noE7iw9+3HPh8rnlrE2MhLgvhNuM+vAGd1QRzTD CgfQ== X-Forwarded-Encrypted: i=1; AFNElJ+jYAHbNGYr/aKWQJd2drirDthCPg9ahVwJxMTHSe51551gvubuI5aSDDvPxs4dpxyu4BBIh9sk2+FmHGndQyw=@vger.kernel.org X-Gm-Message-State: AOJu0YyDTq1umtp1AcV07RoAmWUWdikWKfQm3c2Z+Zzc2hE6++gcFPrY ifNJr0cSeiQbo6YBiJESdn+GlHPdOIxobNOyKypCDi/TW5Gxx8bhgrCDyn+qXcQitM6JwpWa/0B HYIY0YQ== X-Received: from pfbfj40.prod.google.com ([2002:a05:6a00:3a28:b0:842:3d2d:1e84]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a00:600a:b0:841:dcb5:e6f2 with SMTP id d2e1a72fcca58-84524561d40mr12669b3a.23.1781629619966; Tue, 16 Jun 2026 10:06:59 -0700 (PDT) Date: Tue, 16 Jun 2026 10:06:59 -0700 In-Reply-To: Precedence: bulk X-Mailing-List: linux-kselftest@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260521-tdx-selftests-v13-v13-0-6983ae4c3a4d@google.com> <20260521-tdx-selftests-v13-v13-19-6983ae4c3a4d@google.com> Message-ID: Subject: Re: [PATCH v13 19/22] KVM: selftests: Finalize TD memory as part of kvm_arch_vm_finalize_vcpus From: Sean Christopherson To: Ackerley Tng Cc: Lisa Wang , Andrew Jones , Binbin Wu , Chao Gao , Chenyi Qiang , Dave Hansen , Erdem Aktas , Isaku Yamahata , Kiryl Shutsemau , linux-kselftest@vger.kernel.org, Paolo Bonzini , "Pratik R. Sampat" , Reinette Chatre , Rick Edgecombe , Roger Wang , Ryan Afranji , Sagi Shahar , Shuah Khan , Oliver Upton , Jeremiah McReynolds , kvm@vger.kernel.org, linux-coco@lists.linux.dev, linux-kernel@vger.kernel.org, x86@kernel.org Content-Type: text/plain; charset="us-ascii" On Tue, Jun 16, 2026, Ackerley Tng wrote: > >> 1. What do you think of a kvm_arch_vm_finalize() that calls > >> vm_sev_launch() and tdx_vm_finalize()? My key issue is that > >> kvm_arch_vm_finalize_*vcpus*() seems to be for finalizing vCPUs > >> rather than the whole VM. > > > > Key word "seems". I'm pretty sure Oliver picked kvm_arch_vm_finalize_vcpus() as > > the name in commit 8911c7dbc607 ("KVM: arm64: selftests: Create a VGICv3 for > > 'default' VMs") for the same reasons I think it's a good fit for coco VMs: like > > finalizing TDX VMs, initializing the vGIC effectively finalizes vCPUs. > > > > We could rename it to kvm_arch_vm_finalize(), but that won't change the fact that > > we'll need to decide between automagic vs. manual finalization, and it definitely > > should be a separate discussion. > > > > This definitely should not block this series. > > It's coming together for me now with your explanation: > kvm_arch_vm_finalize_vcpus() actually means finalizing vCPUs! vGIC == > Virtual Generic Interrupt Controller, which has to be done after all the > vCPUs are set up. Since the name is describing where in the VM > creation/setup flow the hook is called (after creating VM and after > creating vCPUs), maybe something like kvm_arch_vm_post_vcpu_create()? No, because I would expect post_vcpu_create() to run after creating each vCPU, not after creating all vCPUs. E.g. see KVM's kvm_arch_vcpu_{pre,post}create(). > Renaming this to kvm_arch_vm_finalize() makes it sound like it is > finalizing the VM, but this function shouldn't finalize the VM since for > CoCo finalizing the VM also loads the guest image into the guest - deals > with memory, not just vCPUs. > > 8911c7dbc607 ("KVM: arm64: selftests: Create a VGICv3 for 'default' > VMs") also includes a test_disable_default_vgic() function, we could > also use something like that to skip CoCo VM finalization for some > tests? Maybe that's a good middle ground. That probably won't work well, and in practice it's just shuffling deck chairs on the Titanic. For vGIC, and pre-create hook works because the tests that opt out of automatic vGIC instantiation want that behavior to apply to all VMs that the test creates. That's not the case for sev_smoke_test though, because some testcases need deferred launch (test_sync_vmsa()), whereas others can use automatic launch (test_sev()). The other wrinkle is that SEV at least needs to provide the policy, which again varies per VM within a single test.