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 E5CAF47D940 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-842208d5b0eso3835770b3a.3 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=YjMV/dpA6Noj+s/2MWUpW2metQDXWv1SCNol/iGpZaRAcgcDRGLf1vFmb5fO36JA7q RadsJ0MXf+59loyiwiwbAmpJy2moDCI2Nl6BW8dMUcAaidMtYsMSZUDY8G7WYE4YYmED r1eEwejyuXRpdQAOTmOh5FRmuNOOlfMD7KGyYm+S1rllZsL195C58OFcIipaxMlwSLjR 5fGU0FRFutjoiD7Ahaqpm0N9yi02nrlsLHG++P4ZmVbONmAdspieLNit+PFiwDGOf3SG k8oCmdz8SMq8MDfJZGn6g4kAbOUBj/Xp9Hbzoa9AYUBtnw6xnVdY/0mWdCGVmJuxMdPE F/og== X-Forwarded-Encrypted: i=1; AFNElJ/jBLowe5vPyW2at0eTcZ7V4zqvlFJP8tq+iyQv2MyZZ4t7qY/+K4mj8l5LotAL9RqFdGaFR1dAhLisQMk=@vger.kernel.org X-Gm-Message-State: AOJu0YyEXjHXoWWEx8+9vWjfKTiZazUGj/5lOp3mJ7NfSIcOqfshEzjq 6lexarz68nsXXyrZ+PQ/RleWZ9BRbPG762nCTBg0uCNxjf3Yy03oK0g6BQ+wiNrXgmsmsmuiaER rUif0mg== 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-kernel@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.