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

[Landge, Sudan]

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.