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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id BE676C433EF for ; Tue, 12 Jul 2022 16:04:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id ED7DB9400A1; Tue, 12 Jul 2022 12:04:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E5F2B940063; Tue, 12 Jul 2022 12:04:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CFF9D9400A1; Tue, 12 Jul 2022 12:04:20 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id BB9E4940063 for ; Tue, 12 Jul 2022 12:04:20 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 8A7E4322C4 for ; Tue, 12 Jul 2022 16:04:20 +0000 (UTC) X-FDA: 79678919880.13.B717736 Received: from mail-lf1-f46.google.com (mail-lf1-f46.google.com [209.85.167.46]) by imf06.hostedemail.com (Postfix) with ESMTP id 09732180030 for ; Tue, 12 Jul 2022 16:04:19 +0000 (UTC) Received: by mail-lf1-f46.google.com with SMTP id u13so14719214lfn.5 for ; Tue, 12 Jul 2022 09:04:19 -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=LSy/O7GWTHMN1eMP4QWtf9p6b0VNseTU36k/LilwXHtzY76y1PuNK+SMdvtZVIIOVQ yDJCglV1tfXt7JwWN+RLdHUQGEdAfcAE3iIIgEISTYN6sd+DGHrZDDLdxUubl/1cO0nx tVDIV5YyoZUZ3rwBT8PP2Zb3dCfojngqI5Gai4ItF8E/UNaeWo+fELgurZibMwq+Iwhk vznadTTavEuso8sVyo1ZZb7DIFhK4aHpUaQmBVwEz4g+ejvueu38ku9JLsWuFqK/l6fW XbL1htBKjIv9c0YNnyF05KH8VMAQu9Okf/6gL5jXjqxbF7sEITTPRFcF2QxNGsMemf+i 4qVw== X-Gm-Message-State: AJIora/u7SiXcdns7BQfsnqrB7cLqNEd0/M8N1QHfNJYkpgF/6VHtG9v CikbZ1OLEWVKbhAx3DhhS8CEhva0ZBLPdnJZsDL88g== 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) 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 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1657641860; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=c0RcQSLjeYCnLvxH8el7ACbuvLKqs4ymAPhMSssf3fo=; b=TJ7sAQPN1FFHeWWQq0nTGAeUavt6B5nrS3mrb3x7CtuFZefAaLv0UDf6cfJWVXVD1Uv0Qp LXOXJd2X2W7iOetQImhwUkCPzpdu+q4f8CpPEfpwN75LPF3Js3RSRy3LOBBFKGkKWJYWbh NPxMQhH+TDKsnWyeiXtMUlGaWIcU0DI= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=rgy8GpGj; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf06.hostedemail.com: domain of pgonda@google.com designates 209.85.167.46 as permitted sender) smtp.mailfrom=pgonda@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1657641860; a=rsa-sha256; cv=none; b=yR6k/Ykq2aNOjvNcTBsF8XGghAwY7dZN/GyhyjjOLC/eOTkWXcsblyJal02jcA9iCoZn3j Ts4xFWEOiCzFabOqPf1UAT0S5Em8359A8vFk/QO/GU9RcDgjqHPjinsJxLBq4kjrG+Cxzs fT7Nnv2XvMzxmO+EtNrXdih81khPkL0= X-Stat-Signature: 5pnemm9817wnqnbeuswwoep6m5acsph6 X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 09732180030 Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=rgy8GpGj; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf06.hostedemail.com: domain of pgonda@google.com designates 209.85.167.46 as permitted sender) smtp.mailfrom=pgonda@google.com X-Rspam-User: X-HE-Tag: 1657641859-996549 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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