Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support building as flat BIOS image #5

Open
josephlr opened this issue May 12, 2019 · 2 comments · May be fixed by #24
Open

Support building as flat BIOS image #5

josephlr opened this issue May 12, 2019 · 2 comments · May be fixed by #24

Comments

@josephlr
Copy link
Contributor

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.

@rbradford
Copy link
Member

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

@bwidawsk
Copy link

bwidawsk commented Sep 5, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants