mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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

  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®