coreboot support

[retrage]

This PR proposes "coreboot" feature for rust-hypervisor-firmware as a coreboot payload.
It adds coreboot::StartInfo that parses coreboot table[1] to provide e820 table and RSDP address. (This part may be able to reuse for PR #24)
It adds rust64_start for "coreboot" feature because the coreboot::StartInfo struct should be allocated and supplied before main.

Since coreboot payload starts from 32-bit protected mode, and it uses the ELF entry point, it must point ram32_start (230daa6).

To build:

      cargo build \
        --target target.json \
        -Zbuild-std=core \
        -Zbuild-std-features=compiler-builtins-mem
        --features "coreboot"

Build coreboot.rom with hypervisor-fw as a payload.

To run:

    qemu-system-x86_64
      -enable-kvm \
      -cpu host \
      -machine type=q35 \
      -drive if=pflash,format=raw,readonly,file=coreboot.rom \
      -drive id=disk,file=bionic-server-cloudimg-amd64-raw.img,if=none \
      -device virtio-blk-pci,drive=disk,disable-legacy=on \
      -nographic \
      -serial mon:stdio \
      -m 8G

I confirmed that it works on both Linux loader mode and EFI mode.

[1] https://www.coreboot.org/API

[retrage]

Does anyone have comments?

[rbradford]

This looks fine but I think it probably needs an integration test.

[retrage]

For integration tests, I would like to add a shell script like run_integration_tests.sh.

[retrage]

This looks fine but I think it probably needs an integration test.

I pushed integration tests for coreboot as b7e1ff9. It passes all integration tests.

[retrage]

The coreboot integration tests clone coreboot repository, checkout submodules, and build a binutils/gcc cross compiler every time. It's heavy and time-consuming process to just building a BIOS rom. I think we can improve this by providing pre-built packages for CI.

[rbradford]

@josephlr What do you think?

[retrage]

@josephlr Any updates?

[josephlr]

This looks reasonable to me, and we should be able to reuse some of this for #24.

I haven't had the chance to review this in extreme detail, but if it boots, we can merge this for now and clean it up later.

Long term, we will probably want to use some sort of CI caching (say w/ Github Actions) to speed stuff up.