From: "NOMURA JUNICHI(野村 淳一)" <email@example.com>
To: Michael Roth <firstname.lastname@example.org>
Cc: LKML <email@example.com>,
"firstname.lastname@example.org" <email@example.com>, "firstname.lastname@example.org" <email@example.com>
Subject: RE: [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: Wed, 29 Jun 2022 07:38:09 +0000 [thread overview]
Message-ID: <OSZPR01MB6953EEF3F8E63330547E031183BB9@OSZPR01MB6953.jpnprd01.prod.outlook.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 2010 bytes --]
From: Michael Roth <firstname.lastname@example.org>
> Thanks for the debug info. I haven't been able to reproduce this on the
> Milan or Cascade Lake systems I've tried, with kexec -l/-p, and well as
> with/without -s, so there may be something hardware/environment-specific
> going on here, so I could really use your help to test possible fixes.
Sure. Thank you for trying to reproduce the problem.
> > 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.
> I think this might be the case. Prior to early_memremap() being
> available, we need to rely on the initialize identity map set up by the
> decompression kernel. It has some stuff to add mappings for boot_params
> and whatnot, but I don't see where boot_params->hdr.setup_data is
> If you use kexec -s to force kexec_file_load, then the kernel sets it up
> so that boot_params->hdr.setup_data points to some memory just after
> boot_params, and boot/compressed uses 2M pages in its identity map, so
> that generally ends up handling the whole range.
> But if you use kexec's default kexec_load functionality, setup_data might
> be allocated elsewhere, so in that case we might need explicit mapping. I
> noticed on my systems boot_params->hdr.setup_data seems to generally end
> up at 0x100000 for some reason, and maybe that addr just happens to
> get mapped for other reasons so I don't end up hitting the crash.
> Could you give it a shot with the kexec -s flag and so if that works?
Your explanation makes a lot of sense. I could successfully boot the 2nd
kernel if "kexec -s" is used.
> If so, can you apply the below potential fix, and retry your original
I tried your potential fix but it didn't work... The symptom was same
Jun'ichi Nomura, NEC Corporation / NEC Solution Innovators, Ltd.
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5766 bytes --]
next prev parent reply other threads:[~2022-06-29 7:38 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-24 0:44 [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) NOMURA JUNICHI(野村 淳一)
2022-06-24 9:03 ` Borislav Petkov
2022-06-24 10:14 ` NOMURA JUNICHI(野村 淳一)
2022-06-29 0:41 ` Michael Roth
2022-06-29 7:38 ` NOMURA JUNICHI(野村 淳一) [this message]
2022-06-29 8:20 ` Borislav Petkov
2022-06-29 11:06 ` NOMURA JUNICHI(野村 淳一)
2022-06-29 13:52 ` Michael Roth
2022-06-29 15:35 ` Michael Roth
2022-06-29 13:54 ` Michael Roth
2022-06-30 8:25 ` NOMURA JUNICHI(野村 淳一)
2022-08-16 14:25 ` [Regression v5.19-rc1] kernel fails to boot, no console output " Jeremi Piotrowski
2022-08-16 15:06 ` Michael Roth
2022-08-17 8:40 ` Jeremi Piotrowski
2022-08-22 16:39 ` Michael Roth
2022-09-08 9:35 ` Jeremi Piotrowski
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.