Support more VMMs (QEMU, crosvm, XEN)

[josephlr]

Right now it's not possible to run the firmware with any non-Firecracker VMM. Ideally we would support a wide range of VMMs. There are many small changes that would fix this:

• In the ELF binary, advertise support for a common boot specification. This would allow any VMM supporting that spec to run the firmware. Our options are:

  • Mutliboot/Multiboot2: this is an older FSF common boot standard. It would also let us work with QEMU's -kernel option (might also work with Xen).
  • PVH direct boot: This standard started with XEN, but support was added to QEMU recently. To use this, we just need to advertise XEN_ELFNOTE_PHYS32_ENTRY as an ELFNOTE. Not supporting PVH is why running QEMU with -kernel does not work:

    > qemu-system-x86_64 -kernel target/target/release/hypervisor-fw   
    qemu-system-x86_64: Error loading uncompressed kernel without PVH ELF Note
    
  • Note that both of these specs would (probably) require a separate 32-bit entry point. The firmware would then need to setup paging before jumping to the normal 64-bit ELF entry point (i.e. _start).

• Issue Support building as flat BIOS image #5: support building the firmware as a flat BIOS binary (like OVMF.fd), allowing it to be directly loaded/executed by any VMM that supports SeaBIOS/OVMF.

Implementing either of these would let the firmware work on QEMU. I'm not sure about how to get it working for crosvm (it should "just work" with any ELF binary). I can ask around at work Monday to see what the deal is.

[rbradford]

PVH would be my strongest preference as I think it will require the least code to program the appropriate state. That being said patches will be accepted for all options.

Note that both of these specs would (probably) require a separate 32-bit entry point. The firmware would then need to setup paging before jumping to the normal 64-bit ELF entry point (i.e. _start).

Sounds fine.

I'm not sure about how to get it working for crosvm (it should "just work" with any ELF binary). I can ask around at work Monday to see what the deal is.

Last time I looked it had a hardcoded jump into 0x200 + text segment (for the Linux kernel setup64 entry point)