Re: [PATCH v1 0/4] virt: vmgenid: Add devicetree bindings support

[David Woodhouse]

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)

> > 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.

Attachment: smime.p7s
Description: S/MIME cryptographic signature