Question: Is there/Will there be support for UEFI SNP(Simple Network Protocol)?

[ghost]

Hi,
Thank you all the developers for this amazing project.

I would like to use this project to install VM on a hardware during its early development stage to test applications. And I wish to be able to boot the VM via the network.

Questions:

• Does the project support UEFI SNP(Simple Network Protocol) for booting via the network?
  Browsing through the code, it seems that it does not support the protocol, but I would just like to make sure.
  • If there is support or ongoing implementation, is there any way that I can contribute to it?
  • If there is no support for it but the project would like add support, can I fork and do a pull request?
  • Or might it be that the project does not intend to add support for UEFI SNP?

[rbradford]

No support for UEFI SNP at the moment but feel free to create a PR to add it.

[josephlr]

@Amir-Fikri if I understand your use-case correctly, you want to:

• Start a VM with only the firmware loaded (and connected to the network)
• Download an image/application via the network
• Reboot the VM into this new image

We needed something similar to this at work, but using the SNP turned out to not work very well (it was either very slow, lacked the correct driver support, or firmware vendors didn't consistently support it, like GCE). What we ended up doing was creating VMs containing only two things:

• The firmware
• A small EFI application that could talk over the network. This application (not the firmware) contains all the appropriate network drivers and image downloading logic.

Then this VM boots, executes the EFI application, downloads the image, and reboots into that downloaded image. This ended up being much faster and more reliable than using the firmware directly.

Part of the issue with implementing UEFI SNP is not the protocol itself, but all the networks drivers you would need to support (and make fast). Where if you use an EFI application you can use whatever existing drivers/logic you want, and it will work on any firmware implementation.

We used a stripped down Linux kernel + Initramfs, but you wouldn't have to do it that way. We also write out the image to disk and do a reboot. However, you could just write it into memory and exec from that.

Finally, one feature I would be interested in is a way to embed an EFI application in the firmware itself. EDK2 supports something like this. That way you could load a single blob onto your VMs and have them run an EFI app without even needing a disk for the VM.

[ghost]

@josephlr Thank you for your respond.

@amir Fikri if I understand your use-case correctly, you want to:

• Start a VM with only the firmware loaded (and connected to the network)
• Download an image/application via the network
• Reboot the VM into this new image

Yes, this is precisely what I want to do.
To explain further, below contains a more descriptive idea of what I am trying to achieve, along with some questions:

Objective

• To conveniently (quickly) do integrated test on network, UEFI HTTP Boot, iPXE, image retrieval, an application software
• To use cloud-hypervisor/rust-hypervisor-firmware(or other independent applications) in production stage

Reasons for wanting to try to use rust-hypervisor-firmware

• Used Vagrant + QEMU(libvirt) + EDK2 but because of the long time to boot up, it was difficult to do integrated tests conveniently
• Used Vagrant + QEMU(libvirt) + EDK2 but it was difficult to make small adjustments to the configuration
• (I think that) it is not possible to do a UEFI HTTP Boot test with Firecracker

Current situation

• I have tried to run the combination of cloud-hypervisor/rust-hypervisor-firmware/iPXE but a PANIC error occured
• I have not yet managed to create an EFI application using EDK2

Questions

I am thinking of using iPXE (https://github.com/ipxe/ipxe) as an EFI Network Bootloader. If possible, do you have any advice/tips regarding the following matters?

• Embedding iPXE using EDK2
• Creating an EFI application that supports UEFI HTTP Boot and supports virtio drivers, using EDK2

Appendix: Details of iPXE PANIC error

Summary of what I did

• Build iPXE
• Create disk image
• Boot cloud-hypervisr
• PANIC error occured

Build iPXE

$ git clone https://github.com/ipxe/ipxe.git
$ make -C ipxe/src -j $(nproc) bin-x86_64-efi/virtio-net.efi

Create disk image

$ git clone https://github.com/takumin/go-diskfs-playground.git
$ make -C go-diskfs-playground RUN_KERNEL=../ipxe/src/bin-x86_64-efi/virtio-net.efi
$ ls -la /tmp/disk.img
-rw-rw-r-- 1 takumi takumi 9437184 2020-01-14 23:48:01 /tmp/disk.img

Boot cloud-hypervisor

$ cloud-hypervisor --kernel /usr/local/share/hypervisor-fw/hypervisor-fw --disk path=/tmp/disk.img --rng --console off --serial tty

PANIC error occured

Cloud Hypervisor Guest
API server: /run/user/1000/cloud-hypervisor.22871
vCPUs: 1
Memory: 512 MB
Kernel: Some(KernelConfig { path: "/usr/local/share/hypervisor-fw/hypervisor-fw" })
Kernel cmdline:
Disk(s): Some([DiskConfig { path: "/tmp/disk.img", iommu: false }])
L
Starting..
Setting up 4 GiB identity mapping
Page tables setup
Found PCI device vendor=8086 device=d57 in slot=0
Found PCI device vendor=1af4 device=1042 in slot=1
Found PCI device vendor=1af4 device=1044 in slot=2
PCI Device: 0:1.0 1af4:1042
Bar: type=MemorySpace32 address=e7f80000
Bar: type=MemorySpace32 address=0
Bar: type=MemorySpace32 address=0
Bar: type=MemorySpace32 address=0
Bar: type=MemorySpace32 address=0
Bar: type=Unused address=0
Virtio block device configured. Capacity: 18432 sectors
Found EFI partition
Filesystem ready
PANIC: panicked at 'index 312 out of range for slice of length 260', /home/travis/.rustup/toolchains/nightly-2019-11-05-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/slice/mod.rs:2664:5
												```