On 22/03/2024 14:27, David Woodhouse wrote:
On Fri, 2024-03-22 at 08:22 -0500, Rob Herring wrote:
What stops you from passing fw_cfg not to UEFI FW? BTW, no actual VM
name was used in your posting, but now suddenly it is a talk about QEMU.
(Forgot to address the second part of that last time. No specific VMM
was mentioned in the first place because this isn't VMM-specific)
QEMU is referenced to explain `vmgenid` which they are also using and
have more documentation on it. We mentioned the hypervisor we tested the
changes with in the cover letter which is
https://github.com/firecracker-microvm/firecracker but this change isn't
VMM specific.
That would be possible. But not ideal.
Why not ideal?
To rephrase the question, why is it fine for UEFI to read the vmgenid
from fw_cfg, but the kernel can't use the same mechanism?
Because fw_cfg an incestuous way to get data from the VMM into the BIOS
(both SeaBIOS and UEFI). It's the way we pass the ACPI tables and
things like that.
It *isn't* designed as a general-purpose way of doing device discovery
for use by various operating systems.
I'm also not sure Firecracker, which is the VMM Sudan is working on,
even *has* fw_cfg. Especially on ARM. If we're going to be forced to
add some complicated device with MMIO and DMA just to be able to
advertise the existence of a simple memory region, that's just as bad
as being forced to expose it as an emulated PCI device.
This is what DT is *for*.
The response
that you'd have to use UEFI to use fw_cfg makes no sense to me. The
only reason I can think of is just being lazy and wanting to have
minimal changes to some existing driver. It looks to me like you could
implement this entirely in userspace already with zero kernel or
binding changes. From a quick look, we already have a fw_cfg driver
exposing UUID (that's the same thing as vmgenid AIUI) to userspace,
and you can feed that back into the random pool.
I am concerned that we already have a mechanism and you want to add a
second way. When do we ever think that's a good idea? What happens
on the next piece of fw_cfg data? We add yet another binding?
No, because fw_cfg is a way for the VMM to give configuration
information to the firmware. There's a clue in the name. The firmware
then sets up ACPI tables or DT to pass information in a more coherent
and structured fashion to general-purpose operating systems.
And some VMMs *don't* use fw_cfg at all because for the minimal microvm
case it's overkill.
The hypervisor we work on
(https://github.com/firecracker-microvm/firecracker) does not have
fw_cfg, it loads kernel directly without the need for UEFI or any
intermediate firmware. It is, as said, an overkill to enable UEFI and
fw_cfg just to support `vmgenid` specially when there is an alternative
available which could keep things simple for the vmm and for the linux
driver.
