Received-SPF: pass (google.com: domain of linux-crypto+bounces-3625-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Subject: Re: [PATCH v6 4/5] dt-bindings: rng: Add vmgenid support
Message-ID: <433a026a-352c-48c1-84cf-e538bb30aad7@amazon.es>
Date: Wed, 17 Apr 2024 15:18:58 +0000
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: Krzysztof Kozlowski <krzk@kernel.org>, <tytso@mit.edu>, <Jason@zx2c4.com>,
	<olivia@selenic.com>, <herbert@gondor.apana.org.au>, <robh@kernel.org>,
	<krzk+dt@kernel.org>, <conor+dt@kernel.org>, <linux-crypto@vger.kernel.org>,
	<devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>
CC: <sudanl@amazon.com>, <graf@amazon.de>, <xmarcalx@amazon.co.uk>,
	<dwmw@amazon.co.uk>, Alexander Graf <graf@amazon.com>
References: <20240417104046.27253-1-bchalios@amazon.es>
 <20240417104046.27253-5-bchalios@amazon.es>
 <a9f1d643-f171-4b41-88c5-bd9bae0f8200@kernel.org>
Content-Language: en-US
From: Babis Chalios <bchalios@amazon.es>
In-Reply-To: <a9f1d643-f171-4b41-88c5-bd9bae0f8200@kernel.org>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit

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
>