On Fri, 14 May 2021 at 05:21, Qiuxu Zhuo [off-list ref] wrote:

quoted

quoted

From: linux-efi-owner@vger.kernel.org <redacted> 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.

quoted

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)