From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-lf1-f46.google.com (mail-lf1-f46.google.com [209.85.167.46]) (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 42A7F4414 for ; Tue, 12 Jul 2022 16:04:20 +0000 (UTC) Received: by mail-lf1-f46.google.com with SMTP id o7so14696898lfq.9 for ; Tue, 12 Jul 2022 09:04:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=c0RcQSLjeYCnLvxH8el7ACbuvLKqs4ymAPhMSssf3fo=; b=rgy8GpGjigNewPkDfawGIyJhs5SthypU/zUHIYssEnhqMMiqNAKc4ezJ19mpUkfSMy nHlnPMccqvaAAhX/ySaXKSzNEJ+RUL0TBhSHaW0HqHGvmgX2wxKuTd+jA0VHIQPZ9QFF a6LEAvMbeWy1+vmRd8d6u+JJ7f13B0rTgQTdohwT7+APFsOdcZJnmvacai86xywgvwxZ kEZYabnYpVeCuAKxSwQRmTLVQyoTaFQAZoagdzVEMYGEcN4G14TusnppOWvHU3N4UMpc t6xNmt5QTEm/TElgI+kc11twOzYFn1L/5P2tE2Iy6Q0EvlpQEc4560MbpDvwkPfROLHC yEdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=c0RcQSLjeYCnLvxH8el7ACbuvLKqs4ymAPhMSssf3fo=; b=7wsd6FjXEFtPGdmUFJcC4CikuaBWnq2r0TQgXrq3I0f36cyhmmgwm4Rp8ckQHD/1aI knVwF7Ou9f0bA4u4CigqBPk/DljmRnTt5Uj/eDA5BayNcGEcSzC44XhHFbvOimeFjcJy 7+CEYuAQFtoim7GRHgyOKQjZ5BIfLTzxhUkuk/6Ag6fauEcRFx3idGqGhOn6oCUavc1P nQkWnJaEdSZ76BKKaZ1OOpYVvMs6jRcRiHdEacemWhgLZP5KBFjn6Lya5iFUYbnfmtGD hr6l5f0J0hjNCFqvCjryr8GjHGD+yJIKeQ3XRQgfx/UlfGmcaXMAlnT/P6GxtkAJcPX3 uyFw== X-Gm-Message-State: AJIora8JTk1Nwt4GTGVrgRgQKH4Qn/qLaLDmklYL7MG61j2iZCv4U7er iVoOQrzzLhc8+ddq/GLl5zZnT45ocQY2dpkq9j+p+A== X-Google-Smtp-Source: AGRyM1ve5bKkRgY91JODr6G0KYNj14IUXmUe2XTmEOY9UMxbgvLVrQb6DVioXtQ4vfZSOB7V9pobKh55jgw4lPONCfA= X-Received: by 2002:a05:6512:32c5:b0:481:1822:c41f with SMTP id f5-20020a05651232c500b004811822c41fmr16158485lfg.373.1657641857910; Tue, 12 Jul 2022 09:04:17 -0700 (PDT) Precedence: bulk X-Mailing-List: linux-coco@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <6a513cf79bf71c479dbd72165faf1d804d77b3af.1655761627.git.ashish.kalra@amd.com> In-Reply-To: From: Peter Gonda Date: Tue, 12 Jul 2022 10:04:05 -0600 Message-ID: Subject: Re: [PATCH Part2 v6 28/49] KVM: SVM: Add KVM_SEV_SNP_LAUNCH_FINISH command To: "Kalra, Ashish" Cc: "the arch/x86 maintainers" , LKML , kvm list , "linux-coco@lists.linux.dev" , Linux Memory Management List , Linux Crypto Mailing List , Thomas Gleixner , Ingo Molnar , Joerg Roedel , "Lendacky, Thomas" , "H. Peter Anvin" , Ard Biesheuvel , Paolo Bonzini , Sean Christopherson , Vitaly Kuznetsov , Jim Mattson , Andy Lutomirski , Dave Hansen , Sergio Lopez , Peter Zijlstra , Srinivas Pandruvada , David Rientjes , Dov Murik , Tobin Feldman-Fitzthum , Borislav Petkov , "Roth, Michael" , Vlastimil Babka , "Kirill A . Shutemov" , Andi Kleen , Tony Luck , Marc Orr , Sathyanarayanan Kuppuswamy , Alper Gun , "Dr. David Alan Gilbert" , "jarkko@kernel.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jul 12, 2022 at 9:22 AM Kalra, Ashish wrote: > > [AMD Official Use Only - General] > > Hello Peter, > > >> >Given the guest uses the SNP NAE AP boot protocol we were expecting t= hat there would be some option to add vCPUs to the VM but mark them as "pen= ding AP boot creation protocol" state. This would allow the LaunchDigest of= a VM doesn't change >just because its vCPU count changes. Would it be poss= ible to add a new add an argument to KVM_SNP_LAUNCH_FINISH to tell it which= vCPUs to LAUNCH_UPDATE VMSA pages for or similarly a new argument for KVM_= CREATE_VCPU? > >> > >> But don't we want/need to measure all vCPUs using LAUNCH_UPDATE_VMSA b= efore we issue SNP_LAUNCH_FINISH command ? > >> > >> If we are going to add vCPUs and mark them as "pending AP boot creatio= n" state then how are we going to do LAUNCH_UPDATE_VMSAs for them after SNP= _LAUNCH_FINISH ? > > >If I understand correctly we don't need or even want the APs to be LAUNC= H_UPDATE_VMSA'd. LAUNCH_UPDATEing all the VMSAs causes VMs with different n= umbers of vCPUs to have different launch digests. Its my understanding the = SNP AP >Creation protocol was to solve this so that VMs with different vcpu= counts have the same launch digest. > > >Looking at patch "[Part2,v6,44/49] KVM: SVM: Support SEV-SNP AP Creation= NAE event" and section "4.1.9 SNP AP Creation" of the GHCB spec. There is = no need to mark the LAUNCH_UPDATE the AP's VMSA or mark the vCPUs runnable.= Instead we >can do that only for the BSP. Then in the guest UEFI the BSP c= an: create new VMSAs from guest pages, RMPADJUST them into the RMP state VM= SA, then use the SNP AP Creation NAE to get the hypervisor to mark them run= nable. I believe this is all >setup in the UEFI patch: > >https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.= mail-archive.com%2Fdevel%40edk2.groups.io%2Fmsg38460.html&data=3D05%7C0= 1%7CAshish.Kalra%40amd.com%7Ca40178ac6f284a9e33aa08da64152baa%>7C3dd8961fe4= 884e608e11a82d994e183d%7C0%7C0%7C637932339382401133%7CUnknown%7CTWFpbGZsb3d= 8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%= 7C%7C%7C&sdata=3DZaiHHo9S24f9BB6E%>2FjexOt5TdKJQXxQDJI5QoYdDDHc%3D&= reserved=3D0. > > Yes, I discussed the same with Tom, and this will be supported going forw= ard, only the BSP will need to go through the LAUNCH_UPDATE_VMSA and at run= time the guest can dynamically create more APs using the SNP AP Creation NA= E event. > > Now, coming back to the original question, why do we need a separate vCPU= count argument for SNP_LAUNCH_FINISH, won't the statically created vCPUs i= n kvm->created_vcpus/online_vcpus be sufficient for that, any dynamically c= reated > vCPU's won't be part of the initial measurement or LaunchDigest of the VM= , right ? Are you suggesting that QEMU will KVM_CREATE_VCPU the BSP, then LAUNCH_FINISH, then KVM_CREATE_VCPU all the APs to their VMSAs were not LAUNCH_UPDATED? If so, it seems annoying to have to create vCPUs at different times to get their VMSAs into different states. That's why I was suggesting some other mechanism so we can continue to KVM_CREATE_VCPU all the vCPUs at the same time. > > Thanks, > Ashish