From: Michael Roth <firstname.lastname@example.org>
To: "NOMURA JUNICHI(野村 淳一)" <email@example.com>
Cc: Borislav Petkov <firstname.lastname@example.org>,
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 08:52:54 -0500 [thread overview]
Message-ID: <email@example.com> (raw)
On Wed, Jun 29, 2022 at 11:06:00AM +0000, NOMURA JUNICHI(野村 淳一) wrote:
> From: Borislav Petkov <firstname.lastname@example.org>
> > I still think the proper fix is to not execute that cc blob code on
> > anything but AMD...
> That will solve my case but I'm afraid there may be people with AMD who
> hits the same problem.
Yah, I'd mentioned to Boris that I was only able to reproduce it on
baremetal Intel system, but that ended up being an unrelated issue due
to having KASAN enabled in my config (which seems to break kexec for me).
But the issue you're seeing I haven't been able to reproduce, and I'm
not sure what is needed to get it to reproduce, but it might not be
> Isn't it possible for boot loaders to pass cc_blob_address via boot_params?
> Information included in struct cc_setup_data is just 'u32 cc_blob_address'
> and it seems struct boot_params already has a place reserved for it.
We were trying to avoid exposing cc_blob_address to boot loaders
directly, since linux boot protocol seems to prefer the setup_data entry
for new parameters.
The reason the kernel uses boot_params->cc_blob_address internally is
because boot/compressed has all the helpers for early EFI parsing, and will
have already checked for the cc blob and cached it there, so the runtime
kernel just uses that instead of trying to introduce all the early EFI
parsing code into early boot and redo'ing all the parsing that
boot/compressed has already done.
So the runtime kernel relies on boot/compressed for handling EFI, and
simply uses boot_params to pass that on to runtime kernel.
But it has its own handling for cc_blob passed via setup_data entry,
because that entry point is meant for boot loaders / VMMs that use stuff
like CONFIG_PVH to jump directly into decompressed kernel: those are the
cases where we'd expect cc blob via setup_data entry. But this is a
critical thing to support right now, and if we can't find a proper fix
we can simply disable this patch and not check for setup_data entry in
But I think we might still be able to fix this properly, I had a typo
in my early patch which would be worth try, and might avoid future
issues with other early setup_data access in the future code. I
responded there with an updated patch.
> Jun'ichi Nomura, NEC Corporation / NEC Solution Innovators, Ltd.
next prev parent reply other threads:[~2022-06-29 13:55 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(野村 淳一)
2022-06-29 8:20 ` Borislav Petkov
2022-06-29 11:06 ` NOMURA JUNICHI(野村 淳一)
2022-06-29 13:52 ` Michael Roth [this message]
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.