From: "Pratik R. Sampat" <prsampat@amd.com>
To: Tom Lendacky <thomas.lendacky@amd.com>,
mcgrof@kernel.org, russ.weight@linux.dev, dakr@kernel.org,
ashish.kalra@amd.com, herbert@gondor.apana.org.au,
davem@davemloft.net
Cc: linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org,
gregkh@linuxfoundation.org, rafael@kernel.org,
chao.gao@intel.com, aik@amd.com, tycho@kernel.org,
nikunj@amd.com, michael.roth@amd.com, shansinha@google.com
Subject: Re: [PATCH 5/7] crypto: ccp - Allow SNP platform data to be queried after SNP INIT
Date: Thu, 10 Sep 2026 17:05:45 -0400 [thread overview]
Message-ID: <ca2dcdd2-1c4c-498d-beb5-13efefcb67f2@amd.com> (raw)
In-Reply-To: <e3040c1e-1928-4552-a775-aa9d9925fa9e@amd.com>
Hi Tom,
Thanks for the review.
On 9/10/26 4:09 PM, Tom Lendacky wrote:
> On 9/10/26 12:02, Pratik R. Sampat wrote:
>> In preparation for refreshing the cached SNP platform status and feature
>> information after a successful firmware live update from
>> DOWNLOAD_FIRMWARE_EX, allow snp_get_platform_data() to be called while
>> the SNP firmware is in the INIT state.
>>
>> Once SNP is initialized the firmware requires the output page of both
>> commands to be firmware-owned. sev->snp_plat_status cannot satisfy that
>> as it is embedded in struct sev_device, so use
>> __sev_do_snp_platform_status(), which stages the output through a
>> dedicated page, and mark/reclaim the SNP_FEATURE_INFO page around the
>> command.
>>
>> Co-developed-by: Tycho Andersen (AMD) <tycho@kernel.org>
>> Signed-off-by: Tycho Andersen (AMD) <tycho@kernel.org>
>> Signed-off-by: Pratik R. Sampat <prsampat@amd.com>
>> ---
>> drivers/crypto/ccp/sev-dev.c | 44 ++++++++++++++++++++++++++++--------
>> 1 file changed, 34 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/crypto/ccp/sev-dev.c b/drivers/crypto/ccp/sev-dev.c
>> index 1ed9e61a95cc..e891d6d1c6f0 100644
>> --- a/drivers/crypto/ccp/sev-dev.c
>> +++ b/drivers/crypto/ccp/sev-dev.c
>> @@ -131,6 +131,8 @@ static void __sev_firmware_shutdown(struct sev_device *sev, bool panic);
>>
>> static int snp_shutdown_on_panic(struct notifier_block *nb,
>> unsigned long reason, void *arg);
>> +static int __sev_do_snp_platform_status(struct sev_user_data_snp_status *status,
>> + int *error);
>>
>> static struct notifier_block snp_panic_notifier = {
>> .notifier_call = snp_shutdown_on_panic,
>> @@ -1261,19 +1263,12 @@ static int snp_get_platform_data(struct sev_device *sev, int *error)
>> {
>> struct sev_data_snp_feature_info snp_feat_info;
>> struct snp_feature_info *feat_info;
>> - struct sev_data_snp_addr buf;
>> struct page *page;
>> int rc;
>>
>> - /*
>> - * This function is expected to be called before SNP is
>> - * initialized.
>> - */
>> - if (sev->snp_initialized)
>> - return -EINVAL;
>> -
>> - buf.address = __psp_pa(&sev->snp_plat_status);
>> - rc = sev_do_cmd(SEV_CMD_SNP_PLATFORM_STATUS, &buf, error);
>> + mutex_lock(&sev_cmd_mutex);
>> + rc = __sev_do_snp_platform_status(&sev->snp_plat_status, error);
>> + mutex_unlock(&sev_cmd_mutex);
>> if (rc) {
>> dev_err(sev->dev, "SNP PLATFORM_STATUS command failed, ret = %d, error = %#x\n",
>> rc, *error);
>> @@ -1302,17 +1297,46 @@ static int snp_get_platform_data(struct sev_device *sev, int *error)
>> return -ENOMEM;
>>
>> feat_info = page_address(page);
>> +
>> + /* If SNP is initialized, transition to use a firmware-owned page */
>> + if (sev->snp_initialized) {
>> + if (rmp_mark_pages_firmware(__pa(feat_info), 1, false)) {
>> + *error = SEV_RET_NO_FW_CALL;
>> + rc = -EFAULT;
>> + goto free_page;
>> + }
>> + }
>> +
>
> You could change to use snp_alloc_firmware_page() which will allocate
> the page and place it in the proper state for you.
>
>> snp_feat_info.length = sizeof(snp_feat_info);
>> snp_feat_info.ecx_in = 0;
>> snp_feat_info.feature_info_paddr = __psp_pa(feat_info);
>>
>> rc = sev_do_cmd(SEV_CMD_SNP_FEATURE_INFO, &snp_feat_info, error);
>> +
>> + /*
>> + * The feature_info page will be in reclaim state on success, or left
>> + * in firmware state on failure. Transition the pages back to
>> + * Hypervisor-owned state.
>> + *
>> + * snp_reclaim_pages() has already pinned the page via snp_leak_pages()
>> + * if it could not do so, which keeps it away from the allocator. The
>> + * reference taken here is dropped either way.
>> + */
>> + if (sev->snp_initialized) {
>> + if (snp_reclaim_pages(__pa(feat_info), 1, false)) {
>> + *error = SEV_RET_NO_FW_CALL;
>> + rc = -EFAULT;
>> + goto free_page;
>> + }
>> + }
>
> And then snp_free_firmware_page() here (after you copy the data -
> similar to what you did in snp_verify_mitigation()).
>
Sure, I'll use snp_alloc_firmware_page + snp_free_firmware_page() and make
things cleaner.
> (I think the same changes apply to __sev_do_snp_platform_status(), but
> don't worry about it for this series)
>
Right. The only difference I believe would be to use
__snp_alloc_firmware_pages() and __snp_free_firmware_pages() with locked=true
since that is always called with the sev_cmd_mutex held.
I could send that as a separate clean up patch.
Thanks!
--Pratik
> Thanks,
> Tom
>
>> +
>> if (!rc)
>> sev->snp_feat_info_0 = *feat_info;
>> else
>> dev_err(sev->dev, "SNP FEATURE_INFO command failed, ret = %d, error = %#x\n",
>> rc, *error);
>>
>> +free_page:
>> __free_page(page);
>>
>> return rc;
>
next prev parent reply other threads:[~2026-09-10 21:05 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-10 17:01 [PATCH 0/7] Implement SNP live firmware update support Pratik R. Sampat
2026-09-10 17:01 ` [PATCH 1/7] firmware_loader: Stop pinning modules on registration Pratik R. Sampat
2026-09-10 17:01 ` [PATCH 2/7] firmware_loader: Stop pinning parent device per workqueue invocation Pratik R. Sampat
2026-09-10 17:01 ` [PATCH 3/7] treewide: firmware_loader: Drop the unused @module argument Pratik R. Sampat
2026-09-10 17:01 ` [PATCH 4/7] crypto: ccp - Factor out the release of the SEV firmware buffers Pratik R. Sampat
2026-09-10 17:02 ` [PATCH 5/7] crypto: ccp - Allow SNP platform data to be queried after SNP INIT Pratik R. Sampat
2026-09-10 20:09 ` Tom Lendacky
2026-09-10 21:05 ` Pratik R. Sampat [this message]
2026-09-10 17:02 ` [PATCH 6/7] crypto/ccp: Register with fw_uploader and always fail Pratik R. Sampat
2026-09-10 17:02 ` [PATCH 7/7] crypto/ccp: Implement SNP Download Firmware EX Pratik R. Sampat
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=ca2dcdd2-1c4c-498d-beb5-13efefcb67f2@amd.com \
--to=prsampat@amd.com \
--cc=aik@amd.com \
--cc=ashish.kalra@amd.com \
--cc=chao.gao@intel.com \
--cc=dakr@kernel.org \
--cc=davem@davemloft.net \
--cc=gregkh@linuxfoundation.org \
--cc=herbert@gondor.apana.org.au \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mcgrof@kernel.org \
--cc=michael.roth@amd.com \
--cc=nikunj@amd.com \
--cc=rafael@kernel.org \
--cc=russ.weight@linux.dev \
--cc=shansinha@google.com \
--cc=thomas.lendacky@amd.com \
--cc=tycho@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.