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
