Messages in this thread | | | Subject | Re: [PATCH v6 4/5] dt-bindings: rng: Add vmgenid support | Date | Wed, 17 Apr 2024 15:18:58 +0000 | From | 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@amazon.com> >> Signed-off-by: Babis Chalios <bchalios@amazon.es> > 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 >
| |