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 65F8BC433EF for ; Tue, 14 Jun 2022 15:37:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BBF0B6B00A1; Tue, 14 Jun 2022 11:37:53 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B6E5B6B00A2; Tue, 14 Jun 2022 11:37:53 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9E8436B00A3; Tue, 14 Jun 2022 11:37:53 -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 8F8626B00A1 for ; Tue, 14 Jun 2022 11:37:53 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 5CB5960FFE for ; Tue, 14 Jun 2022 15:37:53 +0000 (UTC) X-FDA: 79577246826.07.37F2BAD Received: from mail-lj1-f170.google.com (mail-lj1-f170.google.com [209.85.208.170]) by imf08.hostedemail.com (Postfix) with ESMTP id 0506D16009E for ; Tue, 14 Jun 2022 15:37:52 +0000 (UTC) Received: by mail-lj1-f170.google.com with SMTP id j20so10181726ljg.8 for ; Tue, 14 Jun 2022 08:37:52 -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; bh=fn8gtxL6sSNRSsiDRRI9nlOANxjqFwtwIBrOJj9PDX4=; b=LT/lyo0Gkm8vUesqRnJoPnu//GtJ2a4J7xk0YQo1fVzKIPstZDTs4ocVHUhOQzAzDf 1mhknKFZFcyuP+FcITbRZ9C3Zb5IygQ+dSD/d5sDSo5jPxZ3Xod61S+96JIZEmvp/ioU ZLBYWsR7cCtO3xXbwzi+P+VOMS8qTkNT6dLd5qwOG4wKAOBEMDsF5IyyBzSoJSpbj7Ps 0sLvaRhd6KXmBxBx5Mnte8TQS/1qrwy08MCnMdz9Rwv7O5iKxxqDYqsRoQXOdKe/qqv/ D1JOHgxvD7xtNV5gXfizVs33keuKhzIJmtdRXlLVfle9UauwzrlzB+MCJvLuXXUxDdkT 328Q== 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; bh=fn8gtxL6sSNRSsiDRRI9nlOANxjqFwtwIBrOJj9PDX4=; b=QKs1kFunjVOkhWvLpl9ihnFTd3/G7eJcXSwliIFLJpwkQ1gEmTKXShVr5Viek/tYdS dJ7xyxlkTaSf3JClCvguhzmnCWps+GTvsAsZSMdNcv93Vhdzi7wwPhkBMjI0jBgiwQr9 O3mlDU4bIrX+ydDHhS8wGwRwO0J29iA7Zkk9WLkjnlHn7Q81balcsPFUTeMJUKjvu4dW a1PPjZ1tgq0PJze6fbomtcLq7YbyAh1SKa9RUkUBkEgv8TxNeQ9kp98c5yEEfVEoKG7z hDfhmOzUqQwty/f++CFhV4LqeN6VgoLygqEKYsOOBKBsdlBLBodN0HX++ji9miVWp2+Y kLbA== X-Gm-Message-State: AJIora9llIEjy6LSMGvKUKInyoXnWGd/Wug3RrcbafLZP0uhxURAA+zu sYQZAGiyQmliejiIcDzXGLpmu11QkIAcWWA7MQxQYA== X-Google-Smtp-Source: AGRyM1tVivOgpTFI/b0e/Dm7QRVBpJJPup//gAccjasK6nMQcbpqWB6Xf55xhXL4gRzWthbIWts51F5C1RaIfIMXqkE= X-Received: by 2002:a2e:547:0:b0:255:703a:d9ae with SMTP id 68-20020a2e0547000000b00255703ad9aemr2756675ljf.282.1655221071098; Tue, 14 Jun 2022 08:37:51 -0700 (PDT) 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: Peter Gonda Date: Tue, 14 Jun 2022 09:37:39 -0600 Message-ID: Subject: Re: [PATCH Part2 v5 23/45] KVM: SVM: Add KVM_SNP_INIT command To: Ashish Kalra Cc: Alper Gun , Brijesh Singh , Ashish Kalra , "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 , Tom Lendacky , "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 , Michael Roth , Vlastimil Babka , "Kirill A . Shutemov" , Andi Kleen , Tony Luck , Marc Orr , Sathyanarayanan Kuppuswamy , Pavan Kumar Paluri Content-Type: text/plain; charset="UTF-8" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1655221073; a=rsa-sha256; cv=none; b=FDzpyYxONw6TCQpNl6GnsThLKebQRZ5KHE2NhCHuUHswh6sXXT2e1zXMFWnqylQ3xFIA/Y ExHhYHMuMU4hXm4wnvzrDRKPlKESMaUQ/YPGioKJg2Xb+YYzTO6oW30JsJbSXfrYBVism9 wh5fsSfsJUXnCFqsyqXvOsBWMrwM3+8= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b="LT/lyo0G"; spf=pass (imf08.hostedemail.com: domain of pgonda@google.com designates 209.85.208.170 as permitted sender) smtp.mailfrom=pgonda@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1655221073; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=fn8gtxL6sSNRSsiDRRI9nlOANxjqFwtwIBrOJj9PDX4=; b=Mno03SNrKCCqBNnAINmY2JYOL67FaUerSTE9yOv2Po2rwPxIHsOArRuAGug9xK/QCJJTOl HaO5RIP2UeMU1+0R5HyhqSVQAqjvnfmxajD+cztBrOhXWT0jQaXw2u83RaB+4kWq/ScQaL mi0LQztD6DzQUmC4gy11No0SfJahO90= X-Stat-Signature: 9hraddupy3d7h975dsuxhiejbkw6prqu X-Rspamd-Queue-Id: 0506D16009E Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b="LT/lyo0G"; spf=pass (imf08.hostedemail.com: domain of pgonda@google.com designates 209.85.208.170 as permitted sender) smtp.mailfrom=pgonda@google.com; dmarc=pass (policy=reject) header.from=google.com X-Rspam-User: X-Rspamd-Server: rspam02 X-HE-Tag: 1655221072-792338 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 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 wrote: > >> 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 = (argp->id == KVM_SEV_ES_INIT || argp->id == KVM_SEV_SNP_INIT); > >>>> struct kvm_sev_info *sev = &to_kvm_svm(kvm)->sev_info; > >>>> - bool es_active = argp->id == KVM_SEV_ES_INIT; > >>>> + bool snp_active = argp->id == 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 = es_active; > >>>> + sev->snp_active = snp_active; > >>>> asid = sev_asid_new(sev); > >>>> if (asid < 0) > >>>> goto e_no_asid; > >>>> sev->asid = asid; > >>>> > >>>> - ret = sev_platform_init(&argp->error); > >>>> + if (snp_active) { > >>>> + ret = verify_snp_init_flags(kvm, argp); > >>>> + if (ret) > >>>> + goto e_free; > >>>> + > >>>> + ret = sev_snp_init(&argp->error); > >>>> + } else { > >>>> + ret = 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 tests. > >> 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 BSP ? > >> > > 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(). > > Thanks, Ashish >