New Component: hypervisor-firmware

rbradford commented 5 years ago

Name

hypervisor-firmware

Purpose

This component is an ELF binary (compatible with the vmlinux loading convention used by the linux-loader crate) that can load a guest operating system from the guest image without host involvement. This allows control of the kernel that is booted to be under the control of the customer.

Currently it supports loading a bzImage, initrd & commandline from the EFI system partition using a custom naming convention. e.g. \EFI\LINUX\{BZIMAGE, INITRD, CMDLINE}

In the future the goal is to support loading an EFI application e.g. \EFI\BOOT\BOOTX64.EFI which could be grub or another EFI capable bootloader which would then load the operating system itself.

Implementation details

Dependencies:

Rust core (unable to use std as we have no OS)
cpuio crate for Port I/O
r-efi crate for EFI structs (FUTURE)

The "firmware" contains a basic implementation of a virtio block driver (MMIO only currently, PCI soon), a FAT filesystem implementation and a bzImage loader. In the future it will include a PE32+ loader and a basic EFI compatibility environment (enough to run GRUB.)

Notes

We have this component already developed and working and would like to contribute it to the rust-vmm project. It is currently proceeding through our internal Open Source reviewing process and one of those required steps is to confirm the name.

rn commented 5 years ago

This looks like quite a chunky component. Is the intention to eventually break this up? For example, there is a proposed linux-loader component which seems to have some overlap with the bzImage loader you mention. Also a FAT32 filesystem implementation might be a useful separate component.

bjzhjing commented 5 years ago

@rbradford I'm currently working on linux-loader for bzImage, but from the above description, it seems that the hypervisor-firmware covers the loader work for bzImage, is linux-loader still in need?

rn commented 5 years ago

I think we need a standalone loader, not all VMs will boot via the firmware method. Ideally hypervisor-firmware would re-use linux-loader for bzImage once available.

jiangliu commented 5 years ago

Hypervisor-firmware seems a little heavy, split it into smaller crates would be preferred:) But we do expect a loader with capability to parse kernel sections other than parsing the program headers.

On Feb 28, 2019, at 5:31 PM, Rolf Neugebauer <notifications@github.com mailto:notifications@github.com> wrote:

I think we need a standalone loader, not all VMs will boot via the firmware method. Ideally hypervisor-firmware would re-use linux-loader for bzImage once available.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/rust-vmm/community/issues/29#issuecomment-468201926, or mute the thread https://github.com/notifications/unsubscribe-auth/AB14_NEvyqigNSbKGYYimVmrgLL12QcOks5vR6H3gaJpZM4bUXEt.

rbradford commented 5 years ago

@rbradford I'm currently working on linux-loader for bzImage, but from the above description, it seems that the hypervisor-firmware covers the loader work for bzImage, is linux-loader still in need?

It's not the same thing. The linux-loader crate is for loading the kernel fully under the control of the host, for .e.g. the container use-case where the customer does not get full control of their operating system. This component is instead loaded by the linux-loader and then running within the KVM environment can then load the guest kernel. This allows for use-cases that are more traditional VM focused without then need to port an existing firmware such as OVMF or Seabios.

rbradford commented 5 years ago

I think we need a standalone loader, not all VMs will boot via the firmware method. Ideally hypervisor-firmware would re-use linux-loader for bzImage once available.

The challenge with this proposed reuse is the environment they run in is very different. Running from within the guest means there is no std and the code is very tailored to the environment (own filesystem implementation, etc)

Of course once the code is published maybe we see ways to reuse/split the code.

rn commented 5 years ago

@rbradford thanks for clarifying, I think I've misunderstood how this component would be used.

yangzhon commented 5 years ago

@rbradford @sameo

Do you have plan to implement patching ACPI table in this firmware ? Since we need support ACPI crates and send those ACPI tables to guest kernel. If your firmware does not handle this, we need implement patching ACPI table in VMM side. thanks!

bonzini commented 5 years ago

Any reason not to use uBoot for this instead? It already supports a minimal UEFI runtime, and can be loaded directly from the reset vector.

rbradford commented 5 years ago

@bonzini I'm sure it would be possible to make u-boot work. And the UEFI runtime code there is indeed very mature. The motivation for doing it this way is:

Have something that is directly compatible with the existing ELF kernel loader with the binary started in long mode.
Demonstrate that it is possible to build a firmware in languages other than C, and getting benefits from a "safe" language like Rust.

To be clear i'm not proposing that this is the exclusive solution for firmware in this project, merely proposing that it be hosted here.

bonzini commented 5 years ago

I'm still not sure why this firmware would be a rust-vmm component, it seems pretty closely tied to the design of intel/cloud-hypervisor.

rust-vmm / community