virt: vmgenid: Add devicetree bindings support

From: Sudan Landge <[email protected]>

Rearrage the functions of vmgenid to make the next commit, which re-implements vmgenid as a platform driver, easier to review.

Signed-off-by Sudan Landge <[email protected]>

Quoted 2 lines · Babis Chalios

From: Sudan Landge <[email protected]>

Quoted 4 lines

Rearrage the functions of vmgenid to make the next commit, which re-implements vmgenid as a platform driver, easier to review.

Signed-off-by Sudan Landge <[email protected]>

You can't sign off on behalf of someone else. The SoB here needs to be yours. If you are taking over this code from Sudan, I'd suggest to take over full ownership of it and put your own name as author and SoB in all patches.

Alex

Quoted 10 lines · Alexander Graf

Quoted 6 lines · Babis Chalios

From: Sudan Landge <[email protected]>

Rearrage the functions of vmgenid to make the next commit, which re-implements vmgenid as a platform driver, easier to review.

Signed-off-by Sudan Landge <[email protected]>

Quoted 2 lines

You can't sign off on behalf of someone else. The SoB here needs to be yours. If you are taking over this code from Sudan, I'd suggest to take over full ownership of it and put your own name as author and SoB in all patches.

I thought about it and it seemed weird to me that I take over SoB and authorship since I only touched one line in one of the patches, but I will be taking over the patches, so I can do that if that's the way we things are done.

Does it make sense to at least add "Co-authored-by Sudan Landge <[email protected]>" here?

Quoted 7 lines · Alexander Graf

Quoted 5 lines · Babis Chalios

From: Sudan Landge <[email protected]>

Rearrage the functions of vmgenid to make the next commit, which re-implements vmgenid as a platform driver, easier to review.

Quoted 8 lines

Quoted 1 line

Signed-off-by Sudan Landge <[email protected]>

You can't sign off on behalf of someone else. The SoB here needs to be yours. If you are taking over this code from Sudan, I'd suggest to take over full ownership of it and put your own name as author and SoB in all patches.

I thought about it and it seemed weird to me that I take over SoB and authorship since I only touched one line in one of
the patches, but I will be taking over the patches, so I can do that if that's the way we things are done.

Does it make sense to at least add "Co-authored-by Sudan Landge <[email protected]>" here?

Quoted 24 lines · Babis Chalios

Quoted 7 lines · Alexander Graf

Quoted 5 lines · Babis Chalios

From: Sudan Landge <[email protected]>

Rearrage the functions of vmgenid to make the next commit, which re-implements vmgenid as a platform driver, easier to review.

Quoted 8 lines

Quoted 1 line

Signed-off-by Sudan Landge <[email protected]>

You can't sign off on behalf of someone else. The SoB here needs to be yours. If you are taking over this code from Sudan, I'd suggest to take over full ownership of it and put your own name as author and SoB in all patches.

I thought about it and it seemed weird to me that I take over SoB and authorship since I only touched one line in one of
the patches, but I will be taking over the patches, so I can do that if that's the way we things are done.

Quoted 2 lines

Does it make sense to at least add "Co-authored-by Sudan Landge <[email protected]>" here?

Wait, what? No. If you didn't write these patches, you're not the author. Sudan is the author. However, if they passed through you, it's fine to add your S-o-b. You can even mention the trivial change you made between Sudan's S-o-b and your own.

From: Sudan Landge <[email protected]>

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

Signed-off-by Sudan Landge <[email protected]>

From: Sudan Landge <[email protected]>

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.

From: Sudan Landge <[email protected]>

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

Signed-off-by Sudan Landge <[email protected]>

From: Sudan Landge <[email protected]>

Extend the vmgenid platform driver to support devicetree bindings. With this support, hypervisors can send vmgenid notifications to the virtual machine without the need to enable ACPI. The bindings are located at:
Documentation/devicetree/bindings/rng/microsoft,vmgenid.yaml

Signed-off-by Sudan Landge <[email protected]>

---
 drivers/virt/vmgenid.c | 53 ++++++++++++++++++++++++++++++++++++++++--
 1 file changed, 51 insertions(+), 2 deletions(-)

This small series of patches aims to add devicetree bindings support for the Virtual Machine Generation ID (vmgenid).

Virtual Machine Generation ID 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.

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

*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 chosen 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.

Addtional notes:
While adding the devicetree support we considered re-using existing structures/code to avoid duplicating code and reduce maintenance; so, we used the same driver to be configured either by ACPI or by DT. This also meant reimplementing the existing vmgenid ACPI bus driver as a platform driver and making it discoverable using driver.of_match_table and driver.acpi_match_table.

There is no user impact or change in vmgenid functionality when used with ACPI. We verified ACPI support of these patches on X86 and DT support on ARM using Firecracker hypervisor
https://github.com/firecracker-microvm/firecracker.

To check schema and syntax errors, the bindings file is verified with:

```
   make dt_binding_check \
   DT_SCHEMA_FILES=\
   Documentation/devicetree/bindings/rng/microsoft,vmgenid.yaml
```

and the patches were verified with:
scripts/checkpatch.pl --strict v5-000*.

Changelog with respect to version 4:
- Removed __maybe_unused attribute from vmgenid_of_irq_handler since it is always compiled in (used by vmgenid_add_of).

Changelog with respect to version 3:
- Changed the compatible string from "virtual,vmgenctr" to "microsoft,vmgenid" as per review comments.
- Renamed vmgenid.yaml to follow DT file naming convention.
- Updated the description of properties and example in vmgenid yaml file.
- Addressed the review comments to remove all ifdefs in vmgenid.c with one exception which still needs to be under CONFIG_ACPI.
- reformated the code with clang-format.
- Tested code with W=1, Sparse, Smatch and Coccinelle tools.

Changelog with respect to version 2:
- As per review comments, used platform apis instead of "of_*" APIs, removed unnecessary #include and used IF_ENABLED instead of ifdef.
- Added more info for vmgenid buffer address and corrected the formatting.
- Replaced the compatible string from "linux,*" to "virtual,*" because, the device does not have a vendor.

Changelog with respect to version 1:
- Moved vmgenid.yaml bindings to the more related "rng" folder.
- Removed vmgenid_remove to since it is unrelated to the current goal of the patch.
- Updated the cover letter and bindings commit "[PATCH v2 3/4] dt-bindings: rng: Add vmgenid support" to provide more information on vmgenid.
- Compiled with and without CONFIG_OF/CONFIG_ACPI and fixed compilers errors/warnings.

Sudan Landge (5):
virt: vmgenid: rearrange code to make review easier
virt: vmgenid: change implementation to use a platform driver
virt: vmgenid: enable driver regardless of ACPI config
dt-bindings: rng: Add vmgenid support
virt: vmgenid: add support for devicetree bindings

  .../bindings/rng/microsoft,vmgenid.yaml       |  49 +++++
  MAINTAINERS                                   |   1 +
  drivers/virt/Kconfig                          |   1 -
  drivers/virt/vmgenid.c                        | 168 ++++++++++++++----
  4 files changed, 180 insertions(+), 39 deletions(-)

create mode 100644 Documentation/devicetree/bindings/rng/microsoft,vmgenid.yaml