On Fri, 14 May 2021 at 05:21, Qiuxu Zhuo <qiuxu.zhuo@xxxxxxxxx> wrote:
>
> >> From: linux-efi-owner@xxxxxxxxxxxxxxx <linux-efi-owner@xxxxxxxxxxxxxxx> On Behalf Of Ard Biesheuvel
> >> ...
> >>
> >> OK, so I see one complication with this. The EFI UpdateCapsule() runtime
> >> service expects the OS to use the EFI ResetSystem() runtime service to
> >> perform the reboot. pstore is designed to record whatever it can while the
> >> system is crashing, and so it this would need reboot_on_panic at the very
> >> least, but even then, it is not very likely that you would be able to do a
> >> clean soft reboot from that state in the general case.
> >>
> >> So unless there is a way to perform the test steps /without/ relying on
> >> magic SysRq to do a soft reboot after the system has panicked, I'm not convinced this is worthwhile.
>
>
> > Hi Ard,
> >
> > Your concern is reasonable! Thanks!
> >
> > Yes, the capsule-pstore driver depends on the EFI ResetSystem() runtime service
> > to perform the reboot to save the capsules of crashing dump across a warm reset.
> > Investigation on current Linux kernel reboot code (see the commits below) of
> > arm64 and x86 shows that if the system is UEFI Runtime Services available or
> > if an EFI capsule has been sent to the firmware then the system is forced to
> > use EFI ResetSystem(). I.e., the EFI ResetSystem() will be the preferred reboot
> > path if we have EFI capsules.
> >
> > arm64: 60c0d45a7f7a ("efi/arm64: use UEFI for system reset and poweroff")
> > x86: 87615a34d561 ("x86/efi: Force EFI reboot to process pending capsules")
> >
> > So the capsule-pstore simply depends on reboot_on_panic. The dependency may
> > make it seem to be different from some other pstore backend drivers that save
> > the dump to some persistent memory, so they don’t care how the system is reset
> > (could even be power-cycled). Whether rebooting the kernel or pinning it in a
> > loop on panic is controlled by "panic_timeout" which is exported for external
> > modules. The capsule-pstore driver may check it and print a warning message if
> > it isn't set to trigger a reboot (panic_timeout=0).
> >
> > One more example of pstore successfully using the capsule-pstore driver is showed
> > as below (the panic_timeout=1 was pre-set, so the kernel got reboot on panic).
> > It didn't relying on magic SysRq to reboot the system. Tested the capsule-pstore
> > driver that it still worked well.
> >
> > Summary: The capsule-pstore only depends on panic_timeout !=0. If panic_timeout !=0,
> > then the capsule-pstore can work (certainly, the system should have EFI Runtime Services).
> > Hope the capsule-pstore is still a worthwhile pstore backend. :-)
> > ...
>
> Hi Ard,
>
> Hope all is well with you. May I know whether the comments above make sense for you?
> Thanks!
>
The point is really that even when reboot_on_panic is enabled, there
are many cases where a panic condition prevents the kernel from doing
anything at all, including scheduling the workqueue thread that
handles EFI runtime service calls.
Of course, this applies equally to efi-pstore itself, but at least
that uses EFI runtime services that can be expected to work at
runtime, as opposed to UpdateCapsule(), which is only ever used at
boot time in that majority of cases (both Linux and Windows carry a
special capsule loader that reboots into UEFI so that UpdateCapsule()
can be invoked at boot time, as UpdateCapsule() at runtime is hardly
tested and therefore broken on most production PC hardware)
