[PATCH V4 5/5] virtio: Bind virtio device to device-tree node

[Viresh Kumar]

Bind the virtio devices with their of_node. This will help users of the
virtio devices to mention their dependencies on the device in the DT
itself. Like GPIO pin users can use the phandle of the device node, or
the node may contain more subnodes to add i2c or spi eeproms and other
users.

Reviewed-by: Arnd Bergmann 
Signed-off-by: Viresh Kumar 
---
 drivers/virtio/virtio.c | 57 ++---
 1 file changed, 54 insertions(+), 3 deletions(-)

diff --git a/drivers/virtio/virtio.c b/drivers/virtio/virtio.c
index 4b15c00c0a0a..5f80786c2aa2 100644
--- a/drivers/virtio/virtio.c
+++ b/drivers/virtio/virtio.c
@@ -4,6 +4,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 /* Unique numbering for virtio devices. */
@@ -292,6 +293,9 @@ static int virtio_dev_remove(struct device *_d)
 
/* Acknowledge the device's existence again. */
virtio_add_status(dev, VIRTIO_CONFIG_S_ACKNOWLEDGE);
+
+   of_node_put(dev->dev.of_node);
+
return 0;
 }
 
@@ -319,6 +323,43 @@ void unregister_virtio_driver(struct virtio_driver *driver)
 }
 EXPORT_SYMBOL_GPL(unregister_virtio_driver);
 
+static int virtio_device_of_init(struct virtio_device *dev)
+{
+   struct device_node *np, *pnode = dev_of_node(dev->dev.parent);
+   char compat[] = "virtio,device";
+   int ret, count;
+
+   if (!pnode)
+   return 0;
+
+   count = of_get_available_child_count(pnode);
+   if (!count)
+   return 0;
+
+   /* There can be only 1 child node */
+   if (WARN_ON(count > 1))
+   return -EINVAL;
+
+   np = of_get_next_available_child(pnode, NULL);
+   if (WARN_ON(!np))
+   return -ENODEV;
+
+   ret = snprintf(compat, sizeof(compat), "virtio,device%x", 
dev->id.device);
+   BUG_ON(ret >= sizeof(compat));
+
+   if (!of_device_is_compatible(np, compat)) {
+   ret = -EINVAL;
+   goto out;
+   }
+
+   dev->dev.of_node = np;
+   return 0;
+
+out:
+   of_node_put(np);
+   return ret;
+}
+
 /**
  * register_virtio_device - register virtio device
  * @dev: virtio device to be registered
@@ -343,6 +384,10 @@ int register_virtio_device(struct virtio_device *dev)
dev->index = err;
dev_set_name(&dev->dev, "virtio%u", dev->index);
 
+   err = virtio_device_of_init(dev);
+   if (err)
+   goto out_ida_remove;
+
spin_lock_init(&dev->config_lock);
dev->config_enabled = false;
dev->config_change_pending = false;
@@ -362,10 +407,16 @@ int register_virtio_device(struct virtio_device *dev)
 */
err = device_add(&dev->dev);
if (err)
-   ida_simple_remove(&virtio_index_ida, dev->index);
+   goto out_of_node_put;
+
+   return 0;
+
+out_of_node_put:
+   of_node_put(dev->dev.of_node);
+out_ida_remove:
+   ida_simple_remove(&virtio_index_ida, dev->index);
 out:
-   if (err)
-   virtio_add_status(dev, VIRTIO_CONFIG_S_FAILED);
+   virtio_add_status(dev, VIRTIO_CONFIG_S_FAILED);
return err;
 }
 EXPORT_SYMBOL_GPL(register_virtio_device);
-- 
2.31.1.272.g89b43f80a514

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

[PATCH V4 4/5] uapi: virtio_ids: Sync ids with specification

[Viresh Kumar]

This synchronizes the virtio ids with the latest list from virtio
specification.

Signed-off-by: Viresh Kumar 
---
 include/uapi/linux/virtio_ids.h | 12 
 1 file changed, 12 insertions(+)

diff --git a/include/uapi/linux/virtio_ids.h b/include/uapi/linux/virtio_ids.h
index 70a8057ad4bb..3c8e11820fdb 100644
--- a/include/uapi/linux/virtio_ids.h
+++ b/include/uapi/linux/virtio_ids.h
@@ -54,8 +54,20 @@
 #define VIRTIO_ID_SOUND25 /* virtio sound */
 #define VIRTIO_ID_FS   26 /* virtio filesystem */
 #define VIRTIO_ID_PMEM 27 /* virtio pmem */
+#define VIRTIO_ID_RPMB 28 /* virtio rpmb */
 #define VIRTIO_ID_MAC80211_HWSIM   29 /* virtio mac80211-hwsim */
+#define VIRTIO_ID_VIDEO_ENCODER30 /* virtio video encoder */
+#define VIRTIO_ID_VIDEO_DECODER31 /* virtio video decoder */
+#define VIRTIO_ID_SCMI 32 /* virtio scmi */
+#define VIRTIO_ID_NITRO_SEC_MOD33 /* virtio nitro secure 
module*/
+#define VIRTIO_ID_I2C_ADAPTER  34 /* virtio i2c adapter */
+#define VIRTIO_ID_WATCHDOG 35 /* virtio watchdog */
+#define VIRTIO_ID_CAN  36 /* virtio can */
+#define VIRTIO_ID_DMABUF   37 /* virtio dmabuf */
+#define VIRTIO_ID_PARAM_SERV   38 /* virtio parameter server */
+#define VIRTIO_ID_AUDIO_POLICY 39 /* virtio audio policy */
 #define VIRTIO_ID_BT   40 /* virtio bluetooth */
+#define VIRTIO_ID_GPIO 41 /* virtio gpio */
 
 /*
  * Virtio Transitional IDs
-- 
2.31.1.272.g89b43f80a514

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

[PATCH V4 3/5] dt-bindings: gpio: Add bindings for gpio-virtio

[Viresh Kumar]

This patch adds binding for virtio GPIO controller, it is based on
virtio-device bindings.

Reviewed-by: Arnd Bergmann 
Signed-off-by: Viresh Kumar 
---
 .../devicetree/bindings/gpio/gpio-virtio.yaml | 59 +++
 1 file changed, 59 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/gpio/gpio-virtio.yaml

diff --git a/Documentation/devicetree/bindings/gpio/gpio-virtio.yaml 
b/Documentation/devicetree/bindings/gpio/gpio-virtio.yaml
new file mode 100644
index ..601d85754577
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-virtio.yaml
@@ -0,0 +1,59 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpio/gpio-virtio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Virtio GPIO controller
+
+maintainers:
+  - Viresh Kumar 
+
+allOf:
+  - $ref: /schemas/virtio/virtio-device.yaml#
+
+description:
+  Virtio GPIO controller, see /schemas/virtio/virtio-device.yaml for more
+  details.
+
+properties:
+  $nodename:
+const: gpio
+
+  compatible:
+const: virtio,device29
+
+  gpio-controller: true
+
+  "#gpio-cells":
+const: 2
+
+  interrupt-controller: true
+
+  "#interrupt-cells":
+const: 2
+
+required:
+  - compatible
+  - gpio-controller
+  - "#gpio-cells"
+
+unevaluatedProperties: false
+
+examples:
+  - |
+virtio@3000 {
+compatible = "virtio,mmio";
+reg = <0x3000 0x100>;
+interrupts = <41>;
+
+gpio {
+compatible = "virtio,device29";
+gpio-controller;
+#gpio-cells = <2>;
+interrupt-controller;
+#interrupt-cells = <2>;
+};
+};
+
+...
-- 
2.31.1.272.g89b43f80a514

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

[PATCH V4 2/5] dt-bindings: i2c: Add bindings for i2c-virtio

[Viresh Kumar]

This patch adds binding for virtio I2C device, it is based on
virtio-device bindings.

Acked-by: Wolfram Sang 
Reviewed-by: Arnd Bergmann 
Signed-off-by: Viresh Kumar 
---
 .../devicetree/bindings/i2c/i2c-virtio.yaml   | 51 +++
 1 file changed, 51 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/i2c/i2c-virtio.yaml

diff --git a/Documentation/devicetree/bindings/i2c/i2c-virtio.yaml 
b/Documentation/devicetree/bindings/i2c/i2c-virtio.yaml
new file mode 100644
index ..7d87ed855301
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-virtio.yaml
@@ -0,0 +1,51 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/i2c/i2c-virtio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Virtio I2C Adapter
+
+maintainers:
+  - Viresh Kumar 
+
+allOf:
+  - $ref: /schemas/i2c/i2c-controller.yaml#
+  - $ref: /schemas/virtio/virtio-device.yaml#
+
+description:
+  Virtio I2C device, see /schemas/virtio/virtio-device.yaml for more details.
+
+properties:
+  $nodename:
+const: i2c
+
+  compatible:
+const: virtio,device22
+
+required:
+  - compatible
+
+unevaluatedProperties: false
+
+examples:
+  - |
+virtio@3000 {
+compatible = "virtio,mmio";
+reg = <0x3000 0x100>;
+interrupts = <41>;
+
+i2c {
+compatible = "virtio,device22";
+
+#address-cells = <1>;
+#size-cells = <0>;
+
+light-sensor@20 {
+compatible = "dynaimage,al3320a";
+reg = <0x20>;
+};
+};
+};
+
+...
-- 
2.31.1.272.g89b43f80a514

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

[PATCH V4 1/5] dt-bindings: virtio: Add binding for virtio devices

[Viresh Kumar]

Allow virtio device sub-nodes to be added to the virtio mmio or pci
nodes. The compatible property for virtio device must be of the format
"virtio,device", where ID is virtio device ID in hexadecimal format.

Signed-off-by: Viresh Kumar 
---
 .../devicetree/bindings/virtio/mmio.yaml  |  3 +-
 .../bindings/virtio/virtio-device.yaml| 41 +++
 2 files changed, 43 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/virtio/virtio-device.yaml

diff --git a/Documentation/devicetree/bindings/virtio/mmio.yaml 
b/Documentation/devicetree/bindings/virtio/mmio.yaml
index d46597028cf1..4b7a0273181c 100644
--- a/Documentation/devicetree/bindings/virtio/mmio.yaml
+++ b/Documentation/devicetree/bindings/virtio/mmio.yaml
@@ -36,7 +36,8 @@ title: virtio memory mapped devices
   - reg
   - interrupts
 
-additionalProperties: false
+additionalProperties:
+  type: object
 
 examples:
   - |
diff --git a/Documentation/devicetree/bindings/virtio/virtio-device.yaml 
b/Documentation/devicetree/bindings/virtio/virtio-device.yaml
new file mode 100644
index ..1778ea9b5aa5
--- /dev/null
+++ b/Documentation/devicetree/bindings/virtio/virtio-device.yaml
@@ -0,0 +1,41 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/virtio/virtio-device.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Virtio device bindings
+
+maintainers:
+  - Viresh Kumar 
+
+description:
+  These bindings are applicable to virtio devices irrespective of the bus they
+  are bound to, like mmio or pci.
+
+# We need a select here so we don't match all nodes with 'virtio,mmio'
+properties:
+  compatible:
+pattern: "^virtio,device[0-9a-f]{1,8}$"
+description: Virtio device nodes.
+  "virtio,deviceID", where ID is the virtio device id. The textual
+  representation of ID shall be in lower case hexadecimal with leading
+  zeroes suppressed.
+
+required:
+  - compatible
+
+additionalProperties: true
+
+examples:
+  - |
+virtio@3000 {
+compatible = "virtio,mmio";
+reg = <0x3000 0x100>;
+interrupts = <43>;
+
+i2c {
+compatible = "virtio,device22";
+};
+};
+...
-- 
2.31.1.272.g89b43f80a514

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

[PATCH V4 0/5] virtio: Add virtio-device bindings

[Viresh Kumar]

Hi,

Currently the DT only provides support for following node types for virtio-mmio
nodes:

virtio_mmio@a00 {
dma-coherent;
interrupts = <0x00 0x10 0x01>;
reg = <0x00 0xa00 0x00 0x200>;
compatible = "virtio,mmio";
};

Here, each virtio-mmio corresponds to a virtio-device. But there is no way for
other users in the DT to show their dependency on virtio devices.

This patchset provides that support.

The first patch adds virtio-device bindings to allow for device sub-nodes to be
present and the second patch updates the virtio core to update the of_node.

Other patches add bindings for i2c and gpio devices.

Tested on x86 with qemu for arm64.

V3->V4:
- The binding is named "virtio,device" now.
- The virtio binding doesn't restrict the node names anymore.
- The i2c/gpio nodes are named i2c and gpio now.
- Dropped including gpio.yaml.
- Updated code to match the new binding name.
- Use "type: object" in additional-property.

V2/2.1->V3:
- Added review-tags from Arnd and Wolfram.
- Only the 5th patch changed otherwise:
  - Use of_device_is_compatible() instead of keeping a list of devices.
  - Use snprintf (with BUG_ON on return value) to create the compatible string,
whose length is fixed using "virtio,".
  - Use dev_of_node().

V1->V2:
- The changes (both binding and code) are made at virtio level, instead of
  virtio-mmio. This allows the same to be used by all device types, irrespective
  of the transport mechanism.

- Dropped the reg property and used compatible in the form "virtio,".

- Dropped dt-bindings/virtio/virtio_ids.h.

- Add a patch to sync virtio-ids from spec, required for the last patch.

--
Viresh

Viresh Kumar (5):
  dt-bindings: virtio: Add binding for virtio devices
  dt-bindings: i2c: Add bindings for i2c-virtio
  dt-bindings: gpio: Add bindings for gpio-virtio
  uapi: virtio_ids: Sync ids with specification
  virtio: Bind virtio device to device-tree node

 .../devicetree/bindings/gpio/gpio-virtio.yaml | 59 +++
 .../devicetree/bindings/i2c/i2c-virtio.yaml   | 51 
 .../devicetree/bindings/virtio/mmio.yaml  |  3 +-
 .../bindings/virtio/virtio-device.yaml| 41 +
 drivers/virtio/virtio.c   | 57 +-
 include/uapi/linux/virtio_ids.h   | 12 
 6 files changed, 219 insertions(+), 4 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/gpio/gpio-virtio.yaml
 create mode 100644 Documentation/devicetree/bindings/i2c/i2c-virtio.yaml
 create mode 100644 Documentation/devicetree/bindings/virtio/virtio-device.yaml

-- 
2.31.1.272.g89b43f80a514

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH V3 1/5] dt-bindings: virtio: Add binding for virtio devices

[Viresh Kumar]

On 26-07-21, 08:57, Rob Herring wrote:
> On Sun, Jul 25, 2021 at 10:52 PM Viresh Kumar  wrote:
> > +description: |
> > +  Exactly one node describing the virtio device. The name of the node 
> > isn't
> > +  significant but its phandle can be used to by a user of the virtio 
> > device.
> > +
> > +  compatible:
> > +pattern: "^virtio,[0-9a-f]+$"
> 
> DID is only 4 chars? If so, "^virtio,[0-9a-f]{1,4}$"

It is 32 bit actually, so making this {1,8}.

-- 
viresh
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH v15] i2c: virtio: add a virtio i2c frontend driver

[Viresh Kumar]

On 27-07-21, 10:15, Jie Deng wrote:
> 
> On 2021/7/23 17:03, Arnd Bergmann wrote:
> > On Fri, Jul 23, 2021 at 7:44 AM Jie Deng  wrote:
> > 
> > > +
> > > +   ret = virtio_i2c_setup_vqs(vi);
> > > +   if (ret)
> > > +   return ret;
> > > +
> > > +   vi->adap.owner = THIS_MODULE;
> > > +   snprintf(vi->adap.name, sizeof(vi->adap.name),
> > > +"i2c_virtio at virtio bus %d", vdev->index);
> > > +   vi->adap.algo = &virtio_algorithm;
> > > +   vi->adap.quirks = &virtio_i2c_quirks;
> > > +   vi->adap.dev.parent = &vdev->dev;
> > > +   i2c_set_adapdata(&vi->adap, vi);
> > > +
> > > +   /*
> > > +* Setup ACPI node for controlled devices which will be probed 
> > > through
> > > +* ACPI.
> > > +*/
> > > +   ACPI_COMPANION_SET(&vi->adap.dev, ACPI_COMPANION(pdev));
> > Since there is now a generic way for virtio drivers to link up with OF
> > device nodes, maybe this should be handled the same way in the
> > virtio core rather than the driver?
> 
> 
> I'm currently based on the I2C tree. Has that patch been already merged ？
> 
> Anyway, I think we can send an additional patch to remove this line once
> that
> 
> "generic way" patch is merged.

I agree, we need to get this merged and do stuff on top of it. We are
already on v15 :)

-- 
viresh
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH v15] i2c: virtio: add a virtio i2c frontend driver

[Jie Deng]

On 2021/7/23 17:03, Arnd Bergmann wrote:

On Fri, Jul 23, 2021 at 7:44 AM Jie Deng  wrote:


+
+   ret = virtio_i2c_setup_vqs(vi);
+   if (ret)
+   return ret;
+
+   vi->adap.owner = THIS_MODULE;
+   snprintf(vi->adap.name, sizeof(vi->adap.name),
+"i2c_virtio at virtio bus %d", vdev->index);
+   vi->adap.algo = &virtio_algorithm;
+   vi->adap.quirks = &virtio_i2c_quirks;
+   vi->adap.dev.parent = &vdev->dev;
+   i2c_set_adapdata(&vi->adap, vi);
+
+   /*
+* Setup ACPI node for controlled devices which will be probed through
+* ACPI.
+*/
+   ACPI_COMPANION_SET(&vi->adap.dev, ACPI_COMPANION(pdev));

Since there is now a generic way for virtio drivers to link up with OF
device nodes, maybe this should be handled the same way in the
virtio core rather than the driver?



I'm currently based on the I2C tree. Has that patch been already merged ？

Anyway, I think we can send an additional patch to remove this line once 
that


"generic way" patch is merged.

Regards,

Jie



___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [RFC 0/3] cpuidle: add poll_source API and virtio vq polling

[Rafael J. Wysocki]

On Mon, Jul 26, 2021 at 6:04 PM Stefan Hajnoczi  wrote:
>
> On Mon, Jul 26, 2021 at 05:47:19PM +0200, Rafael J. Wysocki wrote:
> > On Mon, Jul 26, 2021 at 5:17 PM Stefan Hajnoczi  wrote:
> > >
> > > On Thu, Jul 22, 2021 at 05:04:57PM +0800, Jason Wang wrote:
> > > >
> > > > 在 2021/7/21 下午5:41, Stefan Hajnoczi 写道:
> > > > > On Wed, Jul 21, 2021 at 11:29:55AM +0800, Jason Wang wrote:
> > > > > > 在 2021/7/14 上午12:19, Stefan Hajnoczi 写道:
> > > > > > > These patches are not polished yet but I would like request 
> > > > > > > feedback on this
> > > > > > > approach and share performance results with you.
> > > > > > >
> > > > > > > Idle CPUs tentatively enter a busy wait loop before halting when 
> > > > > > > the cpuidle
> > > > > > > haltpoll driver is enabled inside a virtual machine. This reduces 
> > > > > > > wakeup
> > > > > > > latency for events that occur soon after the vCPU becomes idle.
> > > > > > >
> > > > > > > This patch series extends the cpuidle busy wait loop with the new 
> > > > > > > poll_source
> > > > > > > API so drivers can participate in polling. Such polling-aware 
> > > > > > > drivers disable
> > > > > > > their device's irq during the busy wait loop to avoid the cost of 
> > > > > > > interrupts.
> > > > > > > This reduces latency further than regular cpuidle haltpoll, which 
> > > > > > > still relies
> > > > > > > on irqs.
> > > > > > >
> > > > > > > Virtio drivers are modified to use the poll_source API so all 
> > > > > > > virtio device
> > > > > > > types get this feature. The following virtio-blk fio benchmark 
> > > > > > > results show the
> > > > > > > improvement:
> > > > > > >
> > > > > > >IOPS (numjobs=4, iodepth=1, 4 virtqueues)
> > > > > > >  before   poll_source  io_poll
> > > > > > > 4k randread167102  186049 (+11%)  186654 (+11%)
> > > > > > > 4k randwrite   162204  181214 (+11%)  181850 (+12%)
> > > > > > > 4k randrw  159520  177071 (+11%)  177928 (+11%)
> > > > > > >
> > > > > > > The comparison against io_poll shows that cpuidle poll_source 
> > > > > > > achieves
> > > > > > > equivalent performance to the block layer's io_poll feature 
> > > > > > > (which I
> > > > > > > implemented in a separate patch series [1]).
> > > > > > >
> > > > > > > The advantage of poll_source is that applications do not need to 
> > > > > > > explicitly set
> > > > > > > the RWF_HIPRI I/O request flag. The poll_source approach is 
> > > > > > > attractive because
> > > > > > > few applications actually use RWF_HIPRI and it takes advantage of 
> > > > > > > CPU cycles we
> > > > > > > would have spent in cpuidle haltpoll anyway.
> > > > > > >
> > > > > > > The current series does not improve virtio-net. I haven't 
> > > > > > > investigated deeply,
> > > > > > > but it is possible that NAPI and poll_source do not combine. See 
> > > > > > > the final
> > > > > > > patch for a starting point on making the two work together.
> > > > > > >
> > > > > > > I have not tried this on bare metal but it might help there too. 
> > > > > > > The cost of
> > > > > > > disabling a device's irq must be less than the savings from 
> > > > > > > avoiding irq
> > > > > > > handling for this optimization to make sense.
> > > > > > >
> > > > > > > [1] 
> > > > > > > https://lore.kernel.org/linux-block/20210520141305.355961-1-stefa...@redhat.com/
> > > > > >
> > > > > > Hi Stefan:
> > > > > >
> > > > > > Some questions:
> > > > > >
> > > > > > 1) What's the advantages of introducing polling at virtio level 
> > > > > > instead of
> > > > > > doing it at each subsystems? Polling in virtio level may only work 
> > > > > > well if
> > > > > > all (or most) of the devices are virtio
> > > > > I'm not sure I understand the question. cpuidle haltpoll benefits all
> > > > > devices today, except it incurs interrupt latency. The poll_source API
> > > > > eliminates the interrupt latency for drivers that can disable device
> > > > > interrupts cheaply.
> > > > >
> > > > > This patch adds poll_source to core virtio code so that all virtio
> > > > > drivers get this feature for free. No driver-specific changes are
> > > > > needed.
> > > > >
> > > > > If you mean networking, block layer, etc by "subsystems" then there's
> > > > > nothing those subsystems can do to help. Whether poll_source can be 
> > > > > used
> > > > > depends on the specific driver, not the subsystem. If you consider
> > > > > drivers/virtio/ a subsystem, then that's exactly what the patch series
> > > > > is doing.
> > > >
> > > >
> > > > I meant, if we choose to use idle poll, we have some several choices:
> > > >
> > > > 1) bus level (e.g the virtio)
> > > > 2) subsystem level (e.g the networking and block)
> > > >
> > > > I'm not sure which one is better.
> > >
> > > This API is intended to be driver- or bus-level. I don't think
> > > subsystems can do very much since they don't know the hardware
> > > capabilities (cheap interrupt disabling) and in most cases there's no
> > > advantage of plum

Re: [RFC 0/3] cpuidle: add poll_source API and virtio vq polling

[Stefan Hajnoczi]

On Mon, Jul 26, 2021 at 05:47:19PM +0200, Rafael J. Wysocki wrote:
> On Mon, Jul 26, 2021 at 5:17 PM Stefan Hajnoczi  wrote:
> >
> > On Thu, Jul 22, 2021 at 05:04:57PM +0800, Jason Wang wrote:
> > >
> > > 在 2021/7/21 下午5:41, Stefan Hajnoczi 写道:
> > > > On Wed, Jul 21, 2021 at 11:29:55AM +0800, Jason Wang wrote:
> > > > > 在 2021/7/14 上午12:19, Stefan Hajnoczi 写道:
> > > > > > These patches are not polished yet but I would like request 
> > > > > > feedback on this
> > > > > > approach and share performance results with you.
> > > > > >
> > > > > > Idle CPUs tentatively enter a busy wait loop before halting when 
> > > > > > the cpuidle
> > > > > > haltpoll driver is enabled inside a virtual machine. This reduces 
> > > > > > wakeup
> > > > > > latency for events that occur soon after the vCPU becomes idle.
> > > > > >
> > > > > > This patch series extends the cpuidle busy wait loop with the new 
> > > > > > poll_source
> > > > > > API so drivers can participate in polling. Such polling-aware 
> > > > > > drivers disable
> > > > > > their device's irq during the busy wait loop to avoid the cost of 
> > > > > > interrupts.
> > > > > > This reduces latency further than regular cpuidle haltpoll, which 
> > > > > > still relies
> > > > > > on irqs.
> > > > > >
> > > > > > Virtio drivers are modified to use the poll_source API so all 
> > > > > > virtio device
> > > > > > types get this feature. The following virtio-blk fio benchmark 
> > > > > > results show the
> > > > > > improvement:
> > > > > >
> > > > > >IOPS (numjobs=4, iodepth=1, 4 virtqueues)
> > > > > >  before   poll_source  io_poll
> > > > > > 4k randread167102  186049 (+11%)  186654 (+11%)
> > > > > > 4k randwrite   162204  181214 (+11%)  181850 (+12%)
> > > > > > 4k randrw  159520  177071 (+11%)  177928 (+11%)
> > > > > >
> > > > > > The comparison against io_poll shows that cpuidle poll_source 
> > > > > > achieves
> > > > > > equivalent performance to the block layer's io_poll feature (which I
> > > > > > implemented in a separate patch series [1]).
> > > > > >
> > > > > > The advantage of poll_source is that applications do not need to 
> > > > > > explicitly set
> > > > > > the RWF_HIPRI I/O request flag. The poll_source approach is 
> > > > > > attractive because
> > > > > > few applications actually use RWF_HIPRI and it takes advantage of 
> > > > > > CPU cycles we
> > > > > > would have spent in cpuidle haltpoll anyway.
> > > > > >
> > > > > > The current series does not improve virtio-net. I haven't 
> > > > > > investigated deeply,
> > > > > > but it is possible that NAPI and poll_source do not combine. See 
> > > > > > the final
> > > > > > patch for a starting point on making the two work together.
> > > > > >
> > > > > > I have not tried this on bare metal but it might help there too. 
> > > > > > The cost of
> > > > > > disabling a device's irq must be less than the savings from 
> > > > > > avoiding irq
> > > > > > handling for this optimization to make sense.
> > > > > >
> > > > > > [1] 
> > > > > > https://lore.kernel.org/linux-block/20210520141305.355961-1-stefa...@redhat.com/
> > > > >
> > > > > Hi Stefan:
> > > > >
> > > > > Some questions:
> > > > >
> > > > > 1) What's the advantages of introducing polling at virtio level 
> > > > > instead of
> > > > > doing it at each subsystems? Polling in virtio level may only work 
> > > > > well if
> > > > > all (or most) of the devices are virtio
> > > > I'm not sure I understand the question. cpuidle haltpoll benefits all
> > > > devices today, except it incurs interrupt latency. The poll_source API
> > > > eliminates the interrupt latency for drivers that can disable device
> > > > interrupts cheaply.
> > > >
> > > > This patch adds poll_source to core virtio code so that all virtio
> > > > drivers get this feature for free. No driver-specific changes are
> > > > needed.
> > > >
> > > > If you mean networking, block layer, etc by "subsystems" then there's
> > > > nothing those subsystems can do to help. Whether poll_source can be used
> > > > depends on the specific driver, not the subsystem. If you consider
> > > > drivers/virtio/ a subsystem, then that's exactly what the patch series
> > > > is doing.
> > >
> > >
> > > I meant, if we choose to use idle poll, we have some several choices:
> > >
> > > 1) bus level (e.g the virtio)
> > > 2) subsystem level (e.g the networking and block)
> > >
> > > I'm not sure which one is better.
> >
> > This API is intended to be driver- or bus-level. I don't think
> > subsystems can do very much since they don't know the hardware
> > capabilities (cheap interrupt disabling) and in most cases there's no
> > advantage of plumbing it through subsystems when drivers can call the
> > API directly.
> >
> > > > > 2) What's the advantages of using cpuidle instead of using a thread 
> > > > > (and
> > > > > leverage the scheduler)?
> > > > In order to combine with the existing cpuidle infrastructure. No new
> > > > pol

Re: [RFC 0/3] cpuidle: add poll_source API and virtio vq polling

[Rafael J. Wysocki]

On Mon, Jul 26, 2021 at 5:17 PM Stefan Hajnoczi  wrote:
>
> On Thu, Jul 22, 2021 at 05:04:57PM +0800, Jason Wang wrote:
> >
> > 在 2021/7/21 下午5:41, Stefan Hajnoczi 写道:
> > > On Wed, Jul 21, 2021 at 11:29:55AM +0800, Jason Wang wrote:
> > > > 在 2021/7/14 上午12:19, Stefan Hajnoczi 写道:
> > > > > These patches are not polished yet but I would like request feedback 
> > > > > on this
> > > > > approach and share performance results with you.
> > > > >
> > > > > Idle CPUs tentatively enter a busy wait loop before halting when the 
> > > > > cpuidle
> > > > > haltpoll driver is enabled inside a virtual machine. This reduces 
> > > > > wakeup
> > > > > latency for events that occur soon after the vCPU becomes idle.
> > > > >
> > > > > This patch series extends the cpuidle busy wait loop with the new 
> > > > > poll_source
> > > > > API so drivers can participate in polling. Such polling-aware drivers 
> > > > > disable
> > > > > their device's irq during the busy wait loop to avoid the cost of 
> > > > > interrupts.
> > > > > This reduces latency further than regular cpuidle haltpoll, which 
> > > > > still relies
> > > > > on irqs.
> > > > >
> > > > > Virtio drivers are modified to use the poll_source API so all virtio 
> > > > > device
> > > > > types get this feature. The following virtio-blk fio benchmark 
> > > > > results show the
> > > > > improvement:
> > > > >
> > > > >IOPS (numjobs=4, iodepth=1, 4 virtqueues)
> > > > >  before   poll_source  io_poll
> > > > > 4k randread167102  186049 (+11%)  186654 (+11%)
> > > > > 4k randwrite   162204  181214 (+11%)  181850 (+12%)
> > > > > 4k randrw  159520  177071 (+11%)  177928 (+11%)
> > > > >
> > > > > The comparison against io_poll shows that cpuidle poll_source achieves
> > > > > equivalent performance to the block layer's io_poll feature (which I
> > > > > implemented in a separate patch series [1]).
> > > > >
> > > > > The advantage of poll_source is that applications do not need to 
> > > > > explicitly set
> > > > > the RWF_HIPRI I/O request flag. The poll_source approach is 
> > > > > attractive because
> > > > > few applications actually use RWF_HIPRI and it takes advantage of CPU 
> > > > > cycles we
> > > > > would have spent in cpuidle haltpoll anyway.
> > > > >
> > > > > The current series does not improve virtio-net. I haven't 
> > > > > investigated deeply,
> > > > > but it is possible that NAPI and poll_source do not combine. See the 
> > > > > final
> > > > > patch for a starting point on making the two work together.
> > > > >
> > > > > I have not tried this on bare metal but it might help there too. The 
> > > > > cost of
> > > > > disabling a device's irq must be less than the savings from avoiding 
> > > > > irq
> > > > > handling for this optimization to make sense.
> > > > >
> > > > > [1] 
> > > > > https://lore.kernel.org/linux-block/20210520141305.355961-1-stefa...@redhat.com/
> > > >
> > > > Hi Stefan:
> > > >
> > > > Some questions:
> > > >
> > > > 1) What's the advantages of introducing polling at virtio level instead 
> > > > of
> > > > doing it at each subsystems? Polling in virtio level may only work well 
> > > > if
> > > > all (or most) of the devices are virtio
> > > I'm not sure I understand the question. cpuidle haltpoll benefits all
> > > devices today, except it incurs interrupt latency. The poll_source API
> > > eliminates the interrupt latency for drivers that can disable device
> > > interrupts cheaply.
> > >
> > > This patch adds poll_source to core virtio code so that all virtio
> > > drivers get this feature for free. No driver-specific changes are
> > > needed.
> > >
> > > If you mean networking, block layer, etc by "subsystems" then there's
> > > nothing those subsystems can do to help. Whether poll_source can be used
> > > depends on the specific driver, not the subsystem. If you consider
> > > drivers/virtio/ a subsystem, then that's exactly what the patch series
> > > is doing.
> >
> >
> > I meant, if we choose to use idle poll, we have some several choices:
> >
> > 1) bus level (e.g the virtio)
> > 2) subsystem level (e.g the networking and block)
> >
> > I'm not sure which one is better.
>
> This API is intended to be driver- or bus-level. I don't think
> subsystems can do very much since they don't know the hardware
> capabilities (cheap interrupt disabling) and in most cases there's no
> advantage of plumbing it through subsystems when drivers can call the
> API directly.
>
> > > > 2) What's the advantages of using cpuidle instead of using a thread (and
> > > > leverage the scheduler)?
> > > In order to combine with the existing cpuidle infrastructure. No new
> > > polling loop is introduced and no additional CPU cycles are spent on
> > > polling.
> > >
> > > If cpuidle itself is converted to threads then poll_source would
> > > automatically operate in a thread too, but this patch series doesn't
> > > change how the core cpuidle code works.
> >
> >
> > So networking su

Re: [RFC 0/3] cpuidle: add poll_source API and virtio vq polling

[Stefan Hajnoczi]

On Thu, Jul 22, 2021 at 05:04:57PM +0800, Jason Wang wrote:
> 
> 在 2021/7/21 下午5:41, Stefan Hajnoczi 写道:
> > On Wed, Jul 21, 2021 at 11:29:55AM +0800, Jason Wang wrote:
> > > 在 2021/7/14 上午12:19, Stefan Hajnoczi 写道:
> > > > These patches are not polished yet but I would like request feedback on 
> > > > this
> > > > approach and share performance results with you.
> > > > 
> > > > Idle CPUs tentatively enter a busy wait loop before halting when the 
> > > > cpuidle
> > > > haltpoll driver is enabled inside a virtual machine. This reduces wakeup
> > > > latency for events that occur soon after the vCPU becomes idle.
> > > > 
> > > > This patch series extends the cpuidle busy wait loop with the new 
> > > > poll_source
> > > > API so drivers can participate in polling. Such polling-aware drivers 
> > > > disable
> > > > their device's irq during the busy wait loop to avoid the cost of 
> > > > interrupts.
> > > > This reduces latency further than regular cpuidle haltpoll, which still 
> > > > relies
> > > > on irqs.
> > > > 
> > > > Virtio drivers are modified to use the poll_source API so all virtio 
> > > > device
> > > > types get this feature. The following virtio-blk fio benchmark results 
> > > > show the
> > > > improvement:
> > > > 
> > > >IOPS (numjobs=4, iodepth=1, 4 virtqueues)
> > > >  before   poll_source  io_poll
> > > > 4k randread167102  186049 (+11%)  186654 (+11%)
> > > > 4k randwrite   162204  181214 (+11%)  181850 (+12%)
> > > > 4k randrw  159520  177071 (+11%)  177928 (+11%)
> > > > 
> > > > The comparison against io_poll shows that cpuidle poll_source achieves
> > > > equivalent performance to the block layer's io_poll feature (which I
> > > > implemented in a separate patch series [1]).
> > > > 
> > > > The advantage of poll_source is that applications do not need to 
> > > > explicitly set
> > > > the RWF_HIPRI I/O request flag. The poll_source approach is attractive 
> > > > because
> > > > few applications actually use RWF_HIPRI and it takes advantage of CPU 
> > > > cycles we
> > > > would have spent in cpuidle haltpoll anyway.
> > > > 
> > > > The current series does not improve virtio-net. I haven't investigated 
> > > > deeply,
> > > > but it is possible that NAPI and poll_source do not combine. See the 
> > > > final
> > > > patch for a starting point on making the two work together.
> > > > 
> > > > I have not tried this on bare metal but it might help there too. The 
> > > > cost of
> > > > disabling a device's irq must be less than the savings from avoiding irq
> > > > handling for this optimization to make sense.
> > > > 
> > > > [1] 
> > > > https://lore.kernel.org/linux-block/20210520141305.355961-1-stefa...@redhat.com/
> > > 
> > > Hi Stefan:
> > > 
> > > Some questions:
> > > 
> > > 1) What's the advantages of introducing polling at virtio level instead of
> > > doing it at each subsystems? Polling in virtio level may only work well if
> > > all (or most) of the devices are virtio
> > I'm not sure I understand the question. cpuidle haltpoll benefits all
> > devices today, except it incurs interrupt latency. The poll_source API
> > eliminates the interrupt latency for drivers that can disable device
> > interrupts cheaply.
> > 
> > This patch adds poll_source to core virtio code so that all virtio
> > drivers get this feature for free. No driver-specific changes are
> > needed.
> > 
> > If you mean networking, block layer, etc by "subsystems" then there's
> > nothing those subsystems can do to help. Whether poll_source can be used
> > depends on the specific driver, not the subsystem. If you consider
> > drivers/virtio/ a subsystem, then that's exactly what the patch series
> > is doing.
> 
> 
> I meant, if we choose to use idle poll, we have some several choices:
> 
> 1) bus level (e.g the virtio)
> 2) subsystem level (e.g the networking and block)
> 
> I'm not sure which one is better.

This API is intended to be driver- or bus-level. I don't think
subsystems can do very much since they don't know the hardware
capabilities (cheap interrupt disabling) and in most cases there's no
advantage of plumbing it through subsystems when drivers can call the
API directly.

> > > 2) What's the advantages of using cpuidle instead of using a thread (and
> > > leverage the scheduler)?
> > In order to combine with the existing cpuidle infrastructure. No new
> > polling loop is introduced and no additional CPU cycles are spent on
> > polling.
> > 
> > If cpuidle itself is converted to threads then poll_source would
> > automatically operate in a thread too, but this patch series doesn't
> > change how the core cpuidle code works.
> 
> 
> So networking subsystem can use NAPI busy polling in the process context
> which means it can be leveraged by the scheduler.
> 
> I'm not sure it's a good idea to poll drivers for a specific bus in the
> general cpu idle layer.

Why? Maybe because the cpuidle execution environment is a little special?

> Anot

ICITS'22 - The 2022 International Conference on Information Technology & Systems | Costa Rica

[ML]

ICITS'22 - The 2022 International Conference on Information Technology & Systems
San Carlos, Costa Rica, 9 - 11 February 2022
http://icits.me 


SCOPE

ICITS'22 - The 2022 International Conference on Information Technology & 
Systems (http://icits.me ), to be held in Tecnológico de Costa 
Rica, Campus de San Carlos, Costa Rica, 9 - 11 February 2022, is an 
international forum for researchers and practitioners to present and discuss 
the most recent innovations, trends, results, experiences and concerns in the 
several perspectives of Information Technology & Systems.

We are pleased to invite you to submit your papers to ICITS'22. They can be 
written in English, Spanish or Portuguese. All submissions will be reviewed on 
the basis of relevance, originality, importance and clarity.


TOPICS

Submitted papers should be related with one or more of the main themes proposed 
for the Conference:

A) Information and Knowledge Management (IKM);
B) Organizational Models and Information Systems (OMIS);
C) Software and Systems Modeling (SSM);
D) Software Systems, Architectures, Applications and Tools (SSAAT);
E) Multimedia Systems and Applications (MSA);
F) Computer Networks, Mobility and Pervasive Systems (CNMPS);
G) Intelligent and Decision Support Systems (IDSS);
H) Big Data Analytics and Applications (BDAA);
I) Human-Computer Interaction (HCI);
J) Ethics, Computers and Security (ECS)
K) Health Informatics (HIS);
L) Information Technologies in Education (ITE);
M) Media, Applied Technology and Communication (MATC).


SUBMISSION and DECISION

Submitted papers written in English (until 10-page limit) must comply with the 
format of the Lecture Notes in Networks and Systems series (see Instructions 
for Authors at Springer Website), must not have been published before, not be 
under review for any other conference or publication and not include any 
information leading to the authors’ identification. Therefore, the authors’ 
names and affiliations should not be included in the version for evaluation by 
the Scientific Committee. This information should only be included in the 
camera-ready version, saved in Word or Latex format and also in PDF format. 
These files must be accompanied by the Consent to Publish form filled out, in a 
ZIP file, and uploaded at the conference management system.

Submitted papers written in Spanish or Portuguese (until 15-page limit) must 
comply with the format of RISTI - Revista Ibérica de Sistemas e Tecnologias de 
Informação (download instructions/template for authors in Spanish or 
Portuguese), must not have been published before, not be under review for any 
other conference or publication and not include any information leading to the 
authors’ identification. Therefore, the authors’ names and affiliations should 
not be included in the version for evaluation by the Scientific Committee. This 
information should only be included in the camera-ready version, saved in Word. 
These files must be uploaded at the conference management system in a ZIP file.

All papers will be subjected to a “double-blind review” by at least two members 
of the Scientific Committee.
Based on Scientific Committee evaluation, a paper can be rejected or accepted 
by the Conference Chairs. In the later case, it can be accepted as paper or 
poster.

The authors of papers accepted as posters must build and print a poster to be 
exhibited during the Conference. This poster must follow an A1 or A2 vertical 
format. The Conference can include Work Sessions where these posters are 
presented and orally discussed, with a 7 minute limit per poster.

The authors of accepted papers will have 15 minutes to present their work in a 
Conference Work Session; approximately 5 minutes of discussion will follow each 
presentation.


PUBLICATION and INDEXING

Papers accepted as posters are not published; they are only exhibited, 
presented and discussed during the conference.

To ensure that a paper accepted as paper is published, at least one of the 
authors must be fully registered by the 5th of November 2021, and the paper 
must comply with the suggested layout and page-limit. Additionally, all 
recommended changes must be addressed by the authors before they submit the 
camera-ready version.
No more than one paper per registration will be published. An extra fee must be 
paid for publication of additional papers, with a maximum of one additional 
paper per registration. One registration permits only the participation of one 
author in the conference.

Papers written in English and accepted and registered will be published in 
Proceedings by Springer, in a book of the Lecture Notes in Networks and Systems 
series, will  be submitted for indexation by SCOPUS, WoS

Re: [PATCH 4/4] vdpa: Add documentation for vdpa_alloc_device() macro

[Stefano Garzarella]

On Thu, Jul 15, 2021 at 04:00:26PM +0800, Xie Yongji wrote:

The return value of vdpa_alloc_device() macro is not very
clear, so that most of callers did the wrong check. Let's
add some comments to better document it.

Signed-off-by: Xie Yongji 
---
include/linux/vdpa.h | 11 +++
1 file changed, 11 insertions(+)

diff --git a/include/linux/vdpa.h b/include/linux/vdpa.h
index 3357ac98878d..8cfe49d201dd 100644
--- a/include/linux/vdpa.h
+++ b/include/linux/vdpa.h
@@ -277,6 +277,17 @@ struct vdpa_device *__vdpa_alloc_device(struct device 
*parent,
const struct vdpa_config_ops *config,
size_t size, const char *name);

+/**
+ * vdpa_alloc_device - allocate and initilaize a vDPA device
+ *
+ * @dev_struct: the type of the parent structure
+ * @member: the name of struct vdpa_device within the @dev_struct
+ * @parent: the parent device
+ * @config: the bus operations that is supported by this device
+ * @name: name of the vdpa device
+ *
+ * Return allocated data structure or ERR_PTR upon error
+ */
#define vdpa_alloc_device(dev_struct, member, parent, config, name)   \
  container_of(__vdpa_alloc_device( \
   parent, config, \
--
2.11.0



Reviewed-by: Stefano Garzarella 

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH 3/4] vDPA/ifcvf: Fix return value check for vdpa_alloc_device()

[Stefano Garzarella]

On Thu, Jul 15, 2021 at 04:00:25PM +0800, Xie Yongji wrote:

The vdpa_alloc_device() returns an error pointer upon
failure, not NULL. To handle the failure correctly, this
replaces NULL check with IS_ERR() check and propagate the
error upwards.

Fixes: 5a2414bc454e ("virtio: Intel IFC VF driver for VDPA")
Reported-by: Dan Carpenter 
Signed-off-by: Xie Yongji 
---
drivers/vdpa/ifcvf/ifcvf_main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/vdpa/ifcvf/ifcvf_main.c b/drivers/vdpa/ifcvf/ifcvf_main.c
index 21b78f1cd521..351c6cfb24c3 100644
--- a/drivers/vdpa/ifcvf/ifcvf_main.c
+++ b/drivers/vdpa/ifcvf/ifcvf_main.c
@@ -493,9 +493,9 @@ static int ifcvf_probe(struct pci_dev *pdev, const struct 
pci_device_id *id)

adapter = vdpa_alloc_device(struct ifcvf_adapter, vdpa,
dev, &ifc_vdpa_ops, NULL);
-   if (adapter == NULL) {
+   if (IS_ERR(adapter)) {
IFCVF_ERR(pdev, "Failed to allocate vDPA structure");
-   return -ENOMEM;
+   return PTR_ERR(adapter);
}

pci_set_master(pdev);
--
2.11.0



Reviewed-by: Stefano Garzarella 

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH 2/4] vp_vdpa: Fix return value check for vdpa_alloc_device()

[Stefano Garzarella]

On Thu, Jul 15, 2021 at 04:00:24PM +0800, Xie Yongji wrote:

The vdpa_alloc_device() returns an error pointer upon
failure, not NULL. To handle the failure correctly, this
replaces NULL check with IS_ERR() check and propagate the
error upwards.

Fixes: 64b9f64f80a6 ("vdpa: introduce virtio pci driver")
Reported-by: Dan Carpenter 
Signed-off-by: Xie Yongji 
---
drivers/vdpa/virtio_pci/vp_vdpa.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/vdpa/virtio_pci/vp_vdpa.c 
b/drivers/vdpa/virtio_pci/vp_vdpa.c
index 7b4a6396c553..fe0527329857 100644
--- a/drivers/vdpa/virtio_pci/vp_vdpa.c
+++ b/drivers/vdpa/virtio_pci/vp_vdpa.c
@@ -436,9 +436,9 @@ static int vp_vdpa_probe(struct pci_dev *pdev, const struct 
pci_device_id *id)

vp_vdpa = vdpa_alloc_device(struct vp_vdpa, vdpa,
dev, &vp_vdpa_ops, NULL);
-   if (vp_vdpa == NULL) {
+   if (IS_ERR(vp_vdpa)) {
dev_err(dev, "vp_vdpa: Failed to allocate vDPA structure\n");
-   return -ENOMEM;
+   return PTR_ERR(vp_vdpa);
}

mdev = &vp_vdpa->mdev;
--
2.11.0



Reviewed-by: Stefano Garzarella 

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH 1/4] vdpa_sim: Fix return value check for vdpa_alloc_device()

[Stefano Garzarella]

On Thu, Jul 15, 2021 at 04:00:23PM +0800, Xie Yongji wrote:

The vdpa_alloc_device() returns an error pointer upon
failure, not NULL. To handle the failure correctly, this
replaces NULL check with IS_ERR() check and propagate the
error upwards.

Fixes: 2c53d0f64c06 ("vdpasim: vDPA device simulator")
Reported-by: Dan Carpenter 
Signed-off-by: Xie Yongji 
---
drivers/vdpa/vdpa_sim/vdpa_sim.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim.c b/drivers/vdpa/vdpa_sim/vdpa_sim.c
index 14e024de5cbf..c621cf7feec0 100644
--- a/drivers/vdpa/vdpa_sim/vdpa_sim.c
+++ b/drivers/vdpa/vdpa_sim/vdpa_sim.c
@@ -251,8 +251,10 @@ struct vdpasim *vdpasim_create(struct vdpasim_dev_attr 
*dev_attr)

vdpasim = vdpa_alloc_device(struct vdpasim, vdpa, NULL, ops,
dev_attr->name);
-   if (!vdpasim)
+   if (IS_ERR(vdpasim)) {
+   ret = PTR_ERR(vdpasim);
goto err_alloc;
+   }

vdpasim->dev_attr = *dev_attr;
INIT_WORK(&vdpasim->work, dev_attr->work_fn);
--
2.11.0



Reviewed-by: Stefano Garzarella 

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH V3 2/5] dt-bindings: i2c: Add bindings for i2c-virtio

[Viresh Kumar]

On 26-07-21, 10:11, Arnd Bergmann wrote:
> On Mon, Jul 26, 2021 at 10:06 AM Arnd Bergmann  wrote:
> >
> > On Mon, Jul 26, 2021 at 6:52 AM Viresh Kumar  
> > wrote:
> > >
> > > This patch adds binding for virtio I2C device, it is based on
> > > virtio-device bindings.
> > >
> > > Acked-by: Wolfram Sang 
> > > Signed-off-by: Viresh Kumar 
> >
> > Reviewed-by: Arnd Bergmann 
> 
> Too quick, after seeing the same issue in the gpio binding I saw it here too:
> 
> > +i2c-virtio {
> > +compatible = "virtio,22";
> 
> The node name "i2c-virtio" looks wrong. According to
> https://github.com/devicetree-org/dt-schema/blob/master/schemas/i2c/i2c-controller.yaml,
> this needs to be plain "i2c".

Okay, I will move back to simple node names then.

Thanks.

-- 
viresh
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH v2 2/9] mm/memory_hotplug: introduce "auto-movable" online policy

[David Hildenbrand]

  
+struct auto_movable_stats {

+   unsigned long kernel_early_pages;
+   unsigned long movable_pages;
+};
+
+static void auto_movable_stats_account_zone(struct auto_movable_stats *stats,
+   struct zone *zone)
+{
+   if (zone_idx(zone) == ZONE_MOVABLE) {
+   stats->movable_pages += zone->present_pages;
+   } else {
+   /*
+* CMA pages (never on hotplugged memory) behave like
+* ZONE_MOVABLE.
+*/
+   stats->movable_pages += zone->cma_pages;
+   stats->kernel_early_pages += zone->present_early_pages;
+   stats->kernel_early_pages -= zone->cma_pages;
+   }
+}


The following on top to make it compile without CONFIG_CMA (thanks Randy):

diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index bfdaa28eb86f..fa1a0afd32ba 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -741,13 +741,15 @@ static void auto_movable_stats_account_zone(struct 
auto_movable_stats *stats,
if (zone_idx(zone) == ZONE_MOVABLE) {
stats->movable_pages += zone->present_pages;
} else {
+   stats->kernel_early_pages += zone->present_early_pages;
+#ifdef CONFIG_CMA
/*
 * CMA pages (never on hotplugged memory) behave like
 * ZONE_MOVABLE.
 */
stats->movable_pages += zone->cma_pages;
-   stats->kernel_early_pages += zone->present_early_pages;
stats->kernel_early_pages -= zone->cma_pages;
+#endif /* CONFIG_CMA */
}
 }
 struct auto_movable_group_stats {



--
Thanks,

David / dhildenb

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization