On Mon, Aug 26, 2019 at 3:13 PM Marc Zyngier <maz@xxxxxxxxxx> wrote: > > On Mon, 26 Aug 2019 15:00:50 -0400 > Pavel Tatashin <pasha.tatashin@xxxxxxxxxx> wrote: > > > Marc Zyngier added the support for kexec and GICv3 for EFI based systems. > > However, it is still not possible todo on systems with device trees. > > > > Here is EFI fixes from Marc: > > https://lore.kernel.org/lkml/20180921195954.21574-1-marc.zyngier@xxxxxxx > > > > For Device Tree variant: lets allow reserve a memory region in interrupt > > controller node, and use this property to allocate interrupt tables. > > There is no such thing as a "device tree variant". As long as your > bootloader implements EFI, everything will work correctly, whether > you're using DT, ACPI, or the anything else. > > This already works today, without any need to add anything to the > kernel (I have systems using EDK II and u-boot, both implementing EFI, > and I'm able to kexec without any issue). If your bootloader doesn't > support EFI, here's a good opportunity to implement it! Hi Marc, Thank you very much for looking at this work. Running Linux without EFI is common, and there are scenarios which make it appropriate. As I understand most of embedded linux do not have EFI enabled, and thus I do not see a reason why we would not support a first class feature of Linux (kexec) on non-EFI bootloaders. We (Microsoft) have a small highly secure device with a high uptime requirement. The device also has PCIe and thus GICv3. The update for this device relies on kexec. For a number of reasons, it was decided to use U-Boot and Linux without EFI enabled. One of those reasons is to improve boot performance, enabling EFI in U-Boot alone reduces the boot performance by half a second. Our total reboot budget is under a second which makes that half a second unacceptable. Also, adding EFI support to kernel increases its size and there are security implications from enabling more code both in U-Boot and Linux. > -- > Without deviation from the norm, progress is not possible. Totally agreed. Thank you, Pasha _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec
