I found crash kexec fails to boot the 2nd kernel since v5.19-rc1 and git bisect points to this as a bad commit: commit b190a043c49af4587f5e157053f909192820522a Author: Michael Roth Date: Thu Feb 24 10:56:18 2022 -0600 x86/sev: Add SEV-SNP feature detection/setup Initial/preliminary detection of SEV-SNP is done via the Confidential Computing blob. Check for it prior to the normal SEV/SME feature initialization, and add some sanity checks to confirm it agrees with SEV-SNP CPUID/MSR bits. The problem seems to occur when find_cc_blob_setup_data() walks setup_data chain. If the code is modified to do nothing in find_cc_blob_setup_data(), the 2nd kernel boots fine. On my system, the chain of setup_data looks like following on regular boot: setup_data: type=0x3 addr=0x9e9e5018 next=0x9e9dc018 setup_data: type=0x3 addr=0x9e9dc018 next=0x9e9d2018 setup_data: type=0x3 addr=0x9e9d2018 next=0x8a27b018 setup_data: type=0x3 addr=0x8a27b018 next=0x8a218018 setup_data: type=0x3 addr=0x8a218018 next=0x9e9a0018 setup_data: type=0x3 addr=0x9e9a0018 next=0x8a1e6018 setup_data: type=0x3 addr=0x8a1e6018 next=0x8a1b4018 setup_data: type=0x3 addr=0x8a1b4018 next=0x8a182018 setup_data: type=0x3 addr=0x8a182018 next=0x8a056018 setup_data: type=0x3 addr=0x8a056018 next=0x8a020018 setup_data: type=0x3 addr=0x8a020018 next=0x89fea018 setup_data: type=0x3 addr=0x89fea018 next=0x0 OTOH, it looks like following on crash kexec boot: setup_data: type=0x4 addr=0x2e000000 next=0x0 Other places that parses setup_data uses early_memremap() before accessing the data (e.g. parse_setup_data()). I wonder if the lack of remapping causes the problem but find_cc_blob is too early in the boot process for early_memremap to work. -- Jun'ichi Nomura, NEC Corporation / NEC Solution Innovators, Ltd.