In 2017 at ELCE in Prague I saw an interesting talk by Alexander Graf (QEMU & KVM developer at SuSE) which was about putting the Qemu tiny-code-generator into E

In 2017 at ELCE in Prague I saw an interesting talk by Alexander Graf (QEMU & KVM developer at SuSE) which was about putting the Qemu tiny-code-generator into EDK2 (UEFI reference implementation) to run x86_64 option ROM blobs on ARM64 servers[1]. The main idea as I understood/remember it was roughly this: UEFI offers an abstract hardware interface to the OS, but to actually talk to the hardware it also needs drivers. To solve this issue, UEFI defines a driver interface and loads driver blobs directly from a ROM on the device itself. However, if you plug an off-the-shelf PCI card into an ARM server, this doesn't work, because the driver blob is x86 code. For Linux this doesn't matter, since it has its own drivers, but e.g. Grub doesn't and if the PCI device in question is a graphics card, you are flying blind until the kernel is up. So they patched their version of EDK2 to map the option ROM blobs as not-executable and when UEFI/the bootloader tries to call into the option ROM blob, the page fault handler they installed traps that, extracts the call arguments and runs the blob through TCG. They use the same trick to catch calls from the ROM blob back into their ARM UEFI binary, extract the arguments again, do the call, convert the return values and jump back. It sounds like a crazy hack, but apparently worked well enough that they could plug an Nvidia card into an ARM server and it would display the Grub boot splash screen and early printk messages. [1] https://osseu17.sched.com/event/ByIv/qemu-in-uefi-alexander-graf-suse https://osseu17.sched.com/event/ByIv/qemu-in-uefi-alexander-...