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

["Zhuo, Qiuxu" <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.  :-)

       #include <linux/module.h>
       #include <linux/irq_work.h>

       static struct irq_work my_irq_work;

       static void my_irq_work_cb(struct irq_work *irq_work)
       {
               *((int *)0) = 0xdeadbeaf;
       }

       static int __init my_init(void)
       {
               init_irq_work(&my_irq_work, my_irq_work_cb);
               irq_work_queue(&my_irq_work);
               return 0;
       }

       static void __exit my_exit(void) {}

       module_init(my_init);
       module_exit(my_exit);

-Qiuxu