Received-SPF: pass (google.com: domain of linux-kernel+bounces-139292-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Date: Wed, 10 Apr 2024 15:09:32 -0500
From: Rob Herring <robh@kernel.org>
To: Sudan Landge <sudanl@amazon.com>
Cc: graf@amazon.de, tytso@mit.edu, krzysztof.kozlowski+dt@linaro.org,
	linux-kernel@vger.kernel.org, xmarcalx@amazon.co.uk,
	robh+dt@kernel.org, Jason@zx2c4.com, bchalios@amazon.es,
	thomas.lendacky@amd.com, dwmw@amazon.co.uk,
	devicetree@vger.kernel.org,
	sathyanarayanan.kuppuswamy@linux.intel.com, conor+dt@kernel.org,
	dan.j.williams@intel.com
Subject: Re: [PATCH v4 4/5] dt-bindings: rng: Add vmgenid support
Message-ID: <171277976994.1266656.4960056294355072441.robh@kernel.org>
References: <20240409181154.9962-1-sudanl@amazon.com>
 <20240409181154.9962-5-sudanl@amazon.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20240409181154.9962-5-sudanl@amazon.com>


On Tue, 09 Apr 2024 19:11:53 +0100, Sudan Landge 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 choose 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.
> 
> vmgenid exposes to the guest a 16-byte cryptographically random number,
> the value of which changes every time it starts executing from a new
> configuration (snapshot, backup, etc.). During initialization, the device
> exposes to the guest the address of the generation ID and
> an interrupt number, which the device will use to notify the guest when
> the generation ID changes.
> These attributes can be trivially communicated via device tree bindings.
> 
> We believe that adding a devicetree binding for vmgenid is a simpler
> alternative way to expose the device to the guest than forcing the
> hypervisors to implement ACPI.
> 
> 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
> 
> Signed-off-by: Sudan Landge <sudanl@amazon.com>
> ---
>  .../bindings/rng/microsoft,vmgenid.yaml       | 49 +++++++++++++++++++
>  MAINTAINERS                                   |  1 +
>  2 files changed, 50 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/rng/microsoft,vmgenid.yaml
> 

Reviewed-by: Rob Herring <robh@kernel.org>