Re: [PATCH v2 01/12] kexec: Allow architecture code to opt-out at runtime
From: Joerg Roedel <hidden>
Date: 2021-11-02 17:00:27
Also in:
kexec, kvm, lkml, stable, virtualization
Possibly related (same subject, not in this thread)
- 2021-11-02 · Re: [PATCH v2 01/12] kexec: Allow architecture code to opt-out at runtime · Eric W. Biederman <hidden>
- 2021-11-01 · Re: [PATCH v2 01/12] kexec: Allow architecture code to opt-out at runtime · Borislav Petkov <bp@alien8.de>
- 2021-09-13 · [PATCH v2 01/12] kexec: Allow architecture code to opt-out at runtime · Joerg Roedel <joro@8bytes.org>
Hi again, On Mon, Nov 01, 2021 at 04:11:42PM -0500, Eric W. Biederman wrote:
I seem to remember the consensus when this was reviewed that it was unnecessary and there is already support for doing something like this at a more fine grained level so we don't need a new kexec hook.
Forgot to state to problem again which these patches solve: Currently a Linux kernel running as an SEV-ES guest has no way to successfully kexec into a new kernel. The normal SIPI sequence to reset the non-boot VCPUs does not work in SEV-ES guests and special code is needed in Linux to safely hand over the VCPUs from one kernel to the next. What happens currently is that the kexec'ed kernel will just hang. The code which implements the VCPU hand-over is also included in this patch-set, but it requires a certain level of Hypervisor support which is not available everywhere. To make it clear to the user that kexec will not work in their environment, it is best to disable the respected syscalls. This is what the hook is needed for. Regards, -- Jörg Rödel jroedel@suse.de SUSE Software Solutions Germany GmbH Maxfeldstr. 5 90409 Nürnberg Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev