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 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.
Addtional notes:
While adding the devicetree support we considered re-using existing
structures/code to avoid duplication 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/vmgenid/vmgenid.yaml
```
and the patches were verified with:
`scripts/checkpatch.pl --strict v1-000*`.
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 (4):
virt: vmgenid: rearrange code to make review easier
virt: vmgenid: change implementation to use a platform driver
dt-bindings: rng: Add vmgenid support
virt: vmgenid: add support for devicetree bindings
.../devicetree/bindings/rng/vmgenid.yaml | 57 +++++
MAINTAINERS | 1 +
drivers/virt/Kconfig | 2 +-
drivers/virt/vmgenid.c | 215 +++++++++++++++---
4 files changed, 237 insertions(+), 38 deletions(-)
create mode 100644 Documentation/devicetree/bindings/rng/vmgenid.yaml
base-commit: a4145ce1e7bc247fd6f2846e8699473448717b37
--
2.40.1
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]>
---
drivers/virt/vmgenid.c | 28 ++++++++++++++--------------
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/virt/vmgenid.c b/drivers/virt/vmgenid.c
index b67a28da4702..ea956df02874 100644
--- a/drivers/virt/vmgenid.c
+++ b/drivers/virt/vmgenid.c
@@ -21,6 +21,20 @@ struct vmgenid_state {
u8 this_id[VMGENID_SIZE];
};
+static void vmgenid_notify(struct acpi_device *device, u32 event)
+{
+ struct vmgenid_state *state = acpi_driver_data(device);
+ char *envp[] = { "NEW_VMGENID=1", NULL };
+ u8 old_id[VMGENID_SIZE];
+
+ memcpy(old_id, state->this_id, sizeof(old_id));
+ memcpy(state->this_id, state->next_id, sizeof(state->this_id));
+ if (!memcmp(old_id, state->this_id, sizeof(old_id)))
+ return;
+ add_vmfork_randomness(state->this_id, sizeof(state->this_id));
+ kobject_uevent_env(&device->dev.kobj, KOBJ_CHANGE, envp);
+}
+
static int vmgenid_add(struct acpi_device *device)
{
struct acpi_buffer parsed = { ACPI_ALLOCATE_BUFFER };
@@ -65,20 +79,6 @@ static int vmgenid_add(struct acpi_device *device)
return ret;
}
-static void vmgenid_notify(struct acpi_device *device, u32 event)
-{
- struct vmgenid_state *state = acpi_driver_data(device);
- char *envp[] = { "NEW_VMGENID=1", NULL };
- u8 old_id[VMGENID_SIZE];
-
- memcpy(old_id, state->this_id, sizeof(old_id));
- memcpy(state->this_id, state->next_id, sizeof(state->this_id));
- if (!memcmp(old_id, state->this_id, sizeof(old_id)))
- return;
- add_vmfork_randomness(state->this_id, sizeof(state->this_id));
- kobject_uevent_env(&device->dev.kobj, KOBJ_CHANGE, envp);
-}
-
static const struct acpi_device_id vmgenid_ids[] = {
{ "VMGENCTR", 0 },
{ "VM_GEN_COUNTER", 0 },
--
2.40.1
Re-implement vmgenid as a platform driver in preparation
for adding devicetree bindings support in next commits.
Signed-off-by: Sudan Landge <[email protected]>
---
drivers/virt/vmgenid.c | 101 ++++++++++++++++++++++++++++++-----------
1 file changed, 74 insertions(+), 27 deletions(-)
diff --git a/drivers/virt/vmgenid.c b/drivers/virt/vmgenid.c
index ea956df02874..d5394c706bd9 100644
--- a/drivers/virt/vmgenid.c
+++ b/drivers/virt/vmgenid.c
@@ -11,6 +11,8 @@
#include <linux/module.h>
#include <linux/acpi.h>
#include <linux/random.h>
+#include <acpi/actypes.h>
+#include <linux/platform_device.h>
ACPI_MODULE_NAME("vmgenid");
@@ -21,9 +23,9 @@ struct vmgenid_state {
u8 this_id[VMGENID_SIZE];
};
-static void vmgenid_notify(struct acpi_device *device, u32 event)
+static void vmgenid_notify(struct device *device)
{
- struct vmgenid_state *state = acpi_driver_data(device);
+ struct vmgenid_state *state = device->driver_data;
char *envp[] = { "NEW_VMGENID=1", NULL };
u8 old_id[VMGENID_SIZE];
@@ -32,22 +34,34 @@ static void vmgenid_notify(struct acpi_device *device, u32 event)
if (!memcmp(old_id, state->this_id, sizeof(old_id)))
return;
add_vmfork_randomness(state->this_id, sizeof(state->this_id));
- kobject_uevent_env(&device->dev.kobj, KOBJ_CHANGE, envp);
+ kobject_uevent_env(&device->kobj, KOBJ_CHANGE, envp);
}
-static int vmgenid_add(struct acpi_device *device)
+static void vmgenid_acpi_handler(acpi_handle handle, u32 event, void *dev)
{
+ vmgenid_notify(dev);
+}
+
+static int setup_vmgenid_state(struct vmgenid_state *state, u8 *next_id)
+{
+ if (IS_ERR(next_id))
+ return PTR_ERR(next_id);
+
+ state->next_id = next_id;
+ memcpy(state->this_id, state->next_id, sizeof(state->this_id));
+ add_device_randomness(state->this_id, sizeof(state->this_id));
+ return 0;
+}
+
+static int vmgenid_add_acpi(struct device *dev, struct vmgenid_state *state)
+{
+ struct acpi_device *device = ACPI_COMPANION(dev);
struct acpi_buffer parsed = { ACPI_ALLOCATE_BUFFER };
- struct vmgenid_state *state;
union acpi_object *obj;
phys_addr_t phys_addr;
acpi_status status;
int ret = 0;
- state = devm_kmalloc(&device->dev, sizeof(*state), GFP_KERNEL);
- if (!state)
- return -ENOMEM;
-
status = acpi_evaluate_object(device->handle, "ADDR", NULL, &parsed);
if (ACPI_FAILURE(status)) {
ACPI_EXCEPTION((AE_INFO, status, "Evaluating ADDR"));
@@ -63,19 +77,42 @@ static int vmgenid_add(struct acpi_device *device)
phys_addr = (obj->package.elements[0].integer.value << 0) |
(obj->package.elements[1].integer.value << 32);
- state->next_id = devm_memremap(&device->dev, phys_addr, VMGENID_SIZE, MEMREMAP_WB);
- if (IS_ERR(state->next_id)) {
- ret = PTR_ERR(state->next_id);
+
+ ret = setup_vmgenid_state(state,
+ (u8 *)devm_memremap(&device->dev, phys_addr,
+ VMGENID_SIZE, MEMREMAP_WB));
+ if (ret)
+ goto out;
+
+ dev->driver_data = state;
+ status = acpi_install_notify_handler(device->handle, ACPI_DEVICE_NOTIFY,
+ vmgenid_acpi_handler, dev);
+ if (ACPI_FAILURE(status)) {
+ dev_err(dev, "Failed to install acpi notify handler");
+ ret = -ENODEV;
+ dev->driver_data = NULL;
goto out;
}
+out:
+ ACPI_FREE(parsed.pointer);
+ return ret;
+}
- memcpy(state->this_id, state->next_id, sizeof(state->this_id));
- add_device_randomness(state->this_id, sizeof(state->this_id));
+static int vmgenid_add(struct platform_device *pdev)
+{
+ struct vmgenid_state *state;
+ struct device *dev = &pdev->dev;
+ int ret = 0;
- device->driver_data = state;
+ state = devm_kmalloc(dev, sizeof(*state), GFP_KERNEL);
+ if (!state)
+ return -ENOMEM;
+
+ ret = vmgenid_add_acpi(dev, state);
+
+ if (ret)
+ devm_kfree(dev, state);
-out:
- ACPI_FREE(parsed.pointer);
return ret;
}
@@ -84,20 +121,30 @@ static const struct acpi_device_id vmgenid_ids[] = {
{ "VM_GEN_COUNTER", 0 },
{ }
};
+MODULE_DEVICE_TABLE(acpi, vmgenid_ids);
-static struct acpi_driver vmgenid_driver = {
- .name = "vmgenid",
- .ids = vmgenid_ids,
- .owner = THIS_MODULE,
- .ops = {
- .add = vmgenid_add,
- .notify = vmgenid_notify
- }
+static struct platform_driver vmgenid_plaform_driver = {
+ .probe = vmgenid_add,
+ .driver = {
+ .name = "vmgenid",
+ .acpi_match_table = ACPI_PTR(vmgenid_ids),
+ .owner = THIS_MODULE,
+ },
};
-module_acpi_driver(vmgenid_driver);
+static int vmgenid_platform_device_init(void)
+{
+ return platform_driver_register(&vmgenid_plaform_driver);
+}
+
+static void vmgenid_platform_device_exit(void)
+{
+ platform_driver_unregister(&vmgenid_plaform_driver);
+}
+
+module_init(vmgenid_platform_device_init)
+module_exit(vmgenid_platform_device_exit)
-MODULE_DEVICE_TABLE(acpi, vmgenid_ids);
MODULE_DESCRIPTION("Virtual Machine Generation ID");
MODULE_LICENSE("GPL v2");
MODULE_AUTHOR("Jason A. Donenfeld <[email protected]>");
--
2.40.1
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]>
---
.../devicetree/bindings/rng/vmgenid.yaml | 57 +++++++++++++++++++
MAINTAINERS | 1 +
2 files changed, 58 insertions(+)
create mode 100644 Documentation/devicetree/bindings/rng/vmgenid.yaml
diff --git a/Documentation/devicetree/bindings/rng/vmgenid.yaml b/Documentation/devicetree/bindings/rng/vmgenid.yaml
new file mode 100644
index 000000000000..4b6ab62cc2ae
--- /dev/null
+++ b/Documentation/devicetree/bindings/rng/vmgenid.yaml
@@ -0,0 +1,57 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/rng/vmgenid.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Virtual Machine Generation Counter ID device
+
+maintainers:
+ - Jason A. Donenfeld <[email protected]>
+
+description:
+ Firmwares or hypervisors can use this devicetree to describe
+ interrupts and the shared resources to inject a Virtual Machine Generation
+ counter.
+
+properties:
+ compatible:
+ const: linux,vmgenctr
+
+ "#interrupt-cells":
+ const: 3
+ description: |
+ The 1st cell is the interrupt type.
+ The 2nd cell contains the interrupt number for the interrupt type.
+ The 3rd cell is for trigger type and level flags.
+
+ interrupt-controller: true
+
+ reg:
+ description: |
+ specifies the base physical address and
+ size of the regions in memory which holds the VMGenID counter.
+ maxItems: 1
+
+ interrupts:
+ description: |
+ interrupt used to notify that a new VMGenID counter is available.
+ The interrupt should be Edge triggered.
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ rng@80000000 {
+ compatible = "linux,vmgenctr";
+ reg = <0x80000000 0x1000>;
+ interrupts = <0x00 0x23 0x01>;
+ };
+
+...
diff --git a/MAINTAINERS b/MAINTAINERS
index 43b39956694a..cf4b2e10fb49 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -18431,6 +18431,7 @@ M: "Theodore Ts'o" <[email protected]>
M: Jason A. Donenfeld <[email protected]>
S: Maintained
T: git https://git.kernel.org/pub/scm/linux/kernel/git/crng/random.git
+F: Documentation/devicetree/bindings/rng/vmgenid.yaml
F: drivers/char/random.c
F: drivers/virt/vmgenid.c
--
2.40.1
- 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/vmgenid.yaml
- Use proper FLAGS to compile with and without ACPI and/or devicetree.
Signed-off-by: Sudan Landge <[email protected]>
---
drivers/virt/Kconfig | 2 +-
drivers/virt/vmgenid.c | 106 ++++++++++++++++++++++++++++++++++++++---
2 files changed, 101 insertions(+), 7 deletions(-)
diff --git a/drivers/virt/Kconfig b/drivers/virt/Kconfig
index 40129b6f0eca..4f33ee2f0372 100644
--- a/drivers/virt/Kconfig
+++ b/drivers/virt/Kconfig
@@ -16,7 +16,7 @@ if VIRT_DRIVERS
config VMGENID
tristate "Virtual Machine Generation ID driver"
default y
- depends on ACPI
+ depends on (ACPI || OF)
help
Say Y here to use the hypervisor-provided Virtual Machine Generation ID
to reseed the RNG when the VM is cloned. This is highly recommended if
diff --git a/drivers/virt/vmgenid.c b/drivers/virt/vmgenid.c
index d5394c706bd9..ec378c37a2a2 100644
--- a/drivers/virt/vmgenid.c
+++ b/drivers/virt/vmgenid.c
@@ -2,7 +2,7 @@
/*
* Copyright (C) 2022 Jason A. Donenfeld <[email protected]>. All Rights Reserved.
*
- * The "Virtual Machine Generation ID" is exposed via ACPI and changes when a
+ * The "Virtual Machine Generation ID" is exposed via ACPI or DT and changes when a
* virtual machine forks or is cloned. This driver exists for shepherding that
* information to random.c.
*/
@@ -13,14 +13,27 @@
#include <linux/random.h>
#include <acpi/actypes.h>
#include <linux/platform_device.h>
-
+#ifdef CONFIG_OF
+#include <linux/init.h>
+#include <linux/interrupt.h>
+#include <linux/io.h>
+#include <linux/of_address.h>
+#include <linux/of_device.h>
+#include <linux/of_irq.h>
+#endif
+
+#ifdef CONFIG_ACPI
ACPI_MODULE_NAME("vmgenid");
+#endif
enum { VMGENID_SIZE = 16 };
struct vmgenid_state {
u8 *next_id;
u8 this_id[VMGENID_SIZE];
+#ifdef CONFIG_OF
+ unsigned int irq;
+#endif
};
static void vmgenid_notify(struct device *device)
@@ -37,10 +50,24 @@ static void vmgenid_notify(struct device *device)
kobject_uevent_env(&device->kobj, KOBJ_CHANGE, envp);
}
+#ifdef CONFIG_ACPI
static void vmgenid_acpi_handler(acpi_handle handle, u32 event, void *dev)
{
+ (void)handle;
+ (void)event;
vmgenid_notify(dev);
}
+#endif
+
+#ifdef CONFIG_OF
+static irqreturn_t vmgenid_of_irq_handler(int irq, void *dev)
+{
+ (void)irq;
+ vmgenid_notify(dev);
+
+ return IRQ_HANDLED;
+}
+#endif
static int setup_vmgenid_state(struct vmgenid_state *state, u8 *next_id)
{
@@ -55,6 +82,7 @@ static int setup_vmgenid_state(struct vmgenid_state *state, u8 *next_id)
static int vmgenid_add_acpi(struct device *dev, struct vmgenid_state *state)
{
+#ifdef CONFIG_ACPI
struct acpi_device *device = ACPI_COMPANION(dev);
struct acpi_buffer parsed = { ACPI_ALLOCATE_BUFFER };
union acpi_object *obj;
@@ -96,6 +124,54 @@ static int vmgenid_add_acpi(struct device *dev, struct vmgenid_state *state)
out:
ACPI_FREE(parsed.pointer);
return ret;
+#else
+ (void)dev;
+ (void)state;
+ return -EINVAL;
+#endif
+}
+
+static int vmgenid_add_of(struct device *dev, struct vmgenid_state *state)
+{
+#ifdef CONFIG_OF
+ struct resource res;
+ int ret = 0;
+
+ if (of_address_to_resource(dev->of_node, 0, &res)) {
+ dev_err(dev, "Failed to get resources from device tree");
+ ret = -EINVAL;
+ goto out;
+ }
+
+ if (!__request_mem_region(res.start, resource_size(&res),
+ "vmgenid", IORESOURCE_EXCLUSIVE)) {
+ dev_err(dev, "Failed to request mem region");
+ ret = -EINVAL;
+ goto out;
+ }
+
+ ret = setup_vmgenid_state(state, (u8 *)of_iomap(dev->of_node, 0));
+ if (ret)
+ goto out;
+
+ state->irq = irq_of_parse_and_map(dev->of_node, 0);
+ dev->driver_data = state;
+
+ if (request_irq(state->irq, vmgenid_of_irq_handler,
+ IRQF_SHARED, "vmgenid", dev) < 0) {
+ dev_err(dev, "request_irq failed");
+ dev->driver_data = NULL;
+ ret = -EINVAL;
+ goto out;
+ }
+
+out:
+ return ret;
+#else
+ (void)dev;
+ (void)state;
+ return -EINVAL;
+#endif
}
static int vmgenid_add(struct platform_device *pdev)
@@ -108,7 +184,10 @@ static int vmgenid_add(struct platform_device *pdev)
if (!state)
return -ENOMEM;
- ret = vmgenid_add_acpi(dev, state);
+ if (dev->of_node)
+ ret = vmgenid_add_of(dev, state);
+ else
+ ret = vmgenid_add_acpi(dev, state);
if (ret)
devm_kfree(dev, state);
@@ -116,18 +195,33 @@ static int vmgenid_add(struct platform_device *pdev)
return ret;
}
-static const struct acpi_device_id vmgenid_ids[] = {
+#ifdef CONFIG_OF
+static const struct of_device_id vmgenid_of_ids[] = {
+ { .compatible = "linux,vmgenctr", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, vmgenid_of_ids);
+#endif
+
+#ifdef CONFIG_ACPI
+static const struct acpi_device_id vmgenid_acpi_ids[] = {
{ "VMGENCTR", 0 },
{ "VM_GEN_COUNTER", 0 },
{ }
};
-MODULE_DEVICE_TABLE(acpi, vmgenid_ids);
+MODULE_DEVICE_TABLE(acpi, vmgenid_acpi_ids);
+#endif
static struct platform_driver vmgenid_plaform_driver = {
.probe = vmgenid_add,
.driver = {
.name = "vmgenid",
- .acpi_match_table = ACPI_PTR(vmgenid_ids),
+#ifdef CONFIG_ACPI
+ .acpi_match_table = ACPI_PTR(vmgenid_acpi_ids),
+#endif
+#ifdef CONFIG_OF
+ .of_match_table = vmgenid_of_ids,
+#endif
.owner = THIS_MODULE,
},
};
--
2.40.1
Hi Sudan,
kernel test robot noticed the following build warnings:
[auto build test WARNING on a4145ce1e7bc247fd6f2846e8699473448717b37]
url: https://github.com/intel-lab-lkp/linux/commits/Sudan-Landge/virt-vmgenid-rearrange-code-to-make-review-easier/20240321-105317
base: a4145ce1e7bc247fd6f2846e8699473448717b37
patch link: https://lore.kernel.org/r/20240321025105.53210-5-sudanl%40amazon.com
patch subject: [PATCH v2 4/4] virt: vmgenid: add support for devicetree bindings
config: x86_64-randconfig-123-20240321 (https://download.01.org/0day-ci/archive/20240322/[email protected]/config)
compiler: gcc-12 (Debian 12.2.0-14) 12.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240322/[email protected]/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <[email protected]>
| Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/
sparse warnings: (new ones prefixed by >>)
>> drivers/virt/vmgenid.c:153:43: sparse: sparse: cast removes address space '__iomem' of expression
vim +/__iomem +153 drivers/virt/vmgenid.c
133
134 static int vmgenid_add_of(struct device *dev, struct vmgenid_state *state)
135 {
136 #ifdef CONFIG_OF
137 struct resource res;
138 int ret = 0;
139
140 if (of_address_to_resource(dev->of_node, 0, &res)) {
141 dev_err(dev, "Failed to get resources from device tree");
142 ret = -EINVAL;
143 goto out;
144 }
145
146 if (!__request_mem_region(res.start, resource_size(&res),
147 "vmgenid", IORESOURCE_EXCLUSIVE)) {
148 dev_err(dev, "Failed to request mem region");
149 ret = -EINVAL;
150 goto out;
151 }
152
> 153 ret = setup_vmgenid_state(state, (u8 *)of_iomap(dev->of_node, 0));
154 if (ret)
155 goto out;
156
157 state->irq = irq_of_parse_and_map(dev->of_node, 0);
158 dev->driver_data = state;
159
160 if (request_irq(state->irq, vmgenid_of_irq_handler,
161 IRQF_SHARED, "vmgenid", dev) < 0) {
162 dev_err(dev, "request_irq failed");
163 dev->driver_data = NULL;
164 ret = -EINVAL;
165 goto out;
166 }
167
168 out:
169 return ret;
170 #else
171 (void)dev;
172 (void)state;
173 return -EINVAL;
174 #endif
175 }
176
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
Hi Sudan,
kernel test robot noticed the following build errors:
[auto build test ERROR on a4145ce1e7bc247fd6f2846e8699473448717b37]
url: https://github.com/intel-lab-lkp/linux/commits/Sudan-Landge/virt-vmgenid-rearrange-code-to-make-review-easier/20240321-105317
base: a4145ce1e7bc247fd6f2846e8699473448717b37
patch link: https://lore.kernel.org/r/20240321025105.53210-5-sudanl%40amazon.com
patch subject: [PATCH v2 4/4] virt: vmgenid: add support for devicetree bindings
config: s390-randconfig-002-20240322 (https://download.01.org/0day-ci/archive/20240322/[email protected]/config)
compiler: clang version 19.0.0git (https://github.com/llvm/llvm-project 23de3862dce582ce91c1aa914467d982cb1a73b4)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240322/[email protected]/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <[email protected]>
| Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/
All errors (new ones prefixed by >>):
s390x-linux-ld: drivers/virt/vmgenid.o: in function `vmgenid_add':
>> vmgenid.c:(.text+0xe8): undefined reference to `of_address_to_resource'
>> s390x-linux-ld: vmgenid.c:(.text+0x148): undefined reference to `of_iomap'
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
On Wed, Mar 20, 2024 at 9:51 PM Sudan Landge <[email protected]> wrote:
>
> - 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/vmgenid.yaml
>
> - Use proper FLAGS to compile with and without ACPI and/or devicetree.
>
> Signed-off-by: Sudan Landge <[email protected]>
> ---
> drivers/virt/Kconfig | 2 +-
> drivers/virt/vmgenid.c | 106 ++++++++++++++++++++++++++++++++++++++---
> 2 files changed, 101 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/virt/Kconfig b/drivers/virt/Kconfig
> index 40129b6f0eca..4f33ee2f0372 100644
> --- a/drivers/virt/Kconfig
> +++ b/drivers/virt/Kconfig
> @@ -16,7 +16,7 @@ if VIRT_DRIVERS
> config VMGENID
> tristate "Virtual Machine Generation ID driver"
> default y
> - depends on ACPI
> + depends on (ACPI || OF)
One of those is pretty much always enabled, so it can probably be dropped.
> help
> Say Y here to use the hypervisor-provided Virtual Machine Generation ID
> to reseed the RNG when the VM is cloned. This is highly recommended if
> diff --git a/drivers/virt/vmgenid.c b/drivers/virt/vmgenid.c
> index d5394c706bd9..ec378c37a2a2 100644
> --- a/drivers/virt/vmgenid.c
> +++ b/drivers/virt/vmgenid.c
> @@ -2,7 +2,7 @@
> /*
> * Copyright (C) 2022 Jason A. Donenfeld <[email protected]>. All Rights Reserved.
> *
> - * The "Virtual Machine Generation ID" is exposed via ACPI and changes when a
> + * The "Virtual Machine Generation ID" is exposed via ACPI or DT and changes when a
> * virtual machine forks or is cloned. This driver exists for shepherding that
> * information to random.c.
> */
> @@ -13,14 +13,27 @@
> #include <linux/random.h>
> #include <acpi/actypes.h>
> #include <linux/platform_device.h>
> -
> +#ifdef CONFIG_OF
You don't need nor want ifdefs around includes.
> +#include <linux/init.h>
> +#include <linux/interrupt.h>
> +#include <linux/io.h>
> +#include <linux/of_address.h>
> +#include <linux/of_device.h>
Doubtful you need this header.
> +#include <linux/of_irq.h>
> +#endif
> +
> +#ifdef CONFIG_ACPI
Probably don't need this.
> ACPI_MODULE_NAME("vmgenid");
> +#endif
>
> enum { VMGENID_SIZE = 16 };
>
> struct vmgenid_state {
> u8 *next_id;
> u8 this_id[VMGENID_SIZE];
> +#ifdef CONFIG_OF
Really worth saving 1 int on ACPI systems?
> + unsigned int irq;
> +#endif
> };
>
> static void vmgenid_notify(struct device *device)
> @@ -37,10 +50,24 @@ static void vmgenid_notify(struct device *device)
> kobject_uevent_env(&device->kobj, KOBJ_CHANGE, envp);
> }
>
> +#ifdef CONFIG_ACPI
Avoid ifdefs. Use "IS_ENABLED(CONFIG_ACPI)" instead if you must.
> static void vmgenid_acpi_handler(acpi_handle handle, u32 event, void *dev)
> {
> + (void)handle;
> + (void)event;
I don't think these are ever needed.
> vmgenid_notify(dev);
> }
> +#endif
> +
> +#ifdef CONFIG_OF
> +static irqreturn_t vmgenid_of_irq_handler(int irq, void *dev)
> +{
> + (void)irq;
> + vmgenid_notify(dev);
> +
> + return IRQ_HANDLED;
> +}
> +#endif
>
> static int setup_vmgenid_state(struct vmgenid_state *state, u8 *next_id)
> {
> @@ -55,6 +82,7 @@ static int setup_vmgenid_state(struct vmgenid_state *state, u8 *next_id)
>
> static int vmgenid_add_acpi(struct device *dev, struct vmgenid_state *state)
> {
> +#ifdef CONFIG_ACPI
> struct acpi_device *device = ACPI_COMPANION(dev);
> struct acpi_buffer parsed = { ACPI_ALLOCATE_BUFFER };
> union acpi_object *obj;
> @@ -96,6 +124,54 @@ static int vmgenid_add_acpi(struct device *dev, struct vmgenid_state *state)
> out:
> ACPI_FREE(parsed.pointer);
> return ret;
> +#else
> + (void)dev;
> + (void)state;
> + return -EINVAL;
> +#endif
> +}
> +
> +static int vmgenid_add_of(struct device *dev, struct vmgenid_state *state)
> +{
> +#ifdef CONFIG_OF
> + struct resource res;
> + int ret = 0;
> +
> + if (of_address_to_resource(dev->of_node, 0, &res)) {
No, use the platform_ APIs which work for both ACPI and DT.
> + dev_err(dev, "Failed to get resources from device tree");
> + ret = -EINVAL;
> + goto out;
> + }
> +
> + if (!__request_mem_region(res.start, resource_size(&res),
There's a single API to do this and ioremap. Use it.
> + "vmgenid", IORESOURCE_EXCLUSIVE)) {
> + dev_err(dev, "Failed to request mem region");
> + ret = -EINVAL;
> + goto out;
> + }
> +
> + ret = setup_vmgenid_state(state, (u8 *)of_iomap(dev->of_node, 0));
> + if (ret)
> + goto out;
> +
> + state->irq = irq_of_parse_and_map(dev->of_node, 0);
platform_get_irq()
> + dev->driver_data = state;
> +
> + if (request_irq(state->irq, vmgenid_of_irq_handler,
> + IRQF_SHARED, "vmgenid", dev) < 0) {
> + dev_err(dev, "request_irq failed");
> + dev->driver_data = NULL;
> + ret = -EINVAL;
> + goto out;
> + }
> +
> +out:
> + return ret;
> +#else
> + (void)dev;
> + (void)state;
> + return -EINVAL;
> +#endif
> }
>
> static int vmgenid_add(struct platform_device *pdev)
> @@ -108,7 +184,10 @@ static int vmgenid_add(struct platform_device *pdev)
> if (!state)
> return -ENOMEM;
>
> - ret = vmgenid_add_acpi(dev, state);
> + if (dev->of_node)
> + ret = vmgenid_add_of(dev, state);
> + else
> + ret = vmgenid_add_acpi(dev, state);
>
> if (ret)
> devm_kfree(dev, state);
> @@ -116,18 +195,33 @@ static int vmgenid_add(struct platform_device *pdev)
> return ret;
> }
>
> -static const struct acpi_device_id vmgenid_ids[] = {
> +#ifdef CONFIG_OF
> +static const struct of_device_id vmgenid_of_ids[] = {
> + { .compatible = "linux,vmgenctr", },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, vmgenid_of_ids);
> +#endif
> +
> +#ifdef CONFIG_ACPI
> +static const struct acpi_device_id vmgenid_acpi_ids[] = {
> { "VMGENCTR", 0 },
> { "VM_GEN_COUNTER", 0 },
> { }
> };
> -MODULE_DEVICE_TABLE(acpi, vmgenid_ids);
> +MODULE_DEVICE_TABLE(acpi, vmgenid_acpi_ids);
> +#endif
>
> static struct platform_driver vmgenid_plaform_driver = {
> .probe = vmgenid_add,
> .driver = {
> .name = "vmgenid",
> - .acpi_match_table = ACPI_PTR(vmgenid_ids),
> +#ifdef CONFIG_ACPI
> + .acpi_match_table = ACPI_PTR(vmgenid_acpi_ids),
Pretty sure you don't need the ifdef AND ACPI_PTR.
> +#endif
> +#ifdef CONFIG_OF
> + .of_match_table = vmgenid_of_ids,
> +#endif
> .owner = THIS_MODULE,
> },
> };
> --
> 2.40.1
>
>
On 22/03/2024 13:33, Rob Herring wrote:
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
>
>
>
> On Wed, Mar 20, 2024 at 9:51 PM Sudan Landge <[email protected]> wrote:
>>
>> - 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/vmgenid.yaml
>>
>> - Use proper FLAGS to compile with and without ACPI and/or devicetree.
>>
>> Signed-off-by: Sudan Landge <[email protected]>
>> ---
>> drivers/virt/Kconfig | 2 +-
>> drivers/virt/vmgenid.c | 106 ++++++++++++++++++++++++++++++++++++++---
>> 2 files changed, 101 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/virt/Kconfig b/drivers/virt/Kconfig
>> index 40129b6f0eca..4f33ee2f0372 100644
>> --- a/drivers/virt/Kconfig
>> +++ b/drivers/virt/Kconfig
>> @@ -16,7 +16,7 @@ if VIRT_DRIVERS
>> config VMGENID
>> tristate "Virtual Machine Generation ID driver"
>> default y
>> - depends on ACPI
>> + depends on (ACPI || OF)
>
> One of those is pretty much always enabled, so it can probably be dropped.
>
>> help
>> Say Y here to use the hypervisor-provided Virtual Machine Generation ID
>> to reseed the RNG when the VM is cloned. This is highly recommended if
>> diff --git a/drivers/virt/vmgenid.c b/drivers/virt/vmgenid.c
>> index d5394c706bd9..ec378c37a2a2 100644
>> --- a/drivers/virt/vmgenid.c
>> +++ b/drivers/virt/vmgenid.c
>> @@ -2,7 +2,7 @@
>> /*
>> * Copyright (C) 2022 Jason A. Donenfeld <[email protected]>. All Rights Reserved.
>> *
>> - * The "Virtual Machine Generation ID" is exposed via ACPI and changes when a
>> + * The "Virtual Machine Generation ID" is exposed via ACPI or DT and changes when a
>> * virtual machine forks or is cloned. This driver exists for shepherding that
>> * information to random.c.
>> */
>> @@ -13,14 +13,27 @@
>> #include <linux/random.h>
>> #include <acpi/actypes.h>
>> #include <linux/platform_device.h>
>> -
>> +#ifdef CONFIG_OF
>
> You don't need nor want ifdefs around includes.
>
>> +#include <linux/init.h>
>> +#include <linux/interrupt.h>
>> +#include <linux/io.h>
>> +#include <linux/of_address.h>
>> +#include <linux/of_device.h>
>
> Doubtful you need this header.
>
>> +#include <linux/of_irq.h>
>> +#endif
>> +
>> +#ifdef CONFIG_ACPI
>
> Probably don't need this.
>
>> ACPI_MODULE_NAME("vmgenid");
>> +#endif
>>
>> enum { VMGENID_SIZE = 16 };
>>
>> struct vmgenid_state {
>> u8 *next_id;
>> u8 this_id[VMGENID_SIZE];
>> +#ifdef CONFIG_OF
>
> Really worth saving 1 int on ACPI systems?
>
>> + unsigned int irq;
>> +#endif
>> };
>>
>> static void vmgenid_notify(struct device *device)
>> @@ -37,10 +50,24 @@ static void vmgenid_notify(struct device *device)
>> kobject_uevent_env(&device->kobj, KOBJ_CHANGE, envp);
>> }
>>
>> +#ifdef CONFIG_ACPI
>
> Avoid ifdefs. Use "IS_ENABLED(CONFIG_ACPI)" instead if you must.
>
>> static void vmgenid_acpi_handler(acpi_handle handle, u32 event, void *dev)
>> {
>> + (void)handle;
>> + (void)event;
>
> I don't think these are ever needed.
>
>> vmgenid_notify(dev);
>> }
>> +#endif
>> +
>> +#ifdef CONFIG_OF
>> +static irqreturn_t vmgenid_of_irq_handler(int irq, void *dev)
>> +{
>> + (void)irq;
>> + vmgenid_notify(dev);
>> +
>> + return IRQ_HANDLED;
>> +}
>> +#endif
>>
>> static int setup_vmgenid_state(struct vmgenid_state *state, u8 *next_id)
>> {
>> @@ -55,6 +82,7 @@ static int setup_vmgenid_state(struct vmgenid_state *state, u8 *next_id)
>>
>> static int vmgenid_add_acpi(struct device *dev, struct vmgenid_state *state)
>> {
>> +#ifdef CONFIG_ACPI
>> struct acpi_device *device = ACPI_COMPANION(dev);
>> struct acpi_buffer parsed = { ACPI_ALLOCATE_BUFFER };
>> union acpi_object *obj;
>> @@ -96,6 +124,54 @@ static int vmgenid_add_acpi(struct device *dev, struct vmgenid_state *state)
>> out:
>> ACPI_FREE(parsed.pointer);
>> return ret;
>> +#else
>> + (void)dev;
>> + (void)state;
>> + return -EINVAL;
>> +#endif
>> +}
>> +
>> +static int vmgenid_add_of(struct device *dev, struct vmgenid_state *state)
>> +{
>> +#ifdef CONFIG_OF
>> + struct resource res;
>> + int ret = 0;
>> +
>> + if (of_address_to_resource(dev->of_node, 0, &res)) {
>
> No, use the platform_ APIs which work for both ACPI and DT.
>
>> + dev_err(dev, "Failed to get resources from device tree");
>> + ret = -EINVAL;
>> + goto out;
>> + }
>> +
>> + if (!__request_mem_region(res.start, resource_size(&res),
>
> There's a single API to do this and ioremap. Use it.
>
>> + "vmgenid", IORESOURCE_EXCLUSIVE)) {
>> + dev_err(dev, "Failed to request mem region");
>> + ret = -EINVAL;
>> + goto out;
>> + }
>> +
>> + ret = setup_vmgenid_state(state, (u8 *)of_iomap(dev->of_node, 0));
>> + if (ret)
>> + goto out;
>> +
>> + state->irq = irq_of_parse_and_map(dev->of_node, 0);
>
> platform_get_irq()
>
>> + dev->driver_data = state;
>> +
>> + if (request_irq(state->irq, vmgenid_of_irq_handler,
>> + IRQF_SHARED, "vmgenid", dev) < 0) {
>> + dev_err(dev, "request_irq failed");
>> + dev->driver_data = NULL;
>> + ret = -EINVAL;
>> + goto out;
>> + }
>> +
>> +out:
>> + return ret;
>> +#else
>> + (void)dev;
>> + (void)state;
>> + return -EINVAL;
>> +#endif
>> }
>>
>> static int vmgenid_add(struct platform_device *pdev)
>> @@ -108,7 +184,10 @@ static int vmgenid_add(struct platform_device *pdev)
>> if (!state)
>> return -ENOMEM;
>>
>> - ret = vmgenid_add_acpi(dev, state);
>> + if (dev->of_node)
>> + ret = vmgenid_add_of(dev, state);
>> + else
>> + ret = vmgenid_add_acpi(dev, state);
>>
>> if (ret)
>> devm_kfree(dev, state);
>> @@ -116,18 +195,33 @@ static int vmgenid_add(struct platform_device *pdev)
>> return ret;
>> }
>>
>> -static const struct acpi_device_id vmgenid_ids[] = {
>> +#ifdef CONFIG_OF
>> +static const struct of_device_id vmgenid_of_ids[] = {
>> + { .compatible = "linux,vmgenctr", },
>> + {},
>> +};
>> +MODULE_DEVICE_TABLE(of, vmgenid_of_ids);
>> +#endif
>> +
>> +#ifdef CONFIG_ACPI
>> +static const struct acpi_device_id vmgenid_acpi_ids[] = {
>> { "VMGENCTR", 0 },
>> { "VM_GEN_COUNTER", 0 },
>> { }
>> };
>> -MODULE_DEVICE_TABLE(acpi, vmgenid_ids);
>> +MODULE_DEVICE_TABLE(acpi, vmgenid_acpi_ids);
>> +#endif
>>
>> static struct platform_driver vmgenid_plaform_driver = {
>> .probe = vmgenid_add,
>> .driver = {
>> .name = "vmgenid",
>> - .acpi_match_table = ACPI_PTR(vmgenid_ids),
>> +#ifdef CONFIG_ACPI
>> + .acpi_match_table = ACPI_PTR(vmgenid_acpi_ids),
>
> Pretty sure you don't need the ifdef AND ACPI_PTR.
>
>> +#endif
>> +#ifdef CONFIG_OF
>> + .of_match_table = vmgenid_of_ids,
>> +#endif
>> .owner = THIS_MODULE,
>> },
>> };
>> --
>> 2.40.1
>>
>>
Thank you for the feedback and sorry for my lack of experience regarding
the APIs. I will use the alternatives APIs suggested for devicetree and
revert after thorough testing.
On Thu, Mar 21, 2024 at 02:51:04AM +0000, 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 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]>
> ---
> .../devicetree/bindings/rng/vmgenid.yaml | 57 +++++++++++++++++++
> MAINTAINERS | 1 +
> 2 files changed, 58 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/rng/vmgenid.yaml
>
> diff --git a/Documentation/devicetree/bindings/rng/vmgenid.yaml b/Documentation/devicetree/bindings/rng/vmgenid.yaml
> new file mode 100644
> index 000000000000..4b6ab62cc2ae
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/rng/vmgenid.yaml
> @@ -0,0 +1,57 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/rng/vmgenid.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Virtual Machine Generation Counter ID device
> +
> +maintainers:
> + - Jason A. Donenfeld <[email protected]>
> +
> +description:
> + Firmwares or hypervisors can use this devicetree to describe
> + interrupts and the shared resources to inject a Virtual Machine Generation
> + counter.
> +
> +properties:
> + compatible:
> + const: linux,vmgenctr
Why 'linux'? It should be named for a particular host implementation
(and that implementation's bugs/quirks). However, this thing is simple
enough we can perhaps avoid that here. As the interface is defined by
Microsoft, then perhaps they should be the vendor here.
> +
> + "#interrupt-cells":
> + const: 3
> + description: |
> + The 1st cell is the interrupt type.
> + The 2nd cell contains the interrupt number for the interrupt type.
> + The 3rd cell is for trigger type and level flags.
> +
> + interrupt-controller: true
Why is this device an interrupt controller?
> +
> + reg:
> + description: |
> + specifies the base physical address and
> + size of the regions in memory which holds the VMGenID counter.
Odd wrapping, but drop unless you have something specific to say about
region like perhaps the layout of the registers. Or maybe thats defined
somewhere else?
Does the spec say anything about endianness or access size? DT assumes
native endianness by default. We have properties to deal these, but
would be better to be explicit if that's defined already.
> + maxItems: 1
> +
> + interrupts:
> + description: |
Don't need '|' if no formatting.
> + interrupt used to notify that a new VMGenID counter is available.
> + The interrupt should be Edge triggered.
> + maxItems: 1
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + rng@80000000 {
> + compatible = "linux,vmgenctr";
> + reg = <0x80000000 0x1000>;
> + interrupts = <0x00 0x23 0x01>;
> + };
> +
> +...
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 43b39956694a..cf4b2e10fb49 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -18431,6 +18431,7 @@ M: "Theodore Ts'o" <[email protected]>
> M: Jason A. Donenfeld <[email protected]>
> S: Maintained
> T: git https://git.kernel.org/pub/scm/linux/kernel/git/crng/random.git
> +F: Documentation/devicetree/bindings/rng/vmgenid.yaml
> F: drivers/char/random.c
> F: drivers/virt/vmgenid.c
>
> --
> 2.40.1
>
>
On 25/03/2024 15:06, Rob Herring wrote:
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
>
>
>
> On Thu, Mar 21, 2024 at 02:51:04AM +0000, 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 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]>
>> ---
>> .../devicetree/bindings/rng/vmgenid.yaml | 57 +++++++++++++++++++
>> MAINTAINERS | 1 +
>> 2 files changed, 58 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/rng/vmgenid.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/rng/vmgenid.yaml b/Documentation/devicetree/bindings/rng/vmgenid.yaml
>> new file mode 100644
>> index 000000000000..4b6ab62cc2ae
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/rng/vmgenid.yaml
>> @@ -0,0 +1,57 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/rng/vmgenid.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Virtual Machine Generation Counter ID device
>> +
>> +maintainers:
>> + - Jason A. Donenfeld <[email protected]>
>> +
>> +description:
>> + Firmwares or hypervisors can use this devicetree to describe
>> + interrupts and the shared resources to inject a Virtual Machine Generation
>> + counter.
>> +
>> +properties:
>> + compatible:
>> + const: linux,vmgenctr
>
> Why 'linux'? It should be named for a particular host implementation
> (and that implementation's bugs/quirks). However, this thing is simple
> enough we can perhaps avoid that here. As the interface is defined by
> Microsoft, then perhaps they should be the vendor here.
>
We chose "linux" because the current implementation and usage of
devicetree was Linux specific. However, I think "virtual" would be a
better choice than "Microsoft" since this is a generic virtual device
that could be configured by any hypervisor or firmware not owned or
related to Microsoft. I have updated this as part of the new version if
it looks good. I don't have a strong opinion for "virtual" though so if
that is the right choice as per you I can update it.
>> +
>> + "#interrupt-cells":
>> + const: 3
>> + description: |
>> + The 1st cell is the interrupt type.
>> + The 2nd cell contains the interrupt number for the interrupt type.
>> + The 3rd cell is for trigger type and level flags.
>> +
>> + interrupt-controller: true
>
> Why is this device an interrupt controller?
>
My devicetree references I took initially were incorrect which led to
the addition of this, I have removed this in the next version. Sorry
about that.
>> +
>> + reg:
>> + description: |
>> + specifies the base physical address and
>> + size of the regions in memory which holds the VMGenID counter.
>
> Odd wrapping, but drop unless you have something specific to say about
> region like perhaps the layout of the registers. Or maybe thats defined
> somewhere else?
>
> Does the spec say anything about endianness or access size? DT assumes
> native endianness by default. We have properties to deal these, but
> would be better to be explicit if that's defined already.
>
The spec doesn't mention anything about the endianness but, I have
updated the description with some more data.
>> + maxItems: 1
>> +
>> + interrupts:
>> + description: |
>
> Don't need '|' if no formatting.
>
>> + interrupt used to notify that a new VMGenID counter is available.
>> + The interrupt should be Edge triggered.
>> + maxItems: 1
>> +
>> +required:
>> + - compatible
>> + - reg
>> + - interrupts
>> +
>> +additionalProperties: false
>> +
>> +examples:
>> + - |
>> + rng@80000000 {
>> + compatible = "linux,vmgenctr";
>> + reg = <0x80000000 0x1000>;
>> + interrupts = <0x00 0x23 0x01>;
>> + };
>> +
>> +...
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 43b39956694a..cf4b2e10fb49 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -18431,6 +18431,7 @@ M: "Theodore Ts'o" <[email protected]>
>> M: Jason A. Donenfeld <[email protected]>
>> S: Maintained
>> T: git https://git.kernel.org/pub/scm/linux/kernel/git/crng/random.git
>> +F: Documentation/devicetree/bindings/rng/vmgenid.yaml
>> F: drivers/char/random.c
>> F: drivers/virt/vmgenid.c
>>
>> --
>> 2.40.1
>>
>>
Thank you for the feedback, I have pushed a new version of the patch to
address the review comments.
On Mon, Mar 25, 2024 at 3:11 PM Landge, Sudan <[email protected]> wrote:
>
>
>
> On 25/03/2024 15:06, Rob Herring wrote:
> > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
> >
> >
> >
> > On Thu, Mar 21, 2024 at 02:51:04AM +0000, 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 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]>
> >> ---
> >> .../devicetree/bindings/rng/vmgenid.yaml | 57 +++++++++++++++++++
> >> MAINTAINERS | 1 +
> >> 2 files changed, 58 insertions(+)
> >> create mode 100644 Documentation/devicetree/bindings/rng/vmgenid.yaml
> >>
> >> diff --git a/Documentation/devicetree/bindings/rng/vmgenid.yaml b/Documentation/devicetree/bindings/rng/vmgenid.yaml
> >> new file mode 100644
> >> index 000000000000..4b6ab62cc2ae
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/rng/vmgenid.yaml
> >> @@ -0,0 +1,57 @@
> >> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> >> +%YAML 1.2
> >> +---
> >> +$id: http://devicetree.org/schemas/rng/vmgenid.yaml#
> >> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> >> +
> >> +title: Virtual Machine Generation Counter ID device
> >> +
> >> +maintainers:
> >> + - Jason A. Donenfeld <[email protected]>
> >> +
> >> +description:
> >> + Firmwares or hypervisors can use this devicetree to describe
> >> + interrupts and the shared resources to inject a Virtual Machine Generation
> >> + counter.
> >> +
> >> +properties:
> >> + compatible:
> >> + const: linux,vmgenctr
> >
> > Why 'linux'? It should be named for a particular host implementation
> > (and that implementation's bugs/quirks). However, this thing is simple
> > enough we can perhaps avoid that here. As the interface is defined by
> > Microsoft, then perhaps they should be the vendor here.
> >
> We chose "linux" because the current implementation and usage of
> devicetree was Linux specific. However, I think "virtual" would be a
> better choice than "Microsoft" since this is a generic virtual device
> that could be configured by any hypervisor or firmware not owned or
> related to Microsoft. I have updated this as part of the new version if
> it looks good. I don't have a strong opinion for "virtual" though so if
> that is the right choice as per you I can update it.
I'm not really a fan of 'virtual' and its one and only existing use.
Don't add to it.
Someone has defined how to read a GUID from register(s). I can think
of many ways that could be implemented. The data itself could be hex
or ascii. You could read N times from one register or read from N
sequential registers. And again, there's endianness and access sizes.
Given the only source of any of that is a Microsoft spec, then that
makes sense to me. Or just no vendor prefix is possible, but I prefer
to avoid those cases.
Also, consider 'vmgenctr' has basically 0 search results. 'vmgenid'
returns some relevant results. Not that search results are a
requirement for naming, but perhaps something to consider.
> >> +
> >> + "#interrupt-cells":
> >> + const: 3
> >> + description: |
> >> + The 1st cell is the interrupt type.
> >> + The 2nd cell contains the interrupt number for the interrupt type.
> >> + The 3rd cell is for trigger type and level flags.
> >> +
> >> + interrupt-controller: true
> >
> > Why is this device an interrupt controller?
> >
> My devicetree references I took initially were incorrect which led to
> the addition of this, I have removed this in the next version. Sorry
> about that.
Try again...
> >> +
> >> + reg:
> >> + description: |
> >> + specifies the base physical address and
> >> + size of the regions in memory which holds the VMGenID counter.
> >
> > Odd wrapping, but drop unless you have something specific to say about
> > region like perhaps the layout of the registers. Or maybe thats defined
> > somewhere else?
> >
> > Does the spec say anything about endianness or access size? DT assumes
> > native endianness by default. We have properties to deal these, but
> > would be better to be explicit if that's defined already.
> >
> The spec doesn't mention anything about the endianness but, I have
> updated the description with some more data.
Then what does your driver assume? Microsoft may not have thought
about it because they don't care, but now you want to use DT so you
have to because it is frequently used on BE systems. If we define
something, then there's some hope. Otherwise, it's pretty much a
guarantee folks will do the opposite.
Rob
On 25/03/2024 20:41, Rob Herring wrote:
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
>
>
>
> On Mon, Mar 25, 2024 at 3:11 PM Landge, Sudan <[email protected]> wrote:
>>
>>
>>
>> On 25/03/2024 15:06, Rob Herring wrote:
>>> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
>>>
>>>
>>>
>>> On Thu, Mar 21, 2024 at 02:51:04AM +0000, 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 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]>
>>>> ---
>>>> .../devicetree/bindings/rng/vmgenid.yaml | 57 +++++++++++++++++++
>>>> MAINTAINERS | 1 +
>>>> 2 files changed, 58 insertions(+)
>>>> create mode 100644 Documentation/devicetree/bindings/rng/vmgenid.yaml
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/rng/vmgenid.yaml b/Documentation/devicetree/bindings/rng/vmgenid.yaml
>>>> new file mode 100644
>>>> index 000000000000..4b6ab62cc2ae
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/rng/vmgenid.yaml
>>>> @@ -0,0 +1,57 @@
>>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>>> +%YAML 1.2
>>>> +---
>>>> +$id: http://devicetree.org/schemas/rng/vmgenid.yaml#
>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>>> +
>>>> +title: Virtual Machine Generation Counter ID device
>>>> +
>>>> +maintainers:
>>>> + - Jason A. Donenfeld <[email protected]>
>>>> +
>>>> +description:
>>>> + Firmwares or hypervisors can use this devicetree to describe
>>>> + interrupts and the shared resources to inject a Virtual Machine Generation
>>>> + counter.
>>>> +
>>>> +properties:
>>>> + compatible:
>>>> + const: linux,vmgenctr
>>>
>>> Why 'linux'? It should be named for a particular host implementation
>>> (and that implementation's bugs/quirks). However, this thing is simple
>>> enough we can perhaps avoid that here. As the interface is defined by
>>> Microsoft, then perhaps they should be the vendor here.
>>>
>> We chose "linux" because the current implementation and usage of
>> devicetree was Linux specific. However, I think "virtual" would be a
>> better choice than "Microsoft" since this is a generic virtual device
>> that could be configured by any hypervisor or firmware not owned or
>> related to Microsoft. I have updated this as part of the new version if
>> it looks good. I don't have a strong opinion for "virtual" though so if
>> that is the right choice as per you I can update it.
>
> I'm not really a fan of 'virtual' and its one and only existing use.
> Don't add to it.
>
> Someone has defined how to read a GUID from register(s). I can think
> of many ways that could be implemented. The data itself could be hex
> or ascii. You could read N times from one register or read from N
> sequential registers. And again, there's endianness and access sizes.
> Given the only source of any of that is a Microsoft spec, then that
> makes sense to me. Or just no vendor prefix is possible, but I prefer
> to avoid those cases.
ok, you are right. Using "Microsoft" as the compatible string makes more
sense. I will use that.
>
> Also, consider 'vmgenctr' has basically 0 search results. 'vmgenid'
> returns some relevant results. Not that search results are a
> requirement for naming, but perhaps something to consider.
>
The original driver supports 2 ACPI CIDs, "VMGENCTR" and
"VM_GEN_COUNTER" and as per this commit
https://github.com/torvalds/linux/commit/0396e46dc46523cba8401a0df84f67cc0b6067ab
"VMGENCTR" is to be used for VMGenID specs. So, I used "vmgenctr" to be
consistent with its ACPI counterpart "VMGENCTR".
>>>> +
>>>> + "#interrupt-cells":
>>>> + const: 3
>>>> + description: |
>>>> + The 1st cell is the interrupt type.
>>>> + The 2nd cell contains the interrupt number for the interrupt type.
>>>> + The 3rd cell is for trigger type and level flags.
>>>> +
>>>> + interrupt-controller: true
>>>
>>> Why is this device an interrupt controller?
>>>
>> My devicetree references I took initially were incorrect which led to
>> the addition of this, I have removed this in the next version. Sorry
>> about that.
>
> Try again...
>
Ok, I will confirm my understanding and provide a better answer in my
next mail. As you mentioned in another mail, I will also pause on
posting any new version till the current threads are answered.
>>>> +
>>>> + reg:
>>>> + description: |
>>>> + specifies the base physical address and
>>>> + size of the regions in memory which holds the VMGenID counter.
>>>
>>> Odd wrapping, but drop unless you have something specific to say about
>>> region like perhaps the layout of the registers. Or maybe thats defined
>>> somewhere else?
>>>
>>> Does the spec say anything about endianness or access size? DT assumes
>>> native endianness by default. We have properties to deal these, but
>>> would be better to be explicit if that's defined already.
>>>
>> The spec doesn't mention anything about the endianness but, I have
>> updated the description with some more data.
>
> Then what does your driver assume? Microsoft may not have thought
> about it because they don't care, but now you want to use DT so you
> have to because it is frequently used on BE systems. If we define
> something, then there's some hope. Otherwise, it's pretty much a
> guarantee folks will do the opposite.
>
> Rob
The driver does not assume any endianness. To provide more context, The
hypervisor stores a 128bit unique ID at the address pointed by the
"reg"'s 1st cell, driver memcpy's this ID to an internal context and
uses memcmp to compare if the ID is new or old.
But yes, it will be good to define a fixed endianness to avoid any
error. I will update the description to use little endian.
On Tue, Mar 26, 2024 at 01:06:16PM +0000, Landge, Sudan wrote:
> >>> Does the spec say anything about endianness or access size? DT assumes
> >>> native endianness by default. We have properties to deal these, but
> >>> would be better to be explicit if that's defined already.
> >>>
> >> The spec doesn't mention anything about the endianness but, I have
> >> updated the description with some more data.
> >
> > Then what does your driver assume? Microsoft may not have thought
> > about it because they don't care, but now you want to use DT so you
> > have to because it is frequently used on BE systems. If we define
> > something, then there's some hope. Otherwise, it's pretty much a
> > guarantee folks will do the opposite.
> >
> > Rob
> The driver does not assume any endianness. To provide more context, The
> hypervisor stores a 128bit unique ID at the address pointed by the
> "reg"'s 1st cell, driver memcpy's this ID to an internal context and
> uses memcmp to compare if the ID is new or old.
> But yes, it will be good to define a fixed endianness to avoid any
> error. I will update the description to use little endian.
It's a 16-byte blob. Why care about endianness at all here? Treat it as
a byte string, not an integer.
Jason