From: Shantanu Sinha <shansinha@google.com>
To: tycho@kernel.org
Cc: shansinha@google.com, jackyli@google.com, aik@amd.com,
ashish.kalra@amd.com, davem@davemloft.net,
herbert@gondor.apana.org.au, john.allen@amd.com,
kim.phillips@amd.com, linux-crypto@vger.kernel.org,
linux-kernel@vger.kernel.org, michael.roth@amd.com,
nikunj@amd.com, prsampat@amd.com, seanjc@google.com,
thomas.lendacky@amd.com
Subject: Re: [PATCH 6/6] crypto/ccp: Implement SNP firmware live update
Date: Mon, 31 Aug 2026 20:47:57 +0000 [thread overview]
Message-ID: <20260831204757.436751-1-shansinha@google.com> (raw)
In-Reply-To: <20260430160716.1120553-7-tycho@kernel.org>
On Thu, Apr 30, 2026 at 10:07:16AM -0600, Tycho Andersen wrote:
> +static int sev_firmware_shutdown_if_sev_initialized(struct sev_device *sev)
> +{
> + int rc, error;
> + int sev_plat_state;
> +
> + rc = sev_get_platform_state(&sev_plat_state, &error);
> + if (rc) {
> + if (error)
> + rc = error;
> + dev_dbg(sev->dev, "SEV get platform state failed %d\n", rc);
> + return rc;
> + }
> +
> + switch (sev_plat_state) {
> + case SEV_STATE_UNINIT:
> + return 0;
> + case SEV_STATE_INIT:
> + error = 0;
> + rc = __sev_platform_shutdown_locked(&error);
> + if (rc) {
> + if (error)
> + rc = error;
> + dev_err(sev->dev, "SEV platform shutdown failed %d\n", rc);
> + return rc;
> + }
> +
> + sev_firmware_needs_reinit = true;
> + return 0;
Tested this on Milan and hit a failure during SEV re-init after firmware update.
__sev_platform_shutdown_locked() sets the FW platform state to UNINIT, but
sev_es_tmr and sev_init_ex_buffer remain firmware-owned in the RMP. When the
new firmware comes up, SEV_CMD_INIT_EX rejects the stale page state and fails
with SEV_RET_INVALID_PAGE_STATE (0x1A).
Tearing down the buffers on shutdown fixes it for us:
--- a/drivers/crypto/ccp/sev-dev.c
+++ b/drivers/crypto/ccp/sev-dev.c
@@ -1905,6 +1905,20 @@ static int sev_firmware_shutdown_if_sev_initialized(struct sev_device *sev)
}
+ if (sev_es_tmr) {
+ wbinvd_on_all_cpus();
+ __snp_free_firmware_pages(virt_to_page(sev_es_tmr),
+ get_order(sev_es_tmr_size),
+ true);
+ sev_es_tmr = NULL;
+ }
+
+ if (sev_init_ex_buffer) {
+ __snp_free_firmware_pages(virt_to_page(sev_init_ex_buffer),
+ get_order(NV_LENGTH),
+ true);
+ sev_init_ex_buffer = NULL;
+ }
+
sev_firmware_needs_reinit = true;
return 0;
(Could also pull this and the cleanup in __sev_firmware_shutdown() into a shared
helper. This logic is duplicated there.)
> if (ret == FW_UPLOAD_ERR_NONE) {
> error = 0;
>
> rc = sev_get_api_version();
> if (rc) {
> if (error)
> rc = error;
> dev_err(sev->dev, "SEV query api version failed %d\n", rc);
> }
> }
>
> + if (!dlfwex_wants_rollback)
> + sev_firmware_reinit_if_shutdown(sev);
If rc == SEV_RET_HWSEV_RET_UNSAFE, psp_dead is true but dlfwex_wants_rollback
is false, so it still falls through to re-init. Even though it is
recommended that the host should be rebooted after HARDWARE_UNSAFE,
reboot tooling can lag and we may want some buffer. Plus the kernel shouldn't
be touching a dead PSP anyway. Checking !psp_dead is a simple safeguard against
extra churn while awaiting restart:
+ if (!dlfwex_wants_rollback && !psp_dead)
sev_firmware_reinit_if_shutdown(sev);
I also moved the call to sev_firmware_reinit_if_shutdown() ahead of
sev_get_api_version() so sev->state is already restored to INIT before sev
status is queried. This is just to avoid unnecessary transient states.
Curious if that logic makes sense to you. Am I missing something that made
the original ordering strictly necessary?
Best,
Shantanu
next prev parent reply other threads:[~2026-08-31 20:47 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-30 16:07 [RFC v1 0/6] Implement SNP DOWNLOAD_FIRMWARE_EX support Tycho Andersen
2026-04-30 16:07 ` [RFC v1 1/6] crypto/ccp: Hoist kernel part of SNP_PLATFORM_STATUS Tycho Andersen
2026-04-30 16:07 ` [RFC v1 2/6] crypto/ccp: Allow snp_get_platform_data() after SNP init Tycho Andersen
2026-04-30 16:07 ` [RFC v1 3/6] crypto/ccp: Add DOWNLOAD_FIRMWARE_EX message struct Tycho Andersen
2026-04-30 16:07 ` [RFC v1 4/6] crypto/ccp: Reclaim command buffer when the PSP dies Tycho Andersen
2026-04-30 16:07 ` [RFC v1 5/6] crypto/ccp: Register with fw_uploader and always fail Tycho Andersen
2026-04-30 16:07 ` [RFC v1 6/6] crypto/ccp: Implement SNP firmware live update Tycho Andersen
2026-05-03 3:18 ` Maxwell Doose
2026-05-03 3:25 ` Maxwell Doose
2026-05-04 13:57 ` Tycho Andersen
2026-05-04 18:43 ` Maxwell Doose
2026-08-31 20:47 ` Shantanu Sinha [this message]
2026-09-02 17:44 ` [PATCH " 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=20260831204757.436751-1-shansinha@google.com \
--to=shansinha@google.com \
--cc=aik@amd.com \
--cc=ashish.kalra@amd.com \
--cc=davem@davemloft.net \
--cc=herbert@gondor.apana.org.au \
--cc=jackyli@google.com \
--cc=john.allen@amd.com \
--cc=kim.phillips@amd.com \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=michael.roth@amd.com \
--cc=nikunj@amd.com \
--cc=prsampat@amd.com \
--cc=seanjc@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 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®