virt: vmgenid: Add devicetree bindings support

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(-)

drivers/virt/vmgenid.c +0 -0

index ea956df02874..d5394c706bd9 100644

drivers/virt/vmgenid.c +0 -0

 ACPI_MODULE_NAME("vmgenid");
 

drivers/virt/vmgenid.c +0 -3

-static struct acpi_driver vmgenid_driver = {
-	.name = "vmgenid",
-	.ids = vmgenid_ids,

drivers/virt/vmgenid.c +4 -1

+		.owner = THIS_MODULE,
+	},
 };
 
-module_acpi_driver(vmgenid_driver);
+static int vmgenid_platform_device_init(void)
+{

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      | 58 +++++++++++++++++++

 MAINTAINERS                                   |  1 +
 2 files changed, 59 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/rng/vmgenid.yaml

Documentation/devicetree/bindings/rng/vmgenid.yaml new file +19 -0

new file mode 100644
index 000000000000..24643080d6b0
@@ -0,0 +1,58 @@
+# 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: virtual,vmgenctr

Documentation/devicetree/bindings/rng/vmgenid.yaml new file +23 -0

+    maxItems: 1
+
+  interrupts:
+    description:
+      interrupt used to notify that a new VMGenID counter is available.
+    maxItems: 1
+
+required:
+  - compatible
+  - reg
+  - interrupts
+
+additionalProperties: false
+
+examples:
+  - |
+    rng@80000000 {
+      compatible = "virtual,vmgenctr";
+      reg = <0x80000000 0x1000>;
+      interrupts = <0x00 0x23 0x01>;
+    };
+
+...

MAINTAINERS +1 -1

index de6a64b248ae..e295d2f50af4 100644
@@ -18461,6 +18461,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

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.

Documentation/devicetree/bindings/rng/vmgenid.yaml new file +16 -0

new file mode 100644
index 000000000000..24643080d6b0
@@ -0,0 +1,58 @@
+# 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.
+

Documentation/devicetree/bindings/rng/vmgenid.yaml new file +19 -0

+
+  interrupt-map: true
+
+  reg:
+    description:
+      The 1st cell specifies the base physical address of the 8-byte aligned
+      buffer in guest memory space which is guaranteed not to be used by the
+      operating system.
+      The 2nd cell specifies the size of the buffer which holds the VMGenID.
+    maxItems: 1
+
+  interrupts:
+    description:
+      interrupt used to notify that a new VMGenID counter is available.
+    maxItems: 1
+
+required:
+  - compatible
+  - reg

- 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   |  1 -
 drivers/virt/vmgenid.c | 85 +++++++++++++++++++++++++++++++++++++++---
 2 files changed, 80 insertions(+), 6 deletions(-)

drivers/virt/vmgenid.c +10 -0

+
+#if IS_ENABLED(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)
 {

drivers/virt/vmgenid.c +29 -0

 	struct acpi_device *device = ACPI_COMPANION(dev);
 	struct acpi_buffer parsed = { ACPI_ALLOCATE_BUFFER };
 	union acpi_object *obj;

@@ -96,6 +112,49 @@ 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 platform_device *pdev, struct vmgenid_state *state)
+{
+#if IS_ENABLED(CONFIG_OF)
+	void __iomem *remapped_ptr;
+	int ret = 0;
+
+	remapped_ptr = devm_platform_get_and_ioremap_resource(pdev, 0, NULL);
+	if (IS_ERR(remapped_ptr)) {
+		ret = PTR_ERR(remapped_ptr);
+		goto out;
+	}
+
+	ret = setup_vmgenid_state(state, remapped_ptr);
+	if (ret)
+		goto out;
+
+	state->irq = platform_get_irq(pdev, 0);
+	if (state->irq < 0) {
+		ret = state->irq;
+		goto out;
+	}
+	pdev->dev.driver_data = state;

drivers/virt/vmgenid.c +8 -1

+	(void)dev;
+	(void)state;
+	return -EINVAL;
+#endif
 }
 
 static int vmgenid_add(struct platform_device *pdev)

@@ -108,7 +167,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(pdev, state);
+	else
+		ret = vmgenid_add_acpi(dev, state);
 
 	if (ret)
 		devm_kfree(dev, state);

(quoted diff) +9 -1

+static const struct of_device_id vmgenid_of_ids[] = {
+	{ .compatible = "linux,vmgenctr", },
+	{},
+};
+MODULE_DEVICE_TABLE(of, vmgenid_of_ids);
+#endif
+
+#if IS_ENABLED(CONFIG_ACPI)
 
 
+static const struct acpi_device_id vmgenid_acpi_ids[] = {
 	{ "VMGENCTR", 0 },
 	{ "VM_GEN_COUNTER", 0 },
 	{ }
 };
-MODULE_DEVICE_TABLE(acpi, vmgenid_ids);

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.

Quoted 5 lines · Sudan Landge

- 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

Quoted 1 line

- Use proper FLAGS to compile with and without ACPI and/or devicetree.

I do not see any flags. You use if/ifdefs which is a NAK.

Do not mix independent changes within one commit. Please follow guidelines in submitting-patches for this.

Quoted 7 lines

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

---
  drivers/virt/Kconfig   |  1 -
  drivers/virt/vmgenid.c | 85 +++++++++++++++++++++++++++++++++++++++---
  2 files changed, 80 insertions(+), 6 deletions(-)

...

Quoted 15 lines

drivers/virt/vmgenid.c +10 -0

+
+#if IS_ENABLED(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 +70,7 @@ static int setup_vmgenid_state(struct vmgenid_state *state, u8 *next_id)
 

drivers/virt/vmgenid.c static int setup_vmgenid_state(struct vmgenid_state *state, u8 *next_id) · line 73

Quoted 3 lines

drivers/virt/vmgenid.c +1 -0

  static int vmgenid_add_acpi(struct device *dev, struct vmgenid_state *state)
  {
+#if IS_ENABLED(CONFIG_ACPI)

Why do you create all this ifdeffery in the code? You already got comments to get rid of all this #if.

Quoted 44 lines

drivers/virt/vmgenid.c +37 -0

       struct acpi_device *device = ACPI_COMPANION(dev);
       struct acpi_buffer parsed = { ACPI_ALLOCATE_BUFFER };
       union acpi_object *obj;

@@ -96,6 +112,49 @@ 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 platform_device *pdev, struct vmgenid_state *state)
+{
+#if IS_ENABLED(CONFIG_OF)
+     void __iomem *remapped_ptr;
+     int ret = 0;
+
+     remapped_ptr = devm_platform_get_and_ioremap_resource(pdev, 0, NULL);
+     if (IS_ERR(remapped_ptr)) {
+             ret = PTR_ERR(remapped_ptr);
+             goto out;
+     }
+
+     ret = setup_vmgenid_state(state, remapped_ptr);
+     if (ret)
+             goto out;
+
+     state->irq = platform_get_irq(pdev, 0);
+     if (state->irq < 0) {
+             ret = state->irq;
+             goto out;
+     }
+     pdev->dev.driver_data = state;
+
+     ret =  devm_request_irq(&pdev->dev, state->irq,
+                             vmgenid_of_irq_handler,
+                             IRQF_SHARED, "vmgenid", &pdev->dev);
+     if (ret)
+             pdev->dev.driver_data = NULL;
+
+out:

drivers/virt/vmgenid.c static int vmgenid_add_acpi(struct device *dev, struct vmgenid_state *state) · line 153

Quoted 2 lines

drivers/virt/vmgenid.c +2 -0

+     return ret;
+#else

That's neither readable code nor matching Linux coding style. Driver don't do such magic. Please open some recent drivers for ACPI and OF and look there. Old drivers had stubs for !CONFIG_XXX, but new drivers don't have even that.

Quoted 20 lines

drivers/virt/vmgenid.c +8 -1

+     (void)dev;
+     (void)state;
+     return -EINVAL;
+#endif
  }
 
  static int vmgenid_add(struct platform_device *pdev)

@@ -108,7 +167,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(pdev, state);
+     else
+             ret = vmgenid_add_acpi(dev, state);
 
       if (ret)
               devm_kfree(dev, state);

drivers/virt/vmgenid.c static int vmgenid_add(struct platform_device *pdev) · line 181

Quoted 5 lines

drivers/virt/vmgenid.c +1 -1

@@ -116,18 +178,31 @@ static int vmgenid_add(struct platform_device *pdev)
       return ret;
  }
 
-static const struct acpi_device_id vmgenid_ids[] = {
+#if IS_ENABLED(CONFIG_OF)

No, drop.

Quoted 16 lines

(quoted diff) +9 -1

+static const struct of_device_id vmgenid_of_ids[] = {
+     { .compatible = "linux,vmgenctr", },
+     {},
+};
+MODULE_DEVICE_TABLE(of, vmgenid_of_ids);
+#endif
+
+#if IS_ENABLED(CONFIG_ACPI)
 
 
+static const struct acpi_device_id vmgenid_acpi_ids[] = {
       { "VMGENCTR", 0 },
       { "VM_GEN_COUNTER", 0 },
       { }
  };
-MODULE_DEVICE_TABLE(acpi, vmgenid_ids);

Review static int vmgenid_add(struct platform_device *pdev) · line 205

Quoted 10 lines

(quoted diff) +4 -1

+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),
+             .acpi_match_table = ACPI_PTR(vmgenid_acpi_ids),
+#if IS_ENABLED(CONFIG_OF)

No, really, this is some ancient code.

Please point me to single driver doing such ifdef.

drivers/virt/vmgenid.c static int vmgenid_add(struct platform_device *pdev) · line 206

Quoted 3 lines

drivers/virt/vmgenid.c +2 -0

+             .of_match_table = vmgenid_of_ids,
+#endif
               .owner = THIS_MODULE,

This is clearly some abandoned driver... sigh... I thought we get rid of all this owner crap. Many years ago. How could it appear back if automated tools report it?

Considering how many failures LKP reported for your patchsets, I have real doubts that anyone actually tests this code.

Please confirm:
Did you build W=1, run smatch, sparse and coccinelle on the driver after your changes?

Best regards,
Krzysztof

Quoted 1 line

.owner = THIS_MODULE,

This is clearly some abandoned driver... sigh... I thought we get rid of all this owner crap. Many years ago. How could it appear back if automated tools report it?

Considering how many failures LKP reported for your patchsets, I have real doubts that anyone actually tests this code.

Quoted 8 lines · Krzysztof Kozlowski

Quoted 1 line

.owner = THIS_MODULE,

This is clearly some abandoned driver... sigh... I thought we get rid of all this owner crap. Many years ago. How could it appear back if automated tools report it?

Considering how many failures LKP reported for your patchsets, I have real doubts that anyone actually tests this code.

Now you're commenting on the context rather than the patch.

No, this isn't an abandoned driver, no it's not untested. Rather, it's code I maintain, care deeply about, and have a tree that receives quite a bit of testing (random.git) where I'll be taking these OF patches in the case that this patchset improves (and thanks very much for your

Hi Sudan,

kernel test robot noticed the following build errors:

   134		ret = setup_vmgenid_state(state, remapped_ptr);
   135		if (ret)
   136			goto out;
   137	
   138		state->irq = platform_get_irq(pdev, 0);
   139		if (state->irq < 0) {
   140			ret = state->irq;
   141			goto out;
   142		}
   143		pdev->dev.driver_data = state;
   144	
   145		ret =  devm_request_irq(&pdev->dev, state->irq,

   146					vmgenid_of_irq_handler,
   147					IRQF_SHARED, "vmgenid", &pdev->dev);
   148		if (ret)
   149			pdev->dev.driver_data = NULL;
   150	
   151	out:
   152		return ret;
   153	#else

Quoted 1 line

154 (void)dev;

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.

Quoted 3 lines · kernel test robot

Hi Sudan,

kernel test robot noticed the following build errors:

...

Quoted 12 lines

    134                ret = setup_vmgenid_state(state, remapped_ptr);
    135                if (ret)
    136                        goto out;
    137
    138                state->irq = platform_get_irq(pdev, 0);
    139                if (state->irq < 0) {
    140                        ret = state->irq;
    141                        goto out;
    142                }
    143                pdev->dev.driver_data = state;
    144
    145                ret =  devm_request_irq(&pdev->dev, state->irq,

Quoted 9 lines

    146                                        vmgenid_of_irq_handler,
    147                                        IRQF_SHARED, "vmgenid", &pdev->dev);
    148                if (ret)
    149                        pdev->dev.driver_data = NULL;
    150
    151        out:
    152                return ret;
    153        #else

Quoted 1 line

154 (void)dev;

So this code was not even built...

Best regards,
Krzysztof