[Regression v5.19-rc1] crash kexec fails to boot the 2nd kernel (Re: [PATCH v12 38/46] x86/sev: Add SEV-SNP feature detection/setup)

From: "NOMURA JUNICHI(野村　淳一)" <junichi.nomura@nec.com>
To: "brijesh.singh@amd.com" <brijesh.singh@amd.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
	"michael.roth@amd.com" <michael.roth@amd.com>,
	"x86@kernel.org" <x86@kernel.org>, "bp@suse.de" <bp@suse.de>
Subject: [Regression v5.19-rc1] crash kexec fails to boot the 2nd kernel (Re: [PATCH v12 38/46] x86/sev: Add SEV-SNP feature detection/setup)
Date: Fri, 24 Jun 2022 00:44:52 +0000	[thread overview]
Message-ID: <TYCPR01MB694815CD815E98945F63C99183B49@TYCPR01MB6948.jpnprd01.prod.outlook.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 1869 bytes --]

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 <michael.roth@amd.com>
  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.

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5766 bytes --]