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

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

On Mon, Aug 01, 2016 at 04:15:10PM +0200, Petr Tesarik 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?
> 
> FWIW the legacy Xen implementation (as found in SLES) simply ignores
> the 'crashkernel=' kernel parameter. The code is not even compiled in.

I wonder if Xen should do that - as in 'fix' the bootparams to not have it.
Or perhaps Linux code during bootup can sanitze this..

> 
> > 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)?

Yes. Daniel (CC-ed) did it. He had it working but only for one CPU
and then Greg KH picked up the patchset .. and not sure what happend.

The underlaying issue was the PV guest could not re-initialize the grants,
events, etc - but now with Vitaly's 'reset' hypercall it would be possible.
Except the 'reset' hypercall is only for HVM guests.

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

Also the upstream one would do this.
> 
> Petr T
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxx
> https://lists.xen.org/xen-devel

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