rust-hypervisor-firmware icon indicating copy to clipboard operation
rust-hypervisor-firmware copied to clipboard

Support building as flat BIOS image

Open josephlr opened this issue 5 years ago • 2 comments

Right now the firmware is built into a normal ELF binary, and then booted using Firecracker. However, it would be nice if were possible to build the firmware into a flat BIOS binary that can be directly executed by the processor on reset.

Specifically, the firmware would be loaded at Guest Physical Address 4 GiB - sizeof(binary) and then execution would begin at the standard x86 reset vector 0xFFFFFFF0 in Real Mode. This is what SeaBIOS's bios.bin and EDK2's OVMF_CODE.fd/OVMF_VARS.fd builds do.

This would then allow for the binary to be used with any VMM that uses the normal BIOS loading process. This means automatic support for QEMU and XEN. Specifically, using QEMU would then be possible with:

qemu-system-x86_64  -drive if=pflash,format=raw,readonly,file=hypervisor-fw

Design Ideas

I would be happy to start exploring this. My idea of the execution flow would be:

  1. One instruction at the reset vector: jump to code in (2)
  2. Assembly code that: b) Deals with A20 c) Sets up stub IDT/GDT/Paging d) Switches to long mode e) Jump to _start (i.e. the normal ELF entry point)
  3. Our normal Rust entry point: _start.

This could be done by having two similar target.json files, that only differed in refering to different layout.ld files. The layout.fd file for our flat BIOS build, would just have to make sure that the code for (1) was properly aligned and at the end of the file. This also means that our flat BIOS build would still be an ELF file, which has its advantages.

josephlr avatar May 12 '19 09:05 josephlr

Hi Joseph your approach seems pretty reasonable and well thought out.

rbradford avatar May 13 '19 17:05 rbradford

Is there any progress on this? I'm potentially interested in using this with either the aforementioned -drive, or -bios.

bwidawsk avatar Sep 05 '19 23:09 bwidawsk