Re: [PATCH v6 4/5] dt-bindings: rng: Add vmgenid support

[Babis Chalios]

On 4/17/24 14:09, Krzysztof Kozlowski wrote:
> On 17/04/2024 12:40, Babis Chalios wrote:
> > 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.
> >
> > VMGenID specification http://go.microsoft.com/fwlink/?LinkId=260709 defines
> > a mechanism for the BIOS/hypervisors to communicate to the virtual machine
> > that it is executed with a different configuration (e.g. snapshot execution
> > or creation from a template).
> > The guest operating system can use the notification for various purposes
> > such as re-initializing its random number generator etc.
> >
> > As per the specs, hypervisor should provide a globally unique identified,
> > or GUID via ACPI.
> >
> > This patch tries to mimic the mechanism to provide the same functionality
> > which is for a hypervisor/BIOS to notify the virtual machine when it is
> > executed with a different configuration.
> >
> > As part of this support the devicetree bindings requires the hypervisors or
> > BIOS to provide a memory address which holds the GUID and an IRQ which is
> > used to notify when there is a change in the GUID.
> > The memory exposed in the DT should follow the rules defined in the
> > vmgenid spec mentioned above.
> >
> > *Reason for this change*:
> > Chosing ACPI or devicetree is an intrinsic part of an hypervisor design.
> > Without going into details of why a hypervisor would chose DT over ACPI,
> > we would like to highlight that the hypervisors that have chose devicetree
> > and now want to make use of the vmgenid functionality cannot do so today
> > because vmgenid is an ACPI only device.
> > This forces these hypervisors to change their design which could have
> > undesirable impacts on their use-cases, test-scenarios etc.
> >
> > The point of vmgenid is to provide a mechanism to discover a GUID when
> > the execution state of a virtual machine changes and the simplest
> > way to do it is pass a memory location and an interrupt via devicetree.
> > It would complicate things unnecessarily if instead of using devicetree,
> > we try to implement a new protocol or modify other protocols to somehow
> > provide the same functionility.
> >
> > We believe that adding a devicetree binding for vmgenid is a simpler,
> > better alternative to provide the same functionality and will allow
> > such hypervisors as mentioned above to continue using devicetree.
> >
> > More references to vmgenid specs:
> >   - https://www.qemu.org/docs/master/specs/vmgenid.html
> >   - https://learn.microsoft.com/en-us/windows/win32/hyperv_v2/virtual-
> > machine-generation-identifier
> >
> > Co-authored-by: Sudan Landge <sudanl@xxxxxxxxxx>
> > Signed-off-by: Babis Chalios <bchalios@xxxxxxxxx>
> What happened here?
>
> NAK
>
> You are no the author of this patch. You changed here nothing and you
> took authorship?
>
> Read carefully submitting patches, this is not acceptable.
Hi Krzysztof,

Thanks for your review and your comments (both here and at the thread in
the previous version). I will read again the documentation for DCO on 
submitting
patches.

In the meantime, I followed the suggestion of Alex in the discussion of the
previous thread and had already sent v6 before receiving yours and Jason's
responses. In my defense, I didn't want to plagiarize Sudan here. It 
just seemed
from the discussion in the previous version that this is the standard 
practice
when someone is taking over the submission of a patch-set.

I will re-create the patches with correct authorship, my SoB and the 
Reviewed-by
tags I had received in previous versions and send a v7.

Cheers,
Babis


> Best regards,
> Krzysztof