RE: [PATCH v6 2/2] eif/capsule-pstore: Add capsule pstore backend

[Qiuxu Zhuo <qiuxu.zhuo@intel.com>]

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

-Qiuxu