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

Landge, Sudan
2024-03-22T16:39:22Z

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.