On Tue, 13 Mar 2018 23:41:46 +1100
Michael Ellerman <m...@ellerman.id.au> wrote:
> Nicholas Piggin <npig...@gmail.com> writes:
>
> > diff --git a/arch/powerpc/platforms/pseries/kexec.c
> > b/arch/powerpc/platforms/pseries/kexec.c
> > index eeb13429d685..3fe126796975 100644
> > --- a/arch/powerpc/platforms/pseries/kexec.c
> > +++ b/arch/powerpc/platforms/pseries/kexec.c
> > @@ -23,7 +23,12 @@
> >
> > void pseries_kexec_cpu_down(int crash_shutdown, int secondary)
> > {
> > - /* Don't risk a hypervisor call if we're crashing */
> > + /*
> > + * Don't risk a hypervisor call if we're crashing
> > + * XXX: Why? The hypervisor is not crashing. It might be better
> > + * to at least attempt unregister to avoid the hypervisor stepping
> > + * on our memory.
> > + */
>
> Because every extra line of code we run in the crashed kernel is another
> opportunity to screw up and not make it into the kdump kernel.
>
> For example the hcalls we do to unregister the VPA might trigger hcall
> tracing which runs a bunch of code and might trip up on something. We
> could modify those hcalls to not be traced, but then we can't trace them
> in normal operation.
We really make no other hcalls in a crash? I didn't think of that.
>
> And the hypervisor might continue to write to the VPA, but that's OK
> because it's the VPA of the crashing kernel, the kdump kernel runs in a
> separate reserved memory region.
Well that takes care of that concern.
> Possibly we could fix the hcall tracing issues etc, but this code has
> not given us any problems for quite a while (~13 years) - ie. there
> seems to be no issue with re-registering the VPAs etc. in the kdump
> kernel.
No I think it's okay then, if you could drop that hunk...
Thanks,
Nick
