I was expecting more terms like ACPI, GPT, partition IDs, maybe even device trees, but this just reads like someone who researched UEFI and BIOS for the first time. Not a lot of signal here.
> Unless you specifically ask for firmware with UEFI support, these often provide virtual machines with firmware that is truly BIOS firmware, with no UEFI features.
This is somewhat true, but also changing quite rapidly. I think RHEL 9 or 10 has/will drop BIOS booting entirely, both for physical machines and virtual hardware.
My main annoyance with UEFI / EDK2 / OVMF virtual firmware is it's just so much slower to boot, which makes it that much harder to do tiny single purpose appliances (like we use for libguestfs, confidential containers and other places).
creshal 18 hours ago [-]
I really wish support for direct kernel boot was more robust. It's there, but there's very little infrastructure support (to get the proper images in the first place, to mass replace them for updates, etc.) and you have to handroll everything to get it working, even in something like ovirt.
rwmj 17 hours ago [-]
I agree with this and we use direct kernel boot for libguestfs. The problem for confidential VMs / containers is the kernel must be inside the image and must be inaccessible to hypervisor (as that is the exact point of the thing), and direct kernel boot needs the kernel to be outside and accessible. The problem for oVirt and other management systems is that usually you want the kernel to be inside the VM so it gets updated when you update the VM, and again direct kernel boot means you've got to have a way to reach in and extract it (cough virt-get-kernel).
ajross 19 hours ago [-]
It's worth pointing out that EFI is an abstraction layer for hardware environments for the benefit (primarily[1]) of a bootloader and not an OS, which has vanishing value in a virtualization context. If you're going to boot a kernel into your VM, you know (or should know) exactly what the "hardware" is and how it's configured. Even real mode BIOS is more than you really need, but it's small and understood and there's little value to rocking the boat.
[1] OS use of EFI at runtime is poorly specified and glitchy. On x86 EFI doesn't even document how to set up page tables for it, so doing it robustly requires you walk and enumerate all the pages in use at boot and make sure nothing touches them again. I've seen calls that return with interrupts masked, calls that change UART registers unexpectedly, etc...
rwmj 17 hours ago [-]
I agree with all that. But the point for OS vendors is we'd prefer to have to support just one firmware type (one less axis on the ol' test matrix), and since physical PC hardware has largely settled on UEFI, that's what virtual machines will use too.
thefz 14 hours ago [-]
Confusing for who? The difference between BIOS and EFI is dramatic
19 hours ago [-]
Rendered at 07:39:45 GMT+0000 (Coordinated Universal Time) with Vercel.
This is somewhat true, but also changing quite rapidly. I think RHEL 9 or 10 has/will drop BIOS booting entirely, both for physical machines and virtual hardware.
My main annoyance with UEFI / EDK2 / OVMF virtual firmware is it's just so much slower to boot, which makes it that much harder to do tiny single purpose appliances (like we use for libguestfs, confidential containers and other places).
[1] OS use of EFI at runtime is poorly specified and glitchy. On x86 EFI doesn't even document how to set up page tables for it, so doing it robustly requires you walk and enumerate all the pages in use at boot and make sure nothing touches them again. I've seen calls that return with interrupts masked, calls that change UART registers unexpectedly, etc...