Re: [PATCH 2/2] Allow kdump with crash_kexec_post_notifiers

[Petr Tesarik <ptesarik@suse.com>]

On Mon, 1 Aug 2016 15:47:58 +0200
"Jan Beulich" <JBeulich@suse.com> wrote:

> (re-adding xen-devel)
> 
> >>> On 01.08.16 at 15:02, <PTesarik@suse.com> wrote:
> > On Mon, 1 Aug 2016 13:55:01 +0200
> > "Jan Beulich" <JBeulich@suse.com> wrote:
> > 
> >> >>> On 13.07.16 at 14:53, <david.vrabel@citrix.com> wrote:
> >> > On 13/07/16 13:20, Petr Tesarik wrote:
> >> >> If a crash kernel is loaded, do not crash the running domain. This is
> >> >> needed if the kernel is loaded with crash_kexec_post_notifiers, because
> >> >> panic notifiers are run before __crash_kexec() in that case, and this
> >> >> Xen hook prevents its being called later.
> >> > 
> >> > Prioritising the in-kernel kexec image over the hypervisor one seems
> >> > sensible behaviour to me.
> >> 
> >> For HVM guests certainly; does loading of an in-kernel crash kernel
> >> properly fail for PV guests (and namely PV Dom0), or does such a
> >> setup work nowadays?
> > 
> > This is a good question, but I don't think it is relevant to this
> > patch. It does not change anything unless the kernel is booted with
> > crash_kexec_post_notifiers.
> > 
> > I fully understand that Dom0 kernels want to load the panic kernel in
> > the hypervisor and crash the complete machine, rather than just Dom0,
> > but if you want that behaviour, simply pass the "crashkernel="
> > parameter only to the Xen hypervisor and not to the Dom0 kernel.
> > 
> > Did I miss something?
> 
> For one there are still many people who, for varying reasons, add
> "crashkernel=" also to Dom0's command line.

Is there a valid use case for it?

FWIW the legacy Xen implementation (as found in SLES) simply ignores
the 'crashkernel=' kernel parameter. The code is not even compiled in.

> And then trying to invoke a locally loaded crash kernel which won't
> work is bad

Without actually knowing whether a PV kernel can kexec another PV
kernel, this discussion is somewhat moot...

But let me repeat: if PV kexec works, then it has always had priority
over the hypercall. If it doesn't work, then it has always been broken.
For the latter case, I agree that the kernel should not even allow to
load the kexec image, but that's unrelated to my patch.

Has anyone here tried booting up a PV domain and performing kexec(2)?
I can't test it with my SLES12 installation, because the kexec(8)
user-space utility is patched in SLES to load the hypervisor kexec
image with a hypercall if Xen is detected.

Petr T

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel