Joerg Roedel
2021-May-06 09:31 UTC
[PATCH 2/2] x86/kexec/64: Forbid kexec when running as an SEV-ES guest
From: Joerg Roedel <jroedel at suse.de> For now, kexec is not supported when running as an SEV-ES guest. Doing so requires additional hypervisor support and special code to hand over the CPUs to the new kernel in a safe way. Until this is implemented, do not support kexec in SEV-ES guests. Cc: stable at vger.kernel.org # v5.10+ Signed-off-by: Joerg Roedel <jroedel at suse.de> --- arch/x86/kernel/machine_kexec_64.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/arch/x86/kernel/machine_kexec_64.c b/arch/x86/kernel/machine_kexec_64.c index c078b0d3ab0e..f902cc9cc634 100644 --- a/arch/x86/kernel/machine_kexec_64.c +++ b/arch/x86/kernel/machine_kexec_64.c @@ -620,3 +620,11 @@ void arch_kexec_pre_free_pages(void *vaddr, unsigned int pages) */ set_memory_encrypted((unsigned long)vaddr, pages); } + +/* + * Kexec is not supported in SEV-ES guests yet + */ +bool arch_kexec_supported(void) +{ + return !sev_es_active(); +} -- 2.31.1
Eric W. Biederman
2021-May-06 17:42 UTC
[PATCH 2/2] x86/kexec/64: Forbid kexec when running as an SEV-ES guest
Joerg Roedel <joro at 8bytes.org> writes:> From: Joerg Roedel <jroedel at suse.de> > > For now, kexec is not supported when running as an SEV-ES guest. Doing > so requires additional hypervisor support and special code to hand > over the CPUs to the new kernel in a safe way. > > Until this is implemented, do not support kexec in SEV-ES guests.I don't understand this. Fundamentally kexec is about doing things more or less inspite of what the firmware is doing. I don't have any idea what a SEV-ES is. But the normal x86 boot doesn't do anything special. Is cross cpu IPI emulation buggy? If this is a move in your face hypervisor like Xen is sometimes I can see perhaps needing a little bit of different work during bootup. Perhaps handing back a cpu on system shutdown and asking for more cpus on system boot up. What is the actual problem you are trying to avoid? And yes for a temporary hack the suggestion of putting code into machine_kexec_prepare seems much more reasonable so we don't have to carry special case infrastructure for the forseeable future. Eric> Cc: stable at vger.kernel.org # v5.10+ > Signed-off-by: Joerg Roedel <jroedel at suse.de> > --- > arch/x86/kernel/machine_kexec_64.c | 8 ++++++++ > 1 file changed, 8 insertions(+) > > diff --git a/arch/x86/kernel/machine_kexec_64.c b/arch/x86/kernel/machine_kexec_64.c > index c078b0d3ab0e..f902cc9cc634 100644 > --- a/arch/x86/kernel/machine_kexec_64.c > +++ b/arch/x86/kernel/machine_kexec_64.c > @@ -620,3 +620,11 @@ void arch_kexec_pre_free_pages(void *vaddr, unsigned int pages) > */ > set_memory_encrypted((unsigned long)vaddr, pages); > } > + > +/* > + * Kexec is not supported in SEV-ES guests yet > + */ > +bool arch_kexec_supported(void) > +{ > + return !sev_es_active(); > +}