From: Tom Lendacky <thomas.lendacky@amd.com>
To: "Kalra, Ashish" <ashish.kalra@amd.com>,
seanjc@google.com, pbonzini@redhat.com, tglx@linutronix.de,
mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com,
x86@kernel.org, hpa@zytor.com, john.allen@amd.com,
herbert@gondor.apana.org.au
Cc: michael.roth@amd.com, dionnaglaze@google.com, nikunj@amd.com,
ardb@kernel.org, kevinloughlin@google.com,
Neeraj.Upadhyay@amd.com, aik@amd.com, kvm@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org,
linux-coco@lists.linux.dev
Subject: Re: [PATCH v4 7/7] crypto: ccp: Move SEV/SNP Platform initialization to KVM
Date: Thu, 20 Feb 2025 15:05:53 -0600 [thread overview]
Message-ID: <491714b8-6cb7-ac0f-862c-7fdec3be5175@amd.com> (raw)
In-Reply-To: <cc89eda4-d1f8-48e1-9bfd-d550846e2d84@amd.com>
On 2/20/25 14:23, Kalra, Ashish wrote:
> Hello Tom,
>
> On 2/20/2025 2:03 PM, Tom Lendacky wrote:
>> On 2/19/25 14:55, Ashish Kalra wrote:
>>> From: Ashish Kalra <ashish.kalra@amd.com>
>>>
>>> SNP initialization is forced during PSP driver probe purely because SNP
>>> can't be initialized if VMs are running. But the only in-tree user of
>>> SEV/SNP functionality is KVM, and KVM depends on PSP driver for the same.
>>> Forcing SEV/SNP initialization because a hypervisor could be running
>>> legacy non-confidential VMs make no sense.
>>>
>>> This patch removes SEV/SNP initialization from the PSP driver probe
>>> time and moves the requirement to initialize SEV/SNP functionality
>>> to KVM if it wants to use SEV/SNP.
>>>
>>> Suggested-by: Sean Christopherson <seanjc@google.com>
>>> Reviewed-by: Alexey Kardashevskiy <aik@amd.com>
>>> Signed-off-by: Ashish Kalra <ashish.kalra@amd.com>
>>> ---
>>> drivers/crypto/ccp/sev-dev.c | 25 +------------------------
>>> 1 file changed, 1 insertion(+), 24 deletions(-)
>>>
>>> diff --git a/drivers/crypto/ccp/sev-dev.c b/drivers/crypto/ccp/sev-dev.c
>>> index f0f3e6d29200..99a663dbc2b6 100644
>>> --- a/drivers/crypto/ccp/sev-dev.c
>>> +++ b/drivers/crypto/ccp/sev-dev.c
>>> @@ -1346,18 +1346,13 @@ static int _sev_platform_init_locked(struct sev_platform_init_args *args)
>>> if (sev->state == SEV_STATE_INIT)
>>> return 0;
>>>
>>> - /*
>>> - * Legacy guests cannot be running while SNP_INIT(_EX) is executing,
>>> - * so perform SEV-SNP initialization at probe time.
>>> - */
>>> rc = __sev_snp_init_locked(&args->error);
>>> if (rc && rc != -ENODEV) {
>>> /*
>>> * Don't abort the probe if SNP INIT failed,
>>> * continue to initialize the legacy SEV firmware.
>>> */
>>> - dev_err(sev->dev, "SEV-SNP: failed to INIT rc %d, error %#x\n",
>>> - rc, args->error);
>>> + dev_err(sev->dev, "SEV-SNP: failed to INIT, continue SEV INIT\n");
>>
>> Please don't remove the error information.
>>
>
> The error(s) are already being printed in __sev_snp_init_locked() otherwise the same
> error will be printed twice, hence removing it here.
Sounds like this change should be in patch #1 then.
Thanks,
Tom
>
>>> }
>>>
>>> /* Defer legacy SEV/SEV-ES support if allowed by caller/module. */
>>> @@ -2505,9 +2500,7 @@ EXPORT_SYMBOL_GPL(sev_issue_cmd_external_user);
>>> void sev_pci_init(void)
>>> {
>>> struct sev_device *sev = psp_master->sev_data;
>>> - struct sev_platform_init_args args = {0};
>>> u8 api_major, api_minor, build;
>>> - int rc;
>>>
>>> if (!sev)
>>> return;
>>> @@ -2530,16 +2523,6 @@ void sev_pci_init(void)
>>> api_major, api_minor, build,
>>> sev->api_major, sev->api_minor, sev->build);
>>>
>>> - /* Initialize the platform */
>>> - args.probe = true;
>>> - rc = sev_platform_init(&args);
>>> - if (rc)
>>> - dev_err(sev->dev, "SEV: failed to INIT error %#x, rc %d\n",
>>> - args.error, rc);
>>> -
>>> - dev_info(sev->dev, "SEV%s API:%d.%d build:%d\n", sev->snp_initialized ?
>>> - "-SNP" : "", sev->api_major, sev->api_minor, sev->build);
>>> -
>>> return;
>>>
>>> err:
>>> @@ -2550,10 +2533,4 @@ void sev_pci_init(void)
>>>
>>> void sev_pci_exit(void)
>>> {
>>> - struct sev_device *sev = psp_master->sev_data;
>>> -
>>> - if (!sev)
>>> - return;
>>> -
>>> - sev_firmware_shutdown(sev);
>>
>> Should this remain? If there's a bug in KVM that somehow skips the
>> shutdown call, then SEV will remain initialized. I think the path is
>> safe to call a second time.
>
> Ok.
>
> Thanks,
> Ashish
>
prev parent reply other threads:[~2025-02-20 21:06 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-19 20:52 [PATCH v4 0/7] Move initializing SEV/SNP functionality " Ashish Kalra
2025-02-19 20:52 ` [PATCH v4 1/7] crypto: ccp: Move dev_info/err messages for SEV/SNP init and shutdown Ashish Kalra
2025-02-20 18:27 ` Tom Lendacky
2025-02-19 20:53 ` [PATCH v4 2/7] crypto: ccp: Ensure implicit SEV/SNP init and shutdown in ioctls Ashish Kalra
2025-02-20 16:44 ` Dionna Amalie Glaze
2025-02-20 20:07 ` Kalra, Ashish
2025-02-20 21:37 ` Dionna Amalie Glaze
2025-02-20 22:18 ` Kalra, Ashish
2025-02-20 22:39 ` Dionna Amalie Glaze
2025-02-19 20:53 ` [PATCH v4 3/7] crypto: ccp: Reset TMR size at SNP Shutdown Ashish Kalra
2025-02-20 16:47 ` Dionna Amalie Glaze
2025-02-20 18:55 ` Tom Lendacky
2025-02-19 20:53 ` [PATCH v4 4/7] crypto: ccp: Register SNP panic notifier only if SNP is enabled Ashish Kalra
2025-02-20 19:08 ` Tom Lendacky
2025-02-19 20:54 ` [PATCH v4 5/7] crypto: ccp: Add new SEV/SNP platform shutdown API Ashish Kalra
2025-02-20 19:21 ` Tom Lendacky
2025-02-19 20:54 ` [PATCH v4 6/7] KVM: SVM: Add support to initialize SEV/SNP functionality in KVM Ashish Kalra
2025-02-20 19:57 ` Tom Lendacky
2025-02-19 20:55 ` [PATCH v4 7/7] crypto: ccp: Move SEV/SNP Platform initialization to KVM Ashish Kalra
2025-02-20 20:03 ` Tom Lendacky
2025-02-20 20:23 ` Kalra, Ashish
2025-02-20 21:05 ` Tom Lendacky [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=491714b8-6cb7-ac0f-862c-7fdec3be5175@amd.com \
--to=thomas.lendacky@amd.com \
--cc=Neeraj.Upadhyay@amd.com \
--cc=aik@amd.com \
--cc=ardb@kernel.org \
--cc=ashish.kalra@amd.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=dionnaglaze@google.com \
--cc=herbert@gondor.apana.org.au \
--cc=hpa@zytor.com \
--cc=john.allen@amd.com \
--cc=kevinloughlin@google.com \
--cc=kvm@vger.kernel.org \
--cc=linux-coco@lists.linux.dev \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=michael.roth@amd.com \
--cc=mingo@redhat.com \
--cc=nikunj@amd.com \
--cc=pbonzini@redhat.com \
--cc=seanjc@google.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®