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

[Landge, Sudan]

On 21/03/2024 13:32, Rob Herring wrote:
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
>
>
>
> On Wed, Mar 20, 2024 at 04:55:45PM +0000, David Woodhouse wrote:
> > On Wed, 2024-03-20 at 11:15 -0500, Rob Herring wrote:
> > > On Wed, Mar 20, 2024 at 01:50:43PM +0000, David Woodhouse wrote:
> > > > On Tue, 2024-03-19 at 16:24 +0100, Krzysztof Kozlowski wrote:
> > > > > On 19/03/2024 15:32, Sudan Landge wrote:
> > > > > > This small series of patches aims to add devicetree bindings support for
> > > > > > the Virtual Machine Generation ID (vmgenid) driver.
> > > > > >
> > > > > > Virtual Machine Generation ID driver was introduced in commit af6b54e2b5ba
> > > > > > ("virt: vmgenid: notify RNG of VM fork and supply generation ID") as an
> > > > > > ACPI only device.
> > > > > > We would like to extend vmgenid to support devicetree bindings because:
> > > > > > 1. A device should not be defined as an ACPI or DT only device.
> > >
> > > This (and the binding patch) tells me nothing about what "Virtual
> > > Machine Generation ID driver" is and isn't really justification for
> > > "why".
> >
> > It's a reference to a memory area which the OS can use to tell whether
> > it's been snapshotted and restored (or 'forked'). A future submission
> > should have a reference to something like
> > https://www.qemu.org/docs/master/specs/vmgenid.html or the Microsoft
> > doc which is linked from there.
>
> That doc mentions fw_cfg for which we already have a binding. Why can't
> it be used/extended here?
QEMU has support for vmgenid but even they do not pass vmgenid directly 
to the guest kernel using fw_cfg. QEMU passes the vmgenid/UUID via 
fw_cfg to an intermediate UEFI firmware. This UEFI firmware, running as 
a guest in QEMU, reads the UUID from fw_cfg and creates ACPI tables for 
it. The UEFI firmware then passes the UUID information to the guest 
kernel via ACPI.
This approach requires yet another intermediary which is UEFI firmware 
and adds more complexity than ACPI for minimalist hypervisors that do 
not have an intermediate bootloader today.

> Rob
>
> [1] https://www.kernel.org/doc/Documentation/devicetree/bindings/firmware/qemu%2Cfw-cfg-mmio.yaml