From: Ashish Kalra ashish.kalra@amd.com
[ Upstream commit 8c571019d8a817b701888926529a5d7a826b947b ]
Since SEV or SNP may already be initialized in the previous kernel, attempting to initialize them again in the kdump kernel can result in SNP initialization failures, which in turn lead to IOMMU initialization failures. Moreover, SNP/SEV guests are not run under a kdump kernel, so there is no need to initialize SEV or SNP during kdump boot.
Skip SNP and SEV INIT if doing kdump boot.
Tested-by: Sairaj Kodilkar sarunkod@amd.com Signed-off-by: Ashish Kalra ashish.kalra@amd.com Link: https://lore.kernel.org/r/d884eff5f6180d8b8c6698a6168988118cf9cba1.175615791... Signed-off-by: Joerg Roedel joerg.roedel@amd.com Signed-off-by: Sasha Levin sashal@kernel.org ---
LLM Generated explanations, may be completely bogus:
YES
- Fixes real kdump failures: Reinitializing SEV/SNP in the kdump kernel can fail SNP init and cascade into AMD IOMMU init failures, preventing reliable crash dumps. Skipping SEV/SNP init in kdump avoids this failure mode and aligns with the fact that SEV/SNP guests aren’t run under kdump. - Minimal, targeted change: Adds `#include <linux/crash_dump.h>` to access `is_kdump_kernel()` and short-circuits SEV/SNP init only when booted as kdump. - Include added: drivers/crypto/ccp/sev-dev.c:31 - Early return on kdump: drivers/crypto/ccp/sev-dev.c:1627 - Normal boots unaffected: Outside kdump, the init path is unchanged and continues to: - Return early if already initialized: drivers/crypto/ccp/sev- dev.c:1632 - Attempt SNP init: drivers/crypto/ccp/sev-dev.c:1635 - Then legacy SEV init: drivers/crypto/ccp/sev-dev.c:1643 - Callers consistent with design: `sev_platform_init()` is primarily invoked when setting up SEV/SNP VMs (e.g., KVM path) and won’t be used in a kdump kernel where VMs aren’t launched: - KVM caller example: arch/x86/kvm/svm/sev.c:448 - Established pattern: Many subsystems adjust behavior based on `is_kdump_kernel()`, including AMD IOMMU, reinforcing that deferring hardware state churn in kdump is correct and expected. - Example precedent: drivers/iommu/amd/init.c:409 - Low regression risk: The change is a simple guard that only applies in kdump. It avoids reprogramming PSP/SEV/SNP during a crash kernel, which is specifically where hardware re-init is fragile. It does not introduce new features or alter interfaces. - Backport considerations: Older stable trees may have minor local differences (e.g., `sev->state` vs. `sev->sev_plat_status.state`, or `__sev_snp_init_locked` signature). The kdump guard itself is trivial to adapt and `is_kdump_kernel()` is long-standing and available via `linux/crash_dump.h`.
Conclusion: This is a small, well-scoped bug fix that improves kdump robustness on SEV/SNP systems with minimal risk and no architectural changes. It meets stable backport criteria.
drivers/crypto/ccp/sev-dev.c | 10 ++++++++++ 1 file changed, 10 insertions(+)
diff --git a/drivers/crypto/ccp/sev-dev.c b/drivers/crypto/ccp/sev-dev.c index 9f5ccc1720cbc..651346db6909d 100644 --- a/drivers/crypto/ccp/sev-dev.c +++ b/drivers/crypto/ccp/sev-dev.c @@ -28,6 +28,7 @@ #include <linux/fs_struct.h> #include <linux/psp.h> #include <linux/amd-iommu.h> +#include <linux/crash_dump.h>
#include <asm/smp.h> #include <asm/cacheflush.h> @@ -1345,6 +1346,15 @@ static int _sev_platform_init_locked(struct sev_platform_init_args *args) if (!psp_master || !psp_master->sev_data) return -ENODEV;
+ /* + * Skip SNP/SEV initialization under a kdump kernel as SEV/SNP + * may already be initialized in the previous kernel. Since no + * SNP/SEV guests are run under a kdump kernel, there is no + * need to initialize SNP or SEV during kdump boot. + */ + if (is_kdump_kernel()) + return 0; + sev = psp_master->sev_data;
if (sev->state == SEV_STATE_INIT)