About

Multi-Architecture UEFI Environment Driver - UEFI driver that allows non-native UEFI boot service drivers and applications to be executed in 64-bit UEFI environments.

Derived from https://github.com/ardbiesheuvel/X86EmulatorPkg, but with host support for RISCV64 and AARCH64, and emulated environment support for X64 and AARCH64 (when built for RISCV64).

Project Scope and Timelines

MultiArchUefiPkg is considered code-complete and ready for business. Adoption is dependent on ongoing upstream activities for RISC-V MMU enablement patches for Tiano and additional partner validation/testing with silicon. but it's lacking third-party validation with real RISC-V silicon.

2H23 Scope.

Validation activities with at least two RISC-V semiconductor companies (V_AI_1 and V_AI_2), including potential bug fixes. The scope of these activities is still be defined, but aims at validating a few off-the-shelf NIC and graphics PCIe adapters with real RISC-V silicon.

V_AI_3 includes checking in a prebuilt RISC-V binary (RELEASE and DEBUG) into https://github.com/tianocore/edk2-non-osi. 

Also see U_AI_1 and U_AI_2 under section on upstreaming, which are information gathering activities to understand/motivate further upstreaming-related activities.

These are due end of 2H23.

2H24 Scope.

Depending on outcome of U_AI_1, U_AI_2 and feedback from V_AI_1 and V_AI_2 trials, this can include U_AI_3 and/or further TBD action items relating to transitioning project to Tiano or moving code to an existing Tiano repository. This also includes upstreaming activities for https://github.com/intel/unicorn-for-efi.

What about upstreaming?

"Upstreaming" refers to a notion of merging a feature from a forked branch into the the main branch of a project. MultiArchUefiPkg is a stand-alone UEFI driver that happens to be built in the Tiano environment and that happens to rely on a non-standard UEFI feature (today) only present in Tiano, yet there is no direct need for it to be merged into the main EDK2 tree. It's not a feature of an existing module. Additionally, even if MultiArchUefiPkg were to become a Tiano project, many Tiano projects are separate repositories, including the UEFI Shell,  FAT filesystem driver, and so on. It's certainly interesting to consider the the project becoming a Tiano project, and there is no philosophical objection to being part of the edk2 code base... In fact, this would help with certain code maintenance issues to avoid bit rot. But:

• MultiArchUefiPkg is derived from X86EmulatorPkg. While MultiUarchUefiPkg drops the Qemu TCG code, it inherits the LGPL v2.1 license. UEFI is BSD licensed and the repos haven't been taking LGPL code. U_AI_1: This code can be relicensed as long as Ard Biesheuvel and Alex Graf don't object.
• MultiArchUefiPkg depends on the Project Unicorn library, which is a mix of licenses including LGPL v2.1 and GPLv2.
  • U_AI_2: It's unclear if Tiano code can have module dependencies on non BSD-licensed code.
  • U_AI_3: an alternate implementation of the Unicorn APIs focused on MultiArchUefiPkg only is possible using the MIT-licensed https://github.com/ptitSeb/box64 DynaRec bits or similar. In fact, an alternate implementation may be highly desirable anyway due to re-entrancy issues in Unicorn, dealing with which today imposes some additional latency to running the non-native code.

U_AI_1 and U_AI_2 action items amount to information gathering and are a good target for remainder of Q3 and can help motivate U_AI_3. U_AI_3 represents a significant engineering investment that is seen as enhancing - not critical or essential to the functionality or adoption of MultiArchUefiPkg

Components and Repos

Stakeholders and Partners

StartFive is a non-RISE validation partner.

Dependencies

• RISC-V MMU enablement patches for Tiano
• For Qemu-based testing (not an identified priority) SE_01_005 (QEMU PCIe passthru on x86 hosts) is a priority.

Measure of Success

2H23 only,

Completed validation activities with (at least) two partners.

RISE Requirements

None (not accounting any of existing engineering investment against RISE resources).

Status

The table below is rolled up to the firmware WG status page - 2023-2H - Firmware Priorities.

25 Sept 2025 Overall update

• V_AI_1 - complete (tested by Ventana)
• V_AI_2 - complete (tested by StarFive)
• V_AI_3 - not started
• U_AI_1 - not started
• U_AI_2 - not started

Additionally, there has been independent validation on an Ampera Altra (AArch64) system.

19 Sept 2023 Move away from TPL manipulation

• EmulatorDxe only uses 1 level (HIGH, equivalent to disabling interrupts)
• Raising TPL gets in the way of using ConOut/ErrOut-based DebugLib (which internally may raise TPL to a level lower than HIGH), causing crashes on DEBUG statements and ASSERTs when TPL is high.
• TPL manipulation is more expensive than interrupt state manipulation
• UEFI is UP only, so this is clearly safe.

18 Sept 2023 Reduce RISCV binary size by half

Building with -Os takes us to 568k for a build that can emulate x64 bins, and 1.7m for a build that supports both x64 and aarch64. It turns out we have to build with -fno-omit-frame-pointer until the LongJumpInternal implementation is fixed (see andreiw/edk2-rv-wip@56871e7) ...building with frame pointer adds another 70k.

08 Jul 2023 Support for building with EMU_X64_RAZ_WI_PIO

If you run a DEBUG build of a UEFI implementation that uses the BaseIoLibIntrinsic (IoLibNoIo.c) implementation instead of a more advanced variant forwarding I/O accesses to PCIe, you may see UEFI assertions with emulated x64 drivers that attempt port I/O.

Building with EMU_X64_RAZ_WI_PIO=YES will ignore all port I/O writes and return zeroes for all port I/O reads.

14 Jun 2023 

Updated to build with GCC-12.

08 Jun 2023 

Presented at https://riscv-europe.org/conference.html. See https://github.com/intel/MultiArchUefiPkg/tree/main/Docs/RviSummitMarch2023.

24 May 2023 

Project reported to RISE board as active priority.

21 Mar 2023 

Project made public on Intel GitHub.