Fix fw write for ExternalKernel payload on aarch64

[ericcurtin]

When using the efi feature on aarch64 with ExternalKernel payload (direct kernel boot), the code incorrectly tried to write EFI firmware to guest memory address 0, which wasn't mapped.

ExternalKernel payload calls arch_memory_regions with firmware_size=None, so no memory region is allocated for firmware. However, with the efi feature enabled, firmware_data is always Some(EDK2_BINARY), causing the write to fail with FirmwareInvalidAddress(InvalidGuestAddress(0)).

Skip firmware writing for ExternalKernel payload since direct kernel boot doesn't use EFI firmware.

[ericcurtin]

@slp @mtjhrc PTAL

[slp]

While I've been tempted to simply state the EFI flavor (which we intend to deprectate) doesn't support external kernels, this change doesn't hurt and fixes this particular use case, so let's get it in. Thanks @ericcurtin !

[ericcurtin]

"which we intend to deprectate" this is useful info thanks. I eventually started using normal grub2 instead of using external kernels.

[slp]

"which we intend to deprectate" this is useful info thanks. I eventually started using normal grub2 instead of using external kernels.

To be clear, we intend to deprecate the "EFI" flavor, not the ability to load an EFI firmware (or any other firmware). The EFI flavor was simply kind of a shortcut that automatically loads a bundled EFI firmware. Without the EFI flavor, users need carry their own firmware (they can simply pick up the binary from this repo) and configure it using krun_set_firmware.

We've already changed krunkit to do this containers/krunkit#86

The main reason is that having both libkrun and libkrun-efi on macOS was both confusing a maintenance burden. With this transition, we have switched back to a single homebrew tap.

[ericcurtin]

"which we intend to deprectate" this is useful info thanks. I eventually started using normal grub2 instead of using external kernels.

To be clear, we intend to deprecate the "EFI" flavor, not the ability to load an EFI firmware (or any other firmware). The EFI flavor was simply kind of a shortcut that automatically loads a bundled EFI firmware. Without the EFI flavor, users need carry their own firmware (they can simply pick up the binary from this repo) and configure it using krun_set_firmware.

We've already changed krunkit to do this containers/krunkit#86

The main reason is that having both libkrun and libkrun-efi on macOS was both confusing a maintenance burden. With this transition, we have switched back to a single homebrew tap.

I'll move to the same technique as krunkit to help with maintenance, fwiw this is the thing that is using libkrun in this way:

https://github.com/ericcurtin/vmm

[slp]

"which we intend to deprectate" this is useful info thanks. I eventually started using normal grub2 instead of using external kernels.

To be clear, we intend to deprecate the "EFI" flavor, not the ability to load an EFI firmware (or any other firmware). The EFI flavor was simply kind of a shortcut that automatically loads a bundled EFI firmware. Without the EFI flavor, users need carry their own firmware (they can simply pick up the binary from this repo) and configure it using krun_set_firmware.
We've already changed krunkit to do this containers/krunkit#86
The main reason is that having both libkrun and libkrun-efi on macOS was both confusing a maintenance burden. With this transition, we have switched back to a single homebrew tap.

I'll move to the same technique as krunkit to help with maintenance, fwiw this is the thing that is using libkrun in this way:

https://github.com/ericcurtin/vmm

Cool! Looks like krunvm but following much closely the container semantics, neat.