From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-io1-f45.google.com (mail-io1-f45.google.com [209.85.166.45]) (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 9941D1FC1 for ; Tue, 14 Jun 2022 18:58:31 +0000 (UTC) Received: by mail-io1-f45.google.com with SMTP id e80so10383464iof.3 for ; Tue, 14 Jun 2022 11:58:31 -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=UcrIrSk5Swd+nvSBeuVYmeu1PhD4aHQkIlKjjep/U/8=; b=gXwMwJILGwkplNokon5zOdE2RQ1Qwvww6dSg4uCJAviXw5icGHnP09W33KGxS29FEj lQmoqXPAK+SY+SmDsCO/uWap3n/Movp3Wt4rOczfaAgqPoAhpMfjyUVxCTjKBao8mOHb xNde4umF8iDkfU55A43FTeYvB/iSrFz+vmF/5fknkICPrZ4tHShvwl3ctm6Jte1duC9w vGIuBcYhURzJCMJ0clNbF4yJswoL63YXLGidU23WgOeR+iaDgxtj7l+QnDEogu1l+H7l NemjvgzAPpKbQcnFV8aV5xNVWnYnLA+pLXhiZY49PjBL982JWxAL2SISJKdAwponp74I homg== 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=UcrIrSk5Swd+nvSBeuVYmeu1PhD4aHQkIlKjjep/U/8=; b=GCuVAxfmJc8IrLbW62qmE78E0r/4gJckaVv6V/2WAYwmPwWldKH4qGpKzXwKeiZA84 pm/jjbsXWdk9KeZfaO1M5wfe0dwHy3vnQexgVNFAcGyEogu/1v7CFhv7AzV5vccbIQWz qomnxjTKZE7N+ZVg4JpqOOr1iLvYsI602oBDxmhdXdv6w6Jymn9PYbZLeJLWTMwcG85S mQOG7NtzUOupyWGMbIjhqDkVRUhkDKcDKyO3loX0ZgKGVpiY9w1p8dMKRTURD3dAK5Pa nkWbpOJom4/rzjCvi8gbn2jf4MaUzqu+Z/wyovvYi8zIZSviN5iE8ap3NWoZleuqq1f+ iVHg== X-Gm-Message-State: AOAM531YMkCD414C0vpZGMv2a81ScJge2SuBRILSBAO9XAtA+dkYzza0 gr+V5x7cpyTQPl88LyEDNVk0mCfRkaBuSQ+XdgwK3A== X-Google-Smtp-Source: ABdhPJxkbeBOlNzS42LkPVnH7oYNg5c6GJRwXSXygjn2ujomA+SXpQWuvJtL4QMILjs/tOS/P8Vv380wMtHehK1DSBU= X-Received: by 2002:a05:6638:13d5:b0:331:a6f2:3dbf with SMTP id i21-20020a05663813d500b00331a6f23dbfmr3907072jaj.9.1655233110381; Tue, 14 Jun 2022 11:58:30 -0700 (PDT) Precedence: bulk X-Mailing-List: linux-coco@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20210820155918.7518-1-brijesh.singh@amd.com> <20210820155918.7518-24-brijesh.singh@amd.com> <1cadca0d-c3dc-68ed-075f-f88ccb0ccc0a@amd.com> In-Reply-To: From: Alper Gun Date: Tue, 14 Jun 2022 11:58:19 -0700 Message-ID: Subject: Re: [PATCH Part2 v5 23/45] KVM: SVM: Add KVM_SNP_INIT command To: "Kalra, Ashish" Cc: Peter Gonda , "the arch/x86 maintainers" , LKML , kvm list , "linux-coco@lists.linux.dev" , "linux-mm@kvack.org" , Linux Crypto Mailing List , Thomas Gleixner , Ingo Molnar , Joerg Roedel , "Lendacky, Thomas" , "H. Peter Anvin" , Ard Biesheuvel , Paolo Bonzini , Sean Christopherson , Vitaly Kuznetsov , Wanpeng Li , 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Let me summarize what I tried. 1- when using psp_init_probe false, the SNP VM fails in SNP_LAUNCH_START step with error SEV_RET_DFFLUSH_REQUIRED(15). 2- added SEV_DF_FLUSH just after SNP platform init and it didn't fail in launch start but failed later during SNP_LAUNCH_UPDATE with SEV_RET_INVALID_PARAM(22) 3- added SNP_DF_FLUSH just after SNP platform init and it failed again during SNP_LAUNCH_UPDATE with SEV_RET_INVALID_PARAM(22) 4- added sev_platform_init for SNP VMs and it worked. For me DF_FLUSH alone didn' help boot a VM. I don't know yet why sev platform status impacts the SNP VM, but sev_platform_init fixes the problem. On Tue, Jun 14, 2022 at 10:16 AM Kalra, Ashish wrote= : > > [AMD Official Use Only - General] > > Hello Alper, Peter, > > -----Original Message----- > From: Peter Gonda > Sent: Tuesday, June 14, 2022 11:30 AM > To: Kalra, Ashish > Cc: Alper Gun ; Brijesh Singh ; the arch/x86 maintainers ; LKML ; kvm list ; linux-coco@lists.linux.dev; linux-m= m@kvack.org; Linux Crypto Mailing List ; Thom= as Gleixner ; Ingo Molnar ; Joerg Roe= del ; Lendacky, Thomas ; H. Peter= Anvin ; Ard Biesheuvel ; Paolo Bonzini ; Sean Christopherson ; Vitaly Kuznets= ov ; Wanpeng Li ; Jim Mattson <= jmattson@google.com>; Andy Lutomirski ; Dave Hansen ; Sergio Lopez ; Peter Zijlstra ; Srinivas Pandruvada ; David Rientjes ; Dov Murik ; Tobin Feldman-Fitzthum ; Borislav Petkov ; = Roth, Michael ; Vlastimil Babka ; Kir= ill A . Shutemov ; Andi Kleen ; T= ony Luck ; Marc Orr ; Sathyanaraya= nan Kuppuswamy ; Pavan Kumar Pa= luri > Subject: Re: [PATCH Part2 v5 23/45] KVM: SVM: Add KVM_SNP_INIT command > > On Tue, Jun 14, 2022 at 10:11 AM Kalra, Ashish wro= te: > > > > [AMD Official Use Only - General] > > > > > > -----Original Message----- > > From: Peter Gonda > > Sent: Tuesday, June 14, 2022 10:38 AM > > To: Kalra, Ashish > > Cc: Alper Gun ; Brijesh Singh > > ; Kalra, Ashish ; the > > arch/x86 maintainers ; LKML > > ; kvm list ; > > linux-coco@lists.linux.dev; linux-mm@kvack.org; Linux Crypto Mailing > > List ; Thomas Gleixner > > ; Ingo Molnar ; Joerg Roedel > > ; Lendacky, Thomas ; H. > > Peter Anvin ; Ard Biesheuvel ; Paolo > > Bonzini ; Sean Christopherson > > ; Vitaly Kuznetsov ; Wanpeng > > Li ; 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 > > ; Pavan Kumar Paluri > > > > Subject: Re: [PATCH Part2 v5 23/45] KVM: SVM: Add KVM_SNP_INIT command > > > > On Mon, Jun 13, 2022 at 6:21 PM Ashish Kalra wrote: > > > > > > > > > On 6/13/22 23:33, Alper Gun wrote: > > > > On Mon, Jun 13, 2022 at 4:15 PM Ashish Kalra wro= te: > > > >> Hello Alper, > > > >> > > > >> On 6/13/22 20:58, Alper Gun wrote: > > > >>> static int sev_guest_init(struct kvm *kvm, struct kvm_sev_cmd > > > >>> *argp) > > > >>>> { > > > >>>> + bool es_active =3D (argp->id =3D=3D KVM_SEV_ES_INIT || > > > >>>> + argp->id =3D=3D KVM_SEV_SNP_INIT); > > > >>>> struct kvm_sev_info *sev =3D &to_kvm_svm(kvm)->sev_inf= o; > > > >>>> - bool es_active =3D argp->id =3D=3D KVM_SEV_ES_INIT; > > > >>>> + bool snp_active =3D argp->id =3D=3D KVM_SEV_SNP_INIT; > > > >>>> int asid, ret; > > > >>>> > > > >>>> if (kvm->created_vcpus) @@ -249,12 +269,22 @@ static > > > >>>> int sev_guest_init(struct kvm *kvm, struct kvm_sev_cmd *argp) > > > >>>> return ret; > > > >>>> > > > >>>> sev->es_active =3D es_active; > > > >>>> + sev->snp_active =3D snp_active; > > > >>>> asid =3D sev_asid_new(sev); > > > >>>> if (asid < 0) > > > >>>> goto e_no_asid; > > > >>>> sev->asid =3D asid; > > > >>>> > > > >>>> - ret =3D sev_platform_init(&argp->error); > > > >>>> + if (snp_active) { > > > >>>> + ret =3D verify_snp_init_flags(kvm, argp); > > > >>>> + if (ret) > > > >>>> + goto e_free; > > > >>>> + > > > >>>> + ret =3D sev_snp_init(&argp->error); > > > >>>> + } else { > > > >>>> + ret =3D sev_platform_init(&argp->error); > > > >>> After SEV INIT_EX support patches, SEV may be initialized in the = platform late. > > > >>> In my tests, if SEV has not been initialized in the platform > > > >>> yet, SNP VMs fail with SEV_DF_FLUSH required error. I tried > > > >>> calling SEV_DF_FLUSH right after the SNP platform init but this > > > >>> time it failed later on the SNP launch update command with > > > >>> SEV_RET_INVALID_PARAM error. Looks like there is another > > > >>> dependency on SEV platform initialization. > > > >>> > > > >>> Calling sev_platform_init for SNP VMs fixes the problem in our te= sts. > > > >> Trying to get some more context for this issue. > > > >> > > > >> When you say after SEV_INIT_EX support patches, SEV may be > > > >> initialized in the platform late, do you mean sev_pci_init()->sev_= snp_init() ... > > > >> sev_platform_init() code path has still not executed on the host B= SP ? > > > >> > > > > Correct, INIT_EX requires the file system to be ready and there is > > > > a ccp module param to call it only when needed. > > > > > > > > MODULE_PARM_DESC(psp_init_on_probe, " if true, the PSP will be > > > > initialized on module init. Else the PSP will be initialized on > > > > the first command requiring it"); > > > > > > > > If this module param is false, it won't initialize SEV on the > > > > platform until the first SEV VM. > > > > > > > Ok, that makes sense. > > > > > > So the fix will be to call sev_platform_init() unconditionally here > > > in sev_guest_init(), and both sev_snp_init() and sev_platform_init() > > > are protected from being called again, so there won't be any issues > > > if these functions are invoked again at SNP/SEV VM launch if they > > > have been invoked earlier during module init. > > > > >That's one solution. I don't know if there is a downside to the system= for enabling SEV if SNP is being enabled but another solution could be to = just directly place a DF_FLUSH command instead of calling sev_platform_init= (). > > > > Actually sev_platform_init() is already called on module init if psp_in= it_on_probe is not false. Only need to ensure that SNP firmware is initiali= zed first with SNP_INIT command. > > > But if psp_init_on_probe is false, sev_platform_init() isn't called dow= n this path. Alper has suggested we always call sev_platform_init() but we = could just place an SEV_DF_FLUSH command instead. Or am I still missing som= ething? > > >After SEV INIT_EX support patches, SEV may be initialized in the platfor= m late. > > In my tests, if SEV has not been initialized in the platform > > yet, SNP VMs fail with SEV_DF_FLUSH required error. I tried > > calling SEV_DF_FLUSH right after the SNP platform init. > > Are you getting the DLFLUSH_REQUIRED error after the SNP activate command= ? > > Also did you use the SEV_DF_FLUSH command or the SNP_DF_FLUSH command ? > > With SNP you need to use SNP_DF_FLUSH command. > > Thanks, > Ashish