Separate protocol vs. fix-up on InstallConfigurationTable

[jan-kiszka]

I found the latter as what edk2-nvidia does, and I was wondering what the downside of this implicit fix-up are. Would be good to add that to the reasoning for this explicit approach here.

[jan-kiszka]

Ok, I understand the trick of Nvidia by now: They require the bootloader to pass a DTB blob with sufficient free space to perform the fix-up. That only works with their custom loader L4TLauncher, it fails miserably with standard bootloaders like systemd-boot.

If such a trick is within the current UEFI spec is also questionable: "UEFI applications are permitted to modify or replace the loaded DTB. System firmware must not depend on any data contained within the DTB.". Also the interface Nvidia hooked into, EFI_BOOT_SERVICES.InstallConfigurationTable(), was not designed for this.

[xypron]

The header of the flattened device tree provides all the information needed to find out if there is enough space to do the fix-ups. If there is not enough space left the EFI application has to allocate memory for a new device-tree and replace the flattened device tree using InstallConfigurationTable().

As the installed device-tree may be changed by EFI applications it is reasonable that the UEFI implementation does not depend on that configuration table.

The EFI_DT_FIXUP_PROTOCOL checks the size before applying fix-ups and requests the calling application to provide a larger buffer if there is not enough space for fix-ups. The U-Boot implementation ensures that after the fix-ups there is still enough room for GRUB and Linux do further fix-ups in place without allocating a new device-tree. See function efi_dt_fixup() where we have

                required_size = fdt_off_dt_strings(dtb) +
                                fdt_size_dt_strings(dtb) +
                                0x3000;

[xypron]

Letting InstallConfigurationTable() make fix-ups automatically is problematic:

If the provided device-tree is too small for fix-ups, a new device-tree would need to be allocated. But that would change the address of the device-tree. The calling application cannot be assumed to look up the changed address after calling InstallConfigurationTable().

This is why we need the suggested protocol.