Nicholas Piggin <npig...@gmail.com> writes:
> 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.
We do, but they're explicitly written to use plpar_hcall_raw().
And TBH I haven't tested a kdump with hcall tracing enabled lately, so
for all I know it's broken, but that's the theory at least.
cheers
