Hi Alexander, We now use GitHub PRs for all EDK2 development. I hope that you find this easier than emails too.
Also, I don't really understand the point of this. If you already have a functional UEFI environment, then why wouldn't you develop against that? New core features can always be tested in OVMF, and if you're developing DXE drivers for your own environment, the odds are fairly high that you could just insert them into your existing FV, regardless of what you had to build against (if needed, use a UDK, or edk2-stable tag). UEFI is very modular that way. As an aside, if you can reduce your existing UEFI environment to just PEI (which makes sense, it eliminates all of the duplicate drivers), then you might be able to implement this as a UPL after adding the PayloadLoaderPeim to your FV. I'm curious, do you plan to use this in production? Personally, I don't think that this is needed to enable new core functionality, there are other platforms for that, so when I ask this, I'm thinking of your additional DXE drivers. I'm asking because, big picture, this seems like a complicated flow that might create its own bugs, which is exactly what I'd want to avoid. UEFI offers runtime services to the OS, which should be presented? Which are 'more correct?' (this has impact for variable services) - I will say that I've reviewed very little of the code so far. That would be easier with syntax highlighting in the GitHub UI. To be clear, I'm not saying that this absolutely shouldn't go in. I just want this to be well-thought out before we risk adding technical debt, and you risk a convoluted approach that might cause you problems down the line. Regards, Benjamin On Mon, Aug 17, 2026 at 3:41 PM Alexander Graf <[email protected]> wrote: > We want to chain-load UEFI from a functional UEFI environment. This is > useful for example to enable new core UEFI functionality or different > DXE drivers that would be more difficult to build against the running > version. It also lets us test UefiPayloadPkg under QEMU/OVMF without > building coreboot or Slim Bootloader first. > > This series adds ChainloadApp, a UEFI application that starts > UEFIPAYLOAD.fd from inside an already-running UEFI environment. > Everything is discovered, not configured: the UEFI memory map and GCD > map give the memory topology, ACPI SPCR gives the serial console, ACPI > MCFG gives the ECAM aperture, ACPI MADT gives the GIC on AArch64, and > the configuration table gives RSDP and SMBIOS. There are no > platform-specific addresses in the series. > > No core package is touched. The series lands in ArmPkg (1 patch), > ArmPlatformPkg (1) and UefiPayloadPkg (21). Endpoint BARs that the > outer firmware left at zero are programmed by ChainloadApp itself, > through ECAM located from the ACPI MCFG, before the payload is > launched, so the payload's light enumeration finds every BAR assigned > and a stock UEFIPAYLOAD.fd works unmodified. > > Patches 03, 04, 05 and 06 are independent bug fixes for existing > coreboot and Slim Bootloader users. Each one fixes a crash, an assert > or a silent memory loss that exists today, with no dependency on > chainloading, and each changes behaviour unconditionally because that > is the point of it. Everything else that could affect an existing > build is behind an option that defaults to the current value: > CHAINLOAD_DEFAULTS, VIRTIO_ENABLE and PcdPublishMcfgAsReservedMemory > are all FALSE unless a platform turns them on. One caveat on that > claim: I have not booted a coreboot board or a Slim Bootloader > platform with this series applied, so the compatibility argument comes > from reading the code. If someone with either can test it, I would > rather hear about a regression before this lands than after. > > All four tip configurations build clean (X64 and AArch64, DEBUG and > RELEASE), every commit builds individually across both architectures > and both CHAINLOAD_DEFAULTS values (92/92), and the chainloaded > payload boots under an outer edk2-based firmware: Ubuntu 24.04 arm64 > on AArch64, Windows Server 2025, Ubuntu 24.04 and FreeBSD 14.3 on X64, > DEBUG and RELEASE each. Memory handed to the OS matches a direct boot > of the same payload to within 100 KiB (0.005 %) on the AArch64 > reference platform. An ACPI/SMBIOS pointer scan on both architectures > found nothing in what the payload hands the OS that points into > memory reclaimed from the outer firmware. > > To reproduce: > > cd /path/to/edk2 > source edksetup.sh > ARCH=X64 BUILD_TARGET=DEBUG > ./UefiPayloadPkg/BuildChainloadEmbedded.sh > ARCH=AARCH64 BUILD_TARGET=DEBUG > ./UefiPayloadPkg/BuildChainloadEmbedded.sh > > UefiPayloadPkg/ChainloadApp/README.md has the exact QEMU command lines > for both architectures. > > Alex > > Cc: Ard Biesheuvel <[email protected]> > Cc: Benjamin Doron <[email protected]> > Cc: Gua Guo <[email protected]> > Cc: Guo Dong <[email protected]> > Cc: James Lu <[email protected]> > Cc: Leif Lindholm <[email protected]> > Cc: Sami Mujawar <[email protected]> > Cc: Sean Rhodes <[email protected]> > Cc: Shuo Liu <[email protected]> > Cc: Vishal Oliyil Kunnnil <[email protected]> > Signed-off-by: Alexander Graf <[email protected]> > > Alexander Graf (23): > ArmPlatformPkg/PL031RealTimeClockLib: Ignore pre-existing MMIO space > ArmPkg/ArmGicDxe: Bail out if no redistributor is found for this CPU > UefiPayloadPkg: Tolerate a bootloader with no SMBIOS table > UefiPayloadPkg/ResetSystemLib: Skip GPE clear when FADT has no GPE0 > block > UefiPayloadPkg/BaseSerialPortLibHob: Close EBS event in destructor > UefiPayloadPkg/UefiPayloadEntry: Don't mutate the bootloader memory > map > UefiPayloadPkg: Add a shared ACPI table walk helper > UefiPayloadPkg/UefiPayloadEntry: Locate the payload FV via ExtraData > UefiPayloadPkg/UefiPayloadEntry: Optionally publish MCFG as Reserved > UefiPayloadPkg/UefiPayloadEntry: Let a bootloader flag MMIO ranges > UefiPayloadPkg: Add CHAINLOAD_DEFAULTS build option > UefiPayloadPkg: Force full INIT-SIPI-SIPI under CHAINLOAD_DEFAULTS > UefiPayloadPkg: Add VIRTIO_ENABLE build option for X64 > UefiPayloadPkg/ChainloadApp: Add embedded-FV launcher skeleton (X64) > UefiPayloadPkg/ChainloadApp: Derive the serial HOB from the ACPI SPCR > UefiPayloadPkg/ChainloadApp: Re-enable SPCR PCI serial decode after > EBS > UefiPayloadPkg/ChainloadApp: Program unassigned BARs before handoff > UefiPayloadPkg/ChainloadApp: Add a Reserved-pages MemoryAllocationLib > UefiPayloadPkg/ChainloadApp: Publish launcher allocations as boot-time > UefiPayloadPkg/ChainloadApp: Reclaim outer runtime services memory > UefiPayloadPkg: Enable legacy payload entry on AArch64 > UefiPayloadPkg/ChainloadApp: Own the AArch64 translation tables > UefiPayloadPkg/ChainloadApp: Add embedded-payload build scripts and > README > > ArmPkg/Drivers/ArmGicDxe/GicV3/ArmGicV3Dxe.c | 46 +- > .../PL031RealTimeClockLib.c | 66 +- > UefiPayloadPkg/BuildChainloadEmbedded.sh | 125 + > .../ChainloadApp/AArch64/PayloadEntry.S | 32 + > UefiPayloadPkg/ChainloadApp/ChainloadApp.c | 2288 +++++++++++++++++ > UefiPayloadPkg/ChainloadApp/ChainloadApp.inf | 77 + > .../ChainloadApp/EmbeddedPayloadStub.h | 20 + > UefiPayloadPkg/ChainloadApp/GenPayloadHdr.py | 61 + > UefiPayloadPkg/ChainloadApp/PciBarFixup.c | 818 ++++++ > UefiPayloadPkg/ChainloadApp/README.md | 116 + > .../ReservedUefiMemoryAllocationLib.c | 191 ++ > .../ReservedUefiMemoryAllocationLib.inf | 32 + > .../ChainloadApp/X64/PayloadEntry.nasm | 37 + > .../Include/Guid/BootTimeReservationGuid.h | 53 + > .../Include/Guid/MemoryMapInfoGuid.h | 11 + > .../Include/Library/AcpiTableWalkLib.h | 43 + > .../Library/AcpiGicPcdLib/AcpiGicPcdLib.c | 664 +++++ > .../Library/AcpiGicPcdLib/AcpiGicPcdLib.inf | 50 + > .../AcpiTableWalkLib/AcpiTableWalkLib.c | 169 ++ > .../AcpiTableWalkLib/AcpiTableWalkLib.inf | 29 + > .../DxeBaseSerialPortLibHob.c | 41 +- > .../DxeBaseSerialPortLibHob.inf | 1 + > .../Library/ResetSystemLib/ResetSystemLib.c | 5 +- > .../Library/SblParseLib/SblParseLib.c | 2 +- > .../UefiPayloadEntry/AArch64/DxeHandoff.c | 398 ++- > UefiPayloadPkg/UefiPayloadEntry/AcpiTable.c | 137 +- > .../FitUniversalPayloadEntry.inf | 1 + > UefiPayloadPkg/UefiPayloadEntry/LoadDxeCore.c | 13 +- > .../UefiPayloadEntry/UefiPayloadEntry.c | 481 +++- > .../UefiPayloadEntry/UefiPayloadEntry.h | 7 +- > .../UefiPayloadEntry/UefiPayloadEntry.inf | 11 +- > .../UniversalPayloadEntry.inf | 1 + > UefiPayloadPkg/UefiPayloadPkg.dec | 23 + > UefiPayloadPkg/UefiPayloadPkg.dsc | 128 +- > UefiPayloadPkg/UefiPayloadPkg.fdf | 22 + > 35 files changed, 6067 insertions(+), 132 deletions(-) > create mode 100755 UefiPayloadPkg/BuildChainloadEmbedded.sh > create mode 100644 UefiPayloadPkg/ChainloadApp/AArch64/PayloadEntry.S > create mode 100644 UefiPayloadPkg/ChainloadApp/ChainloadApp.c > create mode 100644 UefiPayloadPkg/ChainloadApp/ChainloadApp.inf > create mode 100644 UefiPayloadPkg/ChainloadApp/EmbeddedPayloadStub.h > create mode 100644 UefiPayloadPkg/ChainloadApp/GenPayloadHdr.py > create mode 100644 UefiPayloadPkg/ChainloadApp/PciBarFixup.c > create mode 100644 UefiPayloadPkg/ChainloadApp/README.md > create mode 100644 > UefiPayloadPkg/ChainloadApp/ReservedUefiMemoryAllocationLib.c > create mode 100644 > UefiPayloadPkg/ChainloadApp/ReservedUefiMemoryAllocationLib.inf > create mode 100644 UefiPayloadPkg/ChainloadApp/X64/PayloadEntry.nasm > create mode 100644 UefiPayloadPkg/Include/Guid/BootTimeReservationGuid.h > create mode 100644 UefiPayloadPkg/Include/Library/AcpiTableWalkLib.h > create mode 100644 UefiPayloadPkg/Library/AcpiGicPcdLib/AcpiGicPcdLib.c > create mode 100644 UefiPayloadPkg/Library/AcpiGicPcdLib/AcpiGicPcdLib.inf > create mode 100644 > UefiPayloadPkg/Library/AcpiTableWalkLib/AcpiTableWalkLib.c > create mode 100644 > UefiPayloadPkg/Library/AcpiTableWalkLib/AcpiTableWalkLib.inf > > -- > 2.47.3 > > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#122106): https://edk2.groups.io/g/devel/message/122106 Mute This Topic: https://groups.io/mt/120797177/21656 Group Owner: [email protected] Unsubscribe: https://edk2.groups.io/g/devel/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
