Re: [Xen-devel] [PATCH 2/2] Allow kdump with crash_kexec_post_notifiers

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 01.08.16 at 16:15, <PTesarik@xxxxxxxx> wrote:
> On Mon, 1 Aug 2016 15:47:58 +0200
> "Jan Beulich" <JBeulich@xxxxxxxx> wrote:
> 
>> (re-adding xen-devel)
>> 
>> >>> On 01.08.16 at 15:02, <PTesarik@xxxxxxxx> wrote:
>> > On Mon, 1 Aug 2016 13:55:01 +0200
>> > "Jan Beulich" <JBeulich@xxxxxxxx> wrote:
>> > 
>> >> >>> On 13.07.16 at 14:53, <david.vrabel@xxxxxxxxxx> 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?

No, but people doing so shouldn't end up being in more trouble than
they already are with their crashed guest. I.e. ...

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

... along those lines the pointlessly specified option should have
no effect.

>> 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.

It's not, afaict: without your patch, the hypercall to report the guest
crashed would be made unconditionally, without even an attempt to
load that secondary kernel.

Jan


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