From: Tycho Andersen <tycho@kernel.org>
To: "Pratik R. Sampat" <prsampat@amd.com>
Cc: mcgrof@kernel.org, russ.weight@linux.dev, dakr@kernel.org,
ashish.kalra@amd.com, thomas.lendacky@amd.com,
herbert@gondor.apana.org.au, davem@davemloft.net,
linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org,
gregkh@linuxfoundation.org, rafael@kernel.org,
chao.gao@intel.com, aik@amd.com, nikunj@amd.com,
michael.roth@amd.com, shansinha@google.com
Subject: Re: [Patch v4 7/7] crypto/ccp: Implement SNP Download Firmware EX
Date: Thu, 15 Oct 2026 13:38:04 -0600 [thread overview]
Message-ID: <atElnAcDQFTnmdVr@tycho.pizza> (raw)
In-Reply-To: <55c189e9130a7d22c0b756440f10a056415404e5.1792014060.git.prsampat@amd.com>
Hi Pratik,
Two small comments if you happen to respin this one, no worries if
not.
On Thu, Oct 15, 2026 at 02:14:09AM +0000, Pratik R. Sampat wrote:
> +static int sev_download_firmware_ex(const u8 *data, u32 size, int *psp_ret)
> +{
> + struct sev_data_download_firmware_ex sev_data = {0};
> + int ret, order;
> + struct page *p;
> + void *fw_blob;
> +
> + order = get_order(size);
> + p = alloc_pages(GFP_KERNEL | __GFP_ZERO, order);
> + if (!p)
> + return -ENOMEM;
> +
> + fw_blob = page_address(p);
> + memcpy(fw_blob, data, size);
> +
> + sev_data.len = sizeof(sev_data);
> + sev_data.fw_paddr = __psp_pa(fw_blob);
> + sev_data.fw_len = size;
> + /*
> + * Don't commit the new firmware, an explicit SNP_COMMIT is required
> + * after update.
> + */
> + sev_data.commit = 0;
> +
> + ret = __sev_do_cmd_locked(SEV_CMD_SNP_DOWNLOAD_FIRMWARE_EX, &sev_data, psp_ret);
I guess this function could use a lockdep_assert_held(&sev_cmd_mutex),
but maybe we should not do that and instead put it in
__sev_do_cmd_locked()...
> +static enum fw_upload_err sev_fw_upload_update(struct sev_device *sev,
> + const u8 *data, u32 size,
> + u32 *written)
> +{
> + int cmd_ret, psp_ret = SEV_RET_NO_FW_CALL;
> + enum fw_upload_err fwl_ret;
> +
> + guard(mutex)(&sev_cmd_mutex);
> +
> + /*
> + * SEV firmware will only successfully execute the DLFW_EX command if a
> + * firmware rollback is required. Other commands may be processed, but
> + * may not execute properly. Use the psp_dead boolean to restrict
> + * execution to this path.
> + */
> + if (psp_dead && !sev->fwl_rollback_required) {
> + dev_err_ratelimited(sev->dev, "DLFW_EX: PSP is not responding\n");
> + return FW_UPLOAD_ERR_HW_ERROR;
> + }
> +
> + /*
> + * If the last firmware update returned RESTORE_REQUIRED, retry DLFW_EX.
> + * Being in this state means that the legacy firmware has previously
> + * been shut down, so no need to do it again.
> + */
> + if (sev->fwl_rollback_required) {
> + psp_dead = false;
> + } else {
> + cmd_ret = sev_fw_upload_shutdown_platform(sev);
> + if (cmd_ret)
> + return psp_dead ? FW_UPLOAD_ERR_HW_ERROR : FW_UPLOAD_ERR_BUSY;
> + }
> +
> + cmd_ret = sev_download_firmware_ex(data, size, &psp_ret);
> + fwl_ret = sev_fw_upload_handle_err(sev, cmd_ret, psp_ret);
> + if (fwl_ret == FW_UPLOAD_ERR_NONE) {
> + *written = size;
> + sev->fwl_rollback_required = false;
> + }
> +
> + /*
> + * Firmware either just requested a rollback or a rollback attempt
> + * failed. Keep the PSP dead for all other commands, only another
> + * DLFW_EX attempt is allowed through.
> + */
> + if (sev->fwl_rollback_required) {
> + psp_dead = true;
> + if (fwl_ret != FW_UPLOAD_ERR_HW_ERROR)
> + fwl_ret = FW_UPLOAD_ERR_RW_ERROR;
I think this error switcharoo could use a comment (or maybe just be
dropped?). e.g. if the user does something to set
->fwl_rollback_required and then tries another firmware upload that is
the wrong size, ERR_INVALID_SIZE -> ERR_RW_ERROR, which seems
misleading to me.
I saw some discussion about all this:
https://lore.kernel.org/lkml/20260924213737.3833625-1-shansinha@google.com/
but it's not clear to me why you need to reset the error code here.
Thanks,
Tycho
next prev parent reply other threads:[~2026-10-15 19:38 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-15 2:14 [Patch v4 0/7] Implement SNP live firmware update support Pratik R. Sampat
2026-10-15 2:14 ` [Patch v4 1/7] firmware_loader: Stop pinning modules on registration Pratik R. Sampat
2026-10-15 2:14 ` [Patch v4 2/7] firmware_loader: Stop pinning parent device per workqueue invocation Pratik R. Sampat
2026-10-15 2:14 ` [Patch v4 3/7] treewide: firmware_loader: Drop the unused @module argument Pratik R. Sampat
2026-10-15 2:14 ` [Patch v4 4/7] crypto: ccp - Factor out the release of the SEV firmware buffers Pratik R. Sampat
2026-10-15 17:53 ` Tom Lendacky
2026-10-15 2:14 ` [Patch v4 5/7] crypto: ccp - Allow SNP platform data to be queried after SNP INIT Pratik R. Sampat
2026-10-15 18:02 ` Tom Lendacky
2026-10-15 2:14 ` [Patch v4 6/7] crypto/ccp: Register with fw_uploader and always fail Pratik R. Sampat
2026-10-15 2:14 ` [Patch v4 7/7] crypto/ccp: Implement SNP Download Firmware EX Pratik R. Sampat
2026-10-15 19:38 ` Tycho Andersen [this message]
2026-10-15 21:09 ` 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=atElnAcDQFTnmdVr@tycho.pizza \
--to=tycho@kernel.org \
--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=prsampat@amd.com \
--cc=rafael@kernel.org \
--cc=russ.weight@linux.dev \
--cc=shansinha@google.com \
--cc=thomas.lendacky@amd.com \
/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.