Driver model at UEFI runtime

[Heinrich Schuchardt]

Hello Simon,

The EBBR specification requires that the UEFI SystemReset() runtime
service is available to the operating system.

Up to now this has been implemented by overriding function
efi_reset_system() which is marked as __efi_runtime.

Both ARM and RISC-V support generic interfaces for reset. PSCI for ARM
and the System Reset Extension for SBI on RISC-V. This has kept the
number of implementations low. The only exceptions are:

* arch/arm/cpu/armv8/fsl-layerscape/cpu.c
* arch/arm/mach-bcm283x/reset.c for the Raspberry PIs
* arch/sandbox/cpu/start.c

Bin has suggested in
https://lists.denx.de/pipermail/u-boot/2021-September/459865.html to use
reset drivers based on the driver model.

Currently after ExitBootServices() the driver model does not exist anymore.

When evaluating Bin's suggestion one has to keep in mind that after
invoking ExitBootServices() most operating systems call
SetVirtualAddressMap(). Due to the change of the address map all
pointers used by U-Boot afterwards must be updated to match the new
memory map.

The impression that Ilias and I have is that keeping the driver model
alive after SetVirtualAddressMap() would incur:

* a high development effort
* a significant code size increase
* an enlarged attack surface

For RISC-V it has been clarified in the platform specification that the
SBI must implement the system reset extension. For ARMv8 using TF-A and
PSCI is what ARM suggests.

So for these architectures we do not expect a growth in the number of
drivers needed.

Ilias and my favorite would be keeping the design as is.

What is your view on this?

Best regards

Heinrich