Hello,
This patchset adds vhost-user-gpio device's support in Qemu. The support for the same has already been added to virtio specification and Linux Kernel.
A Rust based backend is also in progress and is tested against this patchset:
https://github.com/rust-vmm/vhost-device/pull/76
-- Viresh
Viresh Kumar (2): hw/virtio: add boilerplate for vhost-user-gpio device hw/virtio: add vhost-user-gpio-pci boilerplate
hw/virtio/Kconfig | 5 + hw/virtio/meson.build | 2 + hw/virtio/vhost-user-gpio-pci.c | 69 ++++++ hw/virtio/vhost-user-gpio.c | 343 ++++++++++++++++++++++++++++ include/hw/virtio/vhost-user-gpio.h | 35 +++ 5 files changed, 454 insertions(+) create mode 100644 hw/virtio/vhost-user-gpio-pci.c create mode 100644 hw/virtio/vhost-user-gpio.c create mode 100644 include/hw/virtio/vhost-user-gpio.h
This creates the QEMU side of the vhost-user-gpio device which connects to the remote daemon. It is based of vhost-user-i2c code.
Signed-off-by: Viresh Kumar viresh.kumar@linaro.org --- hw/virtio/Kconfig | 5 + hw/virtio/meson.build | 1 + hw/virtio/vhost-user-gpio.c | 343 ++++++++++++++++++++++++++++ include/hw/virtio/vhost-user-gpio.h | 35 +++ 4 files changed, 384 insertions(+) create mode 100644 hw/virtio/vhost-user-gpio.c create mode 100644 include/hw/virtio/vhost-user-gpio.h
diff --git a/hw/virtio/Kconfig b/hw/virtio/Kconfig index c144d42f9bd0..b16a63609530 100644 --- a/hw/virtio/Kconfig +++ b/hw/virtio/Kconfig @@ -59,6 +59,11 @@ config VIRTIO_MEM depends on VIRTIO_MEM_SUPPORTED select MEM_DEVICE
+config VHOST_USER_GPIO + bool + default y + depends on VIRTIO && VHOST_USER + config VHOST_USER_I2C bool default y diff --git a/hw/virtio/meson.build b/hw/virtio/meson.build index 521f7d64a86a..c7e67adff337 100644 --- a/hw/virtio/meson.build +++ b/hw/virtio/meson.build @@ -29,6 +29,7 @@ virtio_ss.add(when: 'CONFIG_VHOST_USER_I2C', if_true: files('vhost-user-i2c.c')) virtio_ss.add(when: ['CONFIG_VIRTIO_PCI', 'CONFIG_VHOST_USER_I2C'], if_true: files('vhost-user-i2c-pci.c')) virtio_ss.add(when: 'CONFIG_VHOST_USER_RNG', if_true: files('vhost-user-rng.c')) virtio_ss.add(when: ['CONFIG_VHOST_USER_RNG', 'CONFIG_VIRTIO_PCI'], if_true: files('vhost-user-rng-pci.c')) +virtio_ss.add(when: 'CONFIG_VHOST_USER_GPIO', if_true: files('vhost-user-gpio.c'))
virtio_pci_ss = ss.source_set() virtio_pci_ss.add(when: 'CONFIG_VHOST_VSOCK', if_true: files('vhost-vsock-pci.c')) diff --git a/hw/virtio/vhost-user-gpio.c b/hw/virtio/vhost-user-gpio.c new file mode 100644 index 000000000000..c5f67c0104a9 --- /dev/null +++ b/hw/virtio/vhost-user-gpio.c @@ -0,0 +1,343 @@ +/* + * Vhost-user GPIO virtio device + * + * Copyright (c) 2022 Viresh Kumar viresh.kumar@linaro.org + * + * SPDX-License-Identifier: GPL-2.0-or-later + */ + +#include "qemu/osdep.h" +#include "qapi/error.h" +#include "hw/qdev-properties.h" +#include "hw/virtio/virtio-bus.h" +#include "hw/virtio/vhost-user-gpio.h" +#include "qemu/error-report.h" +#include "standard-headers/linux/virtio_ids.h" + +static const int feature_bits[] = { + VIRTIO_GPIO_F_IRQ +}; + +static void vu_gpio_get_config(VirtIODevice *vdev, uint8_t *config) +{ + VHostUserGPIO *gpio = VHOST_USER_GPIO(vdev); + + memcpy(config, &gpio->config, sizeof(gpio->config)); +} + +static int vu_gpio_config_notifier(struct vhost_dev *dev) +{ + VHostUserGPIO *gpio = VHOST_USER_GPIO(dev->vdev); + + memcpy(dev->vdev->config, &gpio->config, sizeof(gpio->config)); + virtio_notify_config(dev->vdev); + + return 0; +} + +const VhostDevConfigOps gpio_ops = { + .vhost_dev_config_notifier = vu_gpio_config_notifier, +}; + +static int vu_gpio_start(VirtIODevice *vdev) +{ + BusState *qbus = BUS(qdev_get_parent_bus(DEVICE(vdev))); + VirtioBusClass *k = VIRTIO_BUS_GET_CLASS(qbus); + VHostUserGPIO *gpio = VHOST_USER_GPIO(vdev); + int ret, i; + + if (!k->set_guest_notifiers) { + error_report("binding does not support guest notifiers"); + return -ENOSYS; + } + + ret = vhost_dev_enable_notifiers(&gpio->vhost_dev, vdev); + if (ret < 0) { + error_report("Error enabling host notifiers: %d", ret); + return ret; + } + + ret = k->set_guest_notifiers(qbus->parent, gpio->vhost_dev.nvqs, true); + if (ret < 0) { + error_report("Error binding guest notifier: %d", ret); + goto err_host_notifiers; + } + + gpio->vhost_dev.acked_features = vdev->guest_features; + + ret = vhost_dev_start(&gpio->vhost_dev, vdev); + if (ret < 0) { + error_report("Error starting vhost-user-gpio: %d", ret); + goto err_guest_notifiers; + } + + /* + * guest_notifier_mask/pending not used yet, so just unmask + * everything here. virtio-pci will do the right thing by + * enabling/disabling irqfd. + */ + for (i = 0; i < gpio->vhost_dev.nvqs; i++) { + vhost_virtqueue_mask(&gpio->vhost_dev, vdev, i, false); + } + + return 0; + +err_guest_notifiers: + k->set_guest_notifiers(qbus->parent, gpio->vhost_dev.nvqs, false); +err_host_notifiers: + vhost_dev_disable_notifiers(&gpio->vhost_dev, vdev); + + return ret; +} + +static void vu_gpio_stop(VirtIODevice *vdev) +{ + VHostUserGPIO *gpio = VHOST_USER_GPIO(vdev); + BusState *qbus = BUS(qdev_get_parent_bus(DEVICE(vdev))); + VirtioBusClass *k = VIRTIO_BUS_GET_CLASS(qbus); + int ret; + + if (!k->set_guest_notifiers) { + return; + } + + vhost_dev_stop(&gpio->vhost_dev, vdev); + + ret = k->set_guest_notifiers(qbus->parent, gpio->vhost_dev.nvqs, false); + if (ret < 0) { + error_report("vhost guest notifier cleanup failed: %d", ret); + return; + } + + vhost_dev_disable_notifiers(&gpio->vhost_dev, vdev); +} + +static void vu_gpio_set_status(VirtIODevice *vdev, uint8_t status) +{ + VHostUserGPIO *gpio = VHOST_USER_GPIO(vdev); + bool should_start = status & VIRTIO_CONFIG_S_DRIVER_OK; + + if (!vdev->vm_running) { + should_start = false; + } + + if (!gpio->connected) { + return; + } + + if (gpio->vhost_dev.started == should_start) { + return; + } + + if (should_start) { + if (vu_gpio_start(vdev)) { + qemu_chr_fe_disconnect(&gpio->chardev); + } + } else { + vu_gpio_stop(vdev); + } +} + +static uint64_t vu_gpio_get_features(VirtIODevice *vdev, + uint64_t requested_features, Error **errp) +{ + VHostUserGPIO *gpio = VHOST_USER_GPIO(vdev); + + virtio_add_feature(&requested_features, VIRTIO_GPIO_F_IRQ); + return vhost_get_features(&gpio->vhost_dev, feature_bits, requested_features); +} + +static void vu_gpio_handle_output(VirtIODevice *vdev, VirtQueue *vq) +{ + /* + * Not normally called; it's the daemon that handles the queue; + * however virtio's cleanup path can call this. + */ +} + +static void vu_gpio_guest_notifier_mask(VirtIODevice *vdev, int idx, bool mask) +{ + VHostUserGPIO *gpio = VHOST_USER_GPIO(vdev); + + vhost_virtqueue_mask(&gpio->vhost_dev, vdev, idx, mask); +} + +static void do_vhost_user_cleanup(VirtIODevice *vdev, VHostUserGPIO *gpio) +{ + virtio_delete_queue(gpio->command_vq); + virtio_delete_queue(gpio->interrupt_vq); + g_free(gpio->vhost_dev.vqs); + gpio->vhost_dev.vqs = NULL; + virtio_cleanup(vdev); + vhost_user_cleanup(&gpio->vhost_user); +} + +static int vu_gpio_connect(DeviceState *dev) +{ + VirtIODevice *vdev = VIRTIO_DEVICE(dev); + VHostUserGPIO *gpio = VHOST_USER_GPIO(vdev); + Error *local_err = NULL; + int ret; + + if (gpio->connected) { + return 0; + } + gpio->connected = true; + + vhost_dev_set_config_notifier(&gpio->vhost_dev, &gpio_ops); + + ret = vhost_dev_init(&gpio->vhost_dev, &gpio->vhost_user, + VHOST_BACKEND_TYPE_USER, 0, &local_err); + if (ret < 0) { + error_report("vhost-user-gpio: vhost initialization failed: %s", + strerror(-ret)); + return ret; + } + + /* restore vhost state */ + if (virtio_device_started(vdev, vdev->status)) { + vu_gpio_start(vdev); + } + + return 0; +} + +static void vu_gpio_disconnect(DeviceState *dev) +{ + VirtIODevice *vdev = VIRTIO_DEVICE(dev); + VHostUserGPIO *gpio = VHOST_USER_GPIO(vdev); + + if (!gpio->connected) { + return; + } + gpio->connected = false; + + vu_gpio_stop(vdev); + vhost_dev_cleanup(&gpio->vhost_dev); +} + +static void vu_gpio_event(void *opaque, QEMUChrEvent event) +{ + DeviceState *dev = opaque; + VirtIODevice *vdev = VIRTIO_DEVICE(dev); + VHostUserGPIO *gpio = VHOST_USER_GPIO(vdev); + + switch (event) { + case CHR_EVENT_OPENED: + if (vu_gpio_connect(dev) < 0) { + qemu_chr_fe_disconnect(&gpio->chardev); + return; + } + break; + case CHR_EVENT_CLOSED: + vu_gpio_disconnect(dev); + break; + case CHR_EVENT_BREAK: + case CHR_EVENT_MUX_IN: + case CHR_EVENT_MUX_OUT: + /* Ignore */ + break; + } +} + +static void vu_gpio_device_realize(DeviceState *dev, Error **errp) +{ + VirtIODevice *vdev = VIRTIO_DEVICE(dev); + VHostUserGPIO *gpio = VHOST_USER_GPIO(dev); + Error *err = NULL; + int ret; + + if (!gpio->chardev.chr) { + error_setg(errp, "vhost-user-gpio: chardev is mandatory"); + return; + } + + if (!vhost_user_init(&gpio->vhost_user, &gpio->chardev, errp)) { + return; + } + + virtio_init(vdev, "vhost-user-gpio", VIRTIO_ID_GPIO, sizeof(gpio->config)); + + gpio->vhost_dev.nvqs = 2; + gpio->command_vq = virtio_add_queue(vdev, 256, vu_gpio_handle_output); + gpio->interrupt_vq = virtio_add_queue(vdev, 256, vu_gpio_handle_output); + gpio->vhost_dev.vqs = g_new0(struct vhost_virtqueue, gpio->vhost_dev.nvqs); + + gpio->connected = false; + + qemu_chr_fe_set_handlers(&gpio->chardev, NULL, NULL, vu_gpio_event, NULL, + dev, NULL, true); + +reconnect: + if (qemu_chr_fe_wait_connected(&gpio->chardev, &err) < 0) { + error_report_err(err); + do_vhost_user_cleanup(vdev, gpio); + return; + } + + /* check whether vhost_user_gpio_connect() failed or not */ + if (!gpio->connected) { + goto reconnect; + } + + ret = vhost_dev_get_config(&gpio->vhost_dev, (uint8_t *)&gpio->config, + sizeof(gpio->config), errp); + if (ret < 0) { + error_report("vhost-user-gpio: get config failed"); + goto reconnect; + } + + return; +} + +static void vu_gpio_device_unrealize(DeviceState *dev) +{ + VirtIODevice *vdev = VIRTIO_DEVICE(dev); + VHostUserGPIO *gpio = VHOST_USER_GPIO(dev); + + vu_gpio_set_status(vdev, 0); + qemu_chr_fe_set_handlers(&gpio->chardev, NULL, NULL, NULL, NULL, NULL, NULL, + false); + vhost_dev_cleanup(&gpio->vhost_dev); + do_vhost_user_cleanup(vdev, gpio); +} + +static const VMStateDescription vu_gpio_vmstate = { + .name = "vhost-user-gpio", + .unmigratable = 1, +}; + +static Property vu_gpio_properties[] = { + DEFINE_PROP_CHR("chardev", VHostUserGPIO, chardev), + DEFINE_PROP_END_OF_LIST(), +}; + +static void vu_gpio_class_init(ObjectClass *klass, void *data) +{ + DeviceClass *dc = DEVICE_CLASS(klass); + VirtioDeviceClass *vdc = VIRTIO_DEVICE_CLASS(klass); + + device_class_set_props(dc, vu_gpio_properties); + dc->vmsd = &vu_gpio_vmstate; + set_bit(DEVICE_CATEGORY_INPUT, dc->categories); + vdc->realize = vu_gpio_device_realize; + vdc->unrealize = vu_gpio_device_unrealize; + vdc->get_features = vu_gpio_get_features; + vdc->get_config = vu_gpio_get_config; + vdc->set_status = vu_gpio_set_status; + vdc->guest_notifier_mask = vu_gpio_guest_notifier_mask; +} + +static const TypeInfo vu_gpio_info = { + .name = TYPE_VHOST_USER_GPIO, + .parent = TYPE_VIRTIO_DEVICE, + .instance_size = sizeof(VHostUserGPIO), + .class_init = vu_gpio_class_init, +}; + +static void vu_gpio_register_types(void) +{ + type_register_static(&vu_gpio_info); +} + +type_init(vu_gpio_register_types) diff --git a/include/hw/virtio/vhost-user-gpio.h b/include/hw/virtio/vhost-user-gpio.h new file mode 100644 index 000000000000..afeb56f53e99 --- /dev/null +++ b/include/hw/virtio/vhost-user-gpio.h @@ -0,0 +1,35 @@ +/* + * Vhost-user GPIO virtio device + * + * Copyright (c) 2021 Viresh Kumar viresh.kumar@linaro.org + * + * SPDX-License-Identifier: GPL-2.0-or-later + */ + +#ifndef _QEMU_VHOST_USER_GPIO_H +#define _QEMU_VHOST_USER_GPIO_H + +#include "hw/virtio/virtio.h" +#include "hw/virtio/vhost.h" +#include "hw/virtio/vhost-user.h" +#include "standard-headers/linux/virtio_gpio.h" +#include "chardev/char-fe.h" + +#define TYPE_VHOST_USER_GPIO "vhost-user-gpio-device" +OBJECT_DECLARE_SIMPLE_TYPE(VHostUserGPIO, VHOST_USER_GPIO); + +struct VHostUserGPIO { + /*< private >*/ + VirtIODevice parent; + CharBackend chardev; + struct virtio_gpio_config config; + struct vhost_virtqueue *vhost_vq; + struct vhost_dev vhost_dev; + VhostUserState vhost_user; + VirtQueue *command_vq; + VirtQueue *interrupt_vq; + bool connected; + /*< public >*/ +}; + +#endif /* _QEMU_VHOST_USER_GPIO_H */
Viresh Kumar viresh.kumar@linaro.org writes:
This creates the QEMU side of the vhost-user-gpio device which connects to the remote daemon. It is based of vhost-user-i2c code.
Signed-off-by: Viresh Kumar viresh.kumar@linaro.org
Reviewed-by: Alex Bennée alex.bennee@linaro.org
Viresh Kumar viresh.kumar@linaro.org writes:
This creates the QEMU side of the vhost-user-gpio device which connects to the remote daemon. It is based of vhost-user-i2c code.
Signed-off-by: Viresh Kumar viresh.kumar@linaro.org
<snip>
+++ b/include/hw/virtio/vhost-user-gpio.h @@ -0,0 +1,35 @@ +/*
- Vhost-user GPIO virtio device
- Copyright (c) 2021 Viresh Kumar viresh.kumar@linaro.org
- SPDX-License-Identifier: GPL-2.0-or-later
- */
+#ifndef _QEMU_VHOST_USER_GPIO_H +#define _QEMU_VHOST_USER_GPIO_H
+#include "hw/virtio/virtio.h" +#include "hw/virtio/vhost.h" +#include "hw/virtio/vhost-user.h" +#include "standard-headers/linux/virtio_gpio.h"
Hmm this fails:
In file included from ../../hw/virtio/vhost-user-gpio.c:13: /home/alex/lsrc/qemu.git/include/hw/virtio/vhost-user-gpio.h:15:10: fatal error: standard-headers/linux/virtio_gpio.h: No such file or directory 15 | #include "standard-headers/linux/virtio_gpio.h" | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ compilation terminated.
The usual solution is to create a patch that imports the headers using:
./scripts/update-linux-headers.sh
either from the current mainline (or your own tree if the feature is in flight) and mark the patch clearly as not for merging.
On 14-01-22, 14:06, Alex Bennée wrote:
Viresh Kumar viresh.kumar@linaro.org writes:
This creates the QEMU side of the vhost-user-gpio device which connects to the remote daemon. It is based of vhost-user-i2c code.
Signed-off-by: Viresh Kumar viresh.kumar@linaro.org
<snip> > +++ b/include/hw/virtio/vhost-user-gpio.h > @@ -0,0 +1,35 @@ > +/* > + * Vhost-user GPIO virtio device > + * > + * Copyright (c) 2021 Viresh Kumar <viresh.kumar@linaro.org> > + * > + * SPDX-License-Identifier: GPL-2.0-or-later > + */ > + > +#ifndef _QEMU_VHOST_USER_GPIO_H > +#define _QEMU_VHOST_USER_GPIO_H > + > +#include "hw/virtio/virtio.h" > +#include "hw/virtio/vhost.h" > +#include "hw/virtio/vhost-user.h" > +#include "standard-headers/linux/virtio_gpio.h"
Hmm this fails:
In file included from ../../hw/virtio/vhost-user-gpio.c:13: /home/alex/lsrc/qemu.git/include/hw/virtio/vhost-user-gpio.h:15:10: fatal error: standard-headers/linux/virtio_gpio.h: No such file or directory 15 | #include "standard-headers/linux/virtio_gpio.h" | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ compilation terminated.
The usual solution is to create a patch that imports the headers using:
./scripts/update-linux-headers.sh
either from the current mainline (or your own tree if the feature is in flight) and mark the patch clearly as not for merging.
I have that patch with me and I planned to mention it in the cover-letter, but completely failed while sending it.
Should I resend this with the NOT-TO-BE-APPLIED patch now ? Everything is in mainline, so the committer just needs to run scripts/update-linux-headers.sh.
Viresh Kumar viresh.kumar@linaro.org writes:
On 14-01-22, 14:06, Alex Bennée wrote:
Viresh Kumar viresh.kumar@linaro.org writes:
This creates the QEMU side of the vhost-user-gpio device which connects to the remote daemon. It is based of vhost-user-i2c code.
Signed-off-by: Viresh Kumar viresh.kumar@linaro.org
<snip> > +++ b/include/hw/virtio/vhost-user-gpio.h > @@ -0,0 +1,35 @@ > +/* > + * Vhost-user GPIO virtio device > + * > + * Copyright (c) 2021 Viresh Kumar <viresh.kumar@linaro.org> > + * > + * SPDX-License-Identifier: GPL-2.0-or-later > + */ > + > +#ifndef _QEMU_VHOST_USER_GPIO_H > +#define _QEMU_VHOST_USER_GPIO_H > + > +#include "hw/virtio/virtio.h" > +#include "hw/virtio/vhost.h" > +#include "hw/virtio/vhost-user.h" > +#include "standard-headers/linux/virtio_gpio.h"
Hmm this fails:
In file included from ../../hw/virtio/vhost-user-gpio.c:13: /home/alex/lsrc/qemu.git/include/hw/virtio/vhost-user-gpio.h:15:10: fatal error: standard-headers/linux/virtio_gpio.h: No such file or directory 15 | #include "standard-headers/linux/virtio_gpio.h" | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ compilation terminated.
The usual solution is to create a patch that imports the headers using:
./scripts/update-linux-headers.sh
either from the current mainline (or your own tree if the feature is in flight) and mark the patch clearly as not for merging.
I have that patch with me and I planned to mention it in the cover-letter, but completely failed while sending it.
Should I resend this with the NOT-TO-BE-APPLIED patch now ? Everything is in mainline, so the committer just needs to run scripts/update-linux-headers.sh.
If it's a released version of mainline even better because you can just include the patch generated from a clean release and it can get merged.
This allows is to instantiate a vhost-user-gpio device as part of a PCI bus. It is mostly boilerplate which looks pretty similar to the vhost-user-fs-pci device.
Signed-off-by: Viresh Kumar viresh.kumar@linaro.org --- hw/virtio/meson.build | 1 + hw/virtio/vhost-user-gpio-pci.c | 69 +++++++++++++++++++++++++++++++++ 2 files changed, 70 insertions(+) create mode 100644 hw/virtio/vhost-user-gpio-pci.c
diff --git a/hw/virtio/meson.build b/hw/virtio/meson.build index c7e67adff337..fe6a4e9acb2a 100644 --- a/hw/virtio/meson.build +++ b/hw/virtio/meson.build @@ -30,6 +30,7 @@ virtio_ss.add(when: ['CONFIG_VIRTIO_PCI', 'CONFIG_VHOST_USER_I2C'], if_true: fil virtio_ss.add(when: 'CONFIG_VHOST_USER_RNG', if_true: files('vhost-user-rng.c')) virtio_ss.add(when: ['CONFIG_VHOST_USER_RNG', 'CONFIG_VIRTIO_PCI'], if_true: files('vhost-user-rng-pci.c')) virtio_ss.add(when: 'CONFIG_VHOST_USER_GPIO', if_true: files('vhost-user-gpio.c')) +virtio_ss.add(when: ['CONFIG_VIRTIO_PCI', 'CONFIG_VHOST_USER_GPIO'], if_true: files('vhost-user-gpio-pci.c'))
virtio_pci_ss = ss.source_set() virtio_pci_ss.add(when: 'CONFIG_VHOST_VSOCK', if_true: files('vhost-vsock-pci.c')) diff --git a/hw/virtio/vhost-user-gpio-pci.c b/hw/virtio/vhost-user-gpio-pci.c new file mode 100644 index 000000000000..8dd042d5e1c1 --- /dev/null +++ b/hw/virtio/vhost-user-gpio-pci.c @@ -0,0 +1,69 @@ +/* + * Vhost-user gpio virtio device PCI glue + * + * Copyright (c) 2022 Viresh Kumar viresh.kumar@linaro.org + * + * SPDX-License-Identifier: GPL-2.0-or-later + */ + +#include "qemu/osdep.h" +#include "hw/qdev-properties.h" +#include "hw/virtio/vhost-user-gpio.h" +#include "virtio-pci.h" + +struct VHostUserGPIOPCI { + VirtIOPCIProxy parent_obj; + VHostUserGPIO vdev; +}; + +typedef struct VHostUserGPIOPCI VHostUserGPIOPCI; + +#define TYPE_VHOST_USER_GPIO_PCI "vhost-user-gpio-pci-base" + +DECLARE_INSTANCE_CHECKER(VHostUserGPIOPCI, VHOST_USER_GPIO_PCI, + TYPE_VHOST_USER_GPIO_PCI) + +static void vhost_user_gpio_pci_realize(VirtIOPCIProxy *vpci_dev, Error **errp) +{ + VHostUserGPIOPCI *dev = VHOST_USER_GPIO_PCI(vpci_dev); + DeviceState *vdev = DEVICE(&dev->vdev); + + vpci_dev->nvectors = 1; + qdev_realize(vdev, BUS(&vpci_dev->bus), errp); +} + +static void vhost_user_gpio_pci_class_init(ObjectClass *klass, void *data) +{ + DeviceClass *dc = DEVICE_CLASS(klass); + VirtioPCIClass *k = VIRTIO_PCI_CLASS(klass); + PCIDeviceClass *pcidev_k = PCI_DEVICE_CLASS(klass); + k->realize = vhost_user_gpio_pci_realize; + set_bit(DEVICE_CATEGORY_INPUT, dc->categories); + pcidev_k->vendor_id = PCI_VENDOR_ID_REDHAT_QUMRANET; + pcidev_k->device_id = 0; /* Set by virtio-pci based on virtio id */ + pcidev_k->revision = 0x00; + pcidev_k->class_id = PCI_CLASS_COMMUNICATION_OTHER; +} + +static void vhost_user_gpio_pci_instance_init(Object *obj) +{ + VHostUserGPIOPCI *dev = VHOST_USER_GPIO_PCI(obj); + + virtio_instance_init_common(obj, &dev->vdev, sizeof(dev->vdev), + TYPE_VHOST_USER_GPIO); +} + +static const VirtioPCIDeviceTypeInfo vhost_user_gpio_pci_info = { + .base_name = TYPE_VHOST_USER_GPIO_PCI, + .non_transitional_name = "vhost-user-gpio-pci", + .instance_size = sizeof(VHostUserGPIOPCI), + .instance_init = vhost_user_gpio_pci_instance_init, + .class_init = vhost_user_gpio_pci_class_init, +}; + +static void vhost_user_gpio_pci_register(void) +{ + virtio_pci_types_register(&vhost_user_gpio_pci_info); +} + +type_init(vhost_user_gpio_pci_register);
Viresh Kumar viresh.kumar@linaro.org writes:
This allows is to instantiate a vhost-user-gpio device as part of a PCI bus. It is mostly boilerplate which looks pretty similar to the vhost-user-fs-pci device.
Signed-off-by: Viresh Kumar viresh.kumar@linaro.org
Reviewed-by: Alex Bennée alex.bennee@linaro.org
On Wed, Jan 12, 2022 at 05:04:57PM +0530, Viresh Kumar wrote:
Hello,
This patchset adds vhost-user-gpio device's support in Qemu. The support for the same has already been added to virtio specification and Linux Kernel.
A Rust based backend is also in progress and is tested against this patchset:
I'm reluctant to add this with no tests in tree. Want to write a minimal libhost-user based backend? We also need some maintainers to step up.
-- Viresh
Viresh Kumar (2): hw/virtio: add boilerplate for vhost-user-gpio device hw/virtio: add vhost-user-gpio-pci boilerplate
hw/virtio/Kconfig | 5 + hw/virtio/meson.build | 2 + hw/virtio/vhost-user-gpio-pci.c | 69 ++++++ hw/virtio/vhost-user-gpio.c | 343 ++++++++++++++++++++++++++++ include/hw/virtio/vhost-user-gpio.h | 35 +++ 5 files changed, 454 insertions(+) create mode 100644 hw/virtio/vhost-user-gpio-pci.c create mode 100644 hw/virtio/vhost-user-gpio.c create mode 100644 include/hw/virtio/vhost-user-gpio.h
-- 2.31.1.272.g89b43f80a514
"Michael S. Tsirkin" mst@redhat.com writes:
On Wed, Jan 12, 2022 at 05:04:57PM +0530, Viresh Kumar wrote:
Hello,
This patchset adds vhost-user-gpio device's support in Qemu. The support for the same has already been added to virtio specification and Linux Kernel.
A Rust based backend is also in progress and is tested against this patchset:
I'm reluctant to add this with no tests in tree. Want to write a minimal libhost-user based backend?
This is going to be a problem going forward as we have more out-of-tree backends written as a first preference. While the first couple of vhost devices have C implementations in contrib before we worked on the rust version I think we are getting to the point of skipping a first C version for future devices.
However I notice we have qtest/vhost-user-test.c so would that be enough to ensure we can instantiate the device and a basic vhost-user initialisation sequence doesn't cause it to crap out. This obviously won't be exercising the virtq processing itself but does that really exercise any of QEMU's boilerplate anyway?
We also need some maintainers to step up.
You mean more reviewers for the vhost and virtio sections of QEMU's maintainers?
-- Viresh
Viresh Kumar (2): hw/virtio: add boilerplate for vhost-user-gpio device hw/virtio: add vhost-user-gpio-pci boilerplate
hw/virtio/Kconfig | 5 + hw/virtio/meson.build | 2 + hw/virtio/vhost-user-gpio-pci.c | 69 ++++++ hw/virtio/vhost-user-gpio.c | 343 ++++++++++++++++++++++++++++ include/hw/virtio/vhost-user-gpio.h | 35 +++ 5 files changed, 454 insertions(+) create mode 100644 hw/virtio/vhost-user-gpio-pci.c create mode 100644 hw/virtio/vhost-user-gpio.c create mode 100644 include/hw/virtio/vhost-user-gpio.h
-- 2.31.1.272.g89b43f80a514
On 17-01-22, 10:11, Alex Bennée wrote:
"Michael S. Tsirkin" mst@redhat.com writes:
On Wed, Jan 12, 2022 at 05:04:57PM +0530, Viresh Kumar wrote:
Hello,
This patchset adds vhost-user-gpio device's support in Qemu. The support for the same has already been added to virtio specification and Linux Kernel.
A Rust based backend is also in progress and is tested against this patchset:
I'm reluctant to add this with no tests in tree. Want to write a minimal libhost-user based backend?
I actually have one already, that I wrote before attempting the Rust counterpart, but never upstreamed as I am not sure if anyone is ever going to use it, as I am not. And I thought what's the point of merging code which I will never end up using.
I am not sure what test I can add here to make sure this doesn't breaks in future though.
This is going to be a problem going forward as we have more out-of-tree backends written as a first preference. While the first couple of vhost devices have C implementations in contrib before we worked on the rust version I think we are getting to the point of skipping a first C version for future devices.
However I notice we have qtest/vhost-user-test.c so would that be enough to ensure we can instantiate the device and a basic vhost-user initialisation sequence doesn't cause it to crap out. This obviously won't be exercising the virtq processing itself but does that really exercise any of QEMU's boilerplate anyway?
We also need some maintainers to step up.
You mean more reviewers for the vhost and virtio sections of QEMU's maintainers?
And I too was waiting for replies on these. I can surely write something up if you guys feel there is a need. I just want to understand it better.
On Thu, Jan 20, 2022 at 09:32:34AM +0530, Viresh Kumar wrote:
On 17-01-22, 10:11, Alex Bennée wrote:
"Michael S. Tsirkin" mst@redhat.com writes:
On Wed, Jan 12, 2022 at 05:04:57PM +0530, Viresh Kumar wrote:
Hello,
This patchset adds vhost-user-gpio device's support in Qemu. The support for the same has already been added to virtio specification and Linux Kernel.
A Rust based backend is also in progress and is tested against this patchset:
I'm reluctant to add this with no tests in tree. Want to write a minimal libhost-user based backend?
I actually have one already, that I wrote before attempting the Rust counterpart, but never upstreamed as I am not sure if anyone is ever going to use it, as I am not. And I thought what's the point of merging code which I will never end up using.
I am not sure what test I can add here to make sure this doesn't breaks in future though.
something that executes with make check.
This is going to be a problem going forward as we have more out-of-tree backends written as a first preference. While the first couple of vhost devices have C implementations in contrib before we worked on the rust version I think we are getting to the point of skipping a first C version for future devices.
However I notice we have qtest/vhost-user-test.c so would that be enough to ensure we can instantiate the device and a basic vhost-user initialisation sequence doesn't cause it to crap out. This obviously won't be exercising the virtq processing itself but does that really exercise any of QEMU's boilerplate anyway?
We also need some maintainers to step up.
You mean more reviewers for the vhost and virtio sections of QEMU's maintainers?
And I too was waiting for replies on these. I can surely write something up if you guys feel there is a need. I just want to understand it better.
-- viresh
"Michael S. Tsirkin" mst@redhat.com writes:
On Thu, Jan 20, 2022 at 09:32:34AM +0530, Viresh Kumar wrote:
On 17-01-22, 10:11, Alex Bennée wrote:
"Michael S. Tsirkin" mst@redhat.com writes:
On Wed, Jan 12, 2022 at 05:04:57PM +0530, Viresh Kumar wrote:
Hello,
This patchset adds vhost-user-gpio device's support in Qemu. The support for the same has already been added to virtio specification and Linux Kernel.
A Rust based backend is also in progress and is tested against this patchset:
I'm reluctant to add this with no tests in tree. Want to write a minimal libhost-user based backend?
I actually have one already, that I wrote before attempting the Rust counterpart, but never upstreamed as I am not sure if anyone is ever going to use it, as I am not. And I thought what's the point of merging code which I will never end up using.
I am not sure what test I can add here to make sure this doesn't breaks in future though.
something that executes with make check.
With Eric's latest series (20220118203833.316741-1-eric.auger@redhat.com) we are already exercising most of the PCI code:
➜ gcov ./libqemu-aarch64-softmmu.fa.p/hw_virtio_vhost-user-gpio.c.gcda File '../../hw/virtio/vhost-user-gpio.c' Lines executed:10.43% of 163 Creating 'vhost-user-gpio.c.gcov'
File '/home/alex/lsrc/qemu.git/include/qemu/bitops.h' Lines executed:100.00% of 4 Creating 'bitops.h.gcov'
File '/home/alex/lsrc/qemu.git/include/hw/virtio/virtio.h' Lines executed:12.50% of 8 Creating 'virtio.h.gcov'
File '/home/alex/lsrc/qemu.git/include/hw/virtio/vhost-user-gpio.h' Lines executed:0.00% of 1 Creating 'vhost-user-gpio.h.gcov'
File '/home/alex/lsrc/qemu.git/include/hw/virtio/virtio-bus.h' Lines executed:0.00% of 1 Creating 'virtio-bus.h.gcov'
File '/home/alex/lsrc/qemu.git/include/hw/qdev-core.h' Lines executed:50.00% of 2 Creating 'qdev-core.h.gcov'
🕙15:40:35 alex@zen:qemu.git/builds/gprof on review/virtio-gpio-boilerplate [$?] ➜ gcov ./libqemu-aarch64-softmmu.fa.p/hw_virtio_vhost-user-gpio-pci.c.gcda File '../../hw/virtio/vhost-user-gpio-pci.c' Lines executed:76.92% of 26 Creating 'vhost-user-gpio-pci.c.gcov'
File '/home/alex/lsrc/qemu.git/include/qemu/bitops.h' Lines executed:100.00% of 4 Creating 'bitops.h.gcov'
File '../../hw/virtio/virtio-pci.h' Lines executed:100.00% of 1 Creating 'virtio-pci.h.gcov'
File '/home/alex/lsrc/qemu.git/include/hw/pci/pci.h' Lines executed:100.00% of 1 Creating 'pci.h.gcov'
File '/home/alex/lsrc/qemu.git/include/hw/qdev-core.h' Lines executed:50.00% of 2 Creating 'qdev-core.h.gcov'
So I think if we add the runes to ensure we instantiate both types explicitly I think we will have enough coverage.
On Mon, Jan 17, 2022 at 10:11:21AM +0000, Alex Bennée wrote:
"Michael S. Tsirkin" mst@redhat.com writes:
On Wed, Jan 12, 2022 at 05:04:57PM +0530, Viresh Kumar wrote:
Hello,
This patchset adds vhost-user-gpio device's support in Qemu. The support for the same has already been added to virtio specification and Linux Kernel.
A Rust based backend is also in progress and is tested against this patchset:
I'm reluctant to add this with no tests in tree. Want to write a minimal libhost-user based backend?
This is going to be a problem going forward as we have more out-of-tree backends written as a first preference. While the first couple of vhost devices have C implementations in contrib before we worked on the rust version I think we are getting to the point of skipping a first C version for future devices.
Not sure what to do then. Integrate using submodules somehow?
However I notice we have qtest/vhost-user-test.c so would that be enough to ensure we can instantiate the device and a basic vhost-user initialisation sequence doesn't cause it to crap out. This obviously won't be exercising the virtq processing itself but does that really exercise any of QEMU's boilerplate anyway?
we do have tests e.g. for network based on vhost-user, yes.
We also need some maintainers to step up.
You mean more reviewers for the vhost and virtio sections of QEMU's maintainers?
-- Viresh
Viresh Kumar (2): hw/virtio: add boilerplate for vhost-user-gpio device hw/virtio: add vhost-user-gpio-pci boilerplate
hw/virtio/Kconfig | 5 + hw/virtio/meson.build | 2 + hw/virtio/vhost-user-gpio-pci.c | 69 ++++++ hw/virtio/vhost-user-gpio.c | 343 ++++++++++++++++++++++++++++ include/hw/virtio/vhost-user-gpio.h | 35 +++ 5 files changed, 454 insertions(+) create mode 100644 hw/virtio/vhost-user-gpio-pci.c create mode 100644 hw/virtio/vhost-user-gpio.c create mode 100644 include/hw/virtio/vhost-user-gpio.h
-- 2.31.1.272.g89b43f80a514
-- Alex Bennée
On Wed, Jan 12, 2022 at 05:04:57PM +0530, Viresh Kumar wrote:
Hello,
This patchset adds vhost-user-gpio device's support in Qemu. The support for the same has already been added to virtio specification and Linux Kernel.
A Rust based backend is also in progress and is tested against this patchset:
So I'm waiting for v2 of this, right?
-- Viresh
Viresh Kumar (2): hw/virtio: add boilerplate for vhost-user-gpio device hw/virtio: add vhost-user-gpio-pci boilerplate
hw/virtio/Kconfig | 5 + hw/virtio/meson.build | 2 + hw/virtio/vhost-user-gpio-pci.c | 69 ++++++ hw/virtio/vhost-user-gpio.c | 343 ++++++++++++++++++++++++++++ include/hw/virtio/vhost-user-gpio.h | 35 +++ 5 files changed, 454 insertions(+) create mode 100644 hw/virtio/vhost-user-gpio-pci.c create mode 100644 hw/virtio/vhost-user-gpio.c create mode 100644 include/hw/virtio/vhost-user-gpio.h
-- 2.31.1.272.g89b43f80a514
"Michael S. Tsirkin" mst@redhat.com writes:
On Wed, Jan 12, 2022 at 05:04:57PM +0530, Viresh Kumar wrote:
Hello,
This patchset adds vhost-user-gpio device's support in Qemu. The support for the same has already been added to virtio specification and Linux Kernel.
A Rust based backend is also in progress and is tested against this patchset:
So I'm waiting for v2 of this, right?
If you can give any pointers for how to properly instantiate the stub in qtest then we can spin v2 pretty quickly. I tried but it didn't work:
Subject: [RFC PATCH] tests/qtest: attempt to enable tests for virtio-gpio (!working) Date: Fri, 21 Jan 2022 15:15:34 +0000 Message-Id: 20220121151534.3654562-1-alex.bennee@linaro.org X-Mailer: git-send-email 2.30.2 In-Reply-To: 20220120040234.ehcjcdr6wrvlz3yc@vireshk-i7 References: 20220120040234.ehcjcdr6wrvlz3yc@vireshk-i7
it's all a bit opaque as to why it didn't.
-- Viresh
Viresh Kumar (2): hw/virtio: add boilerplate for vhost-user-gpio device hw/virtio: add vhost-user-gpio-pci boilerplate
hw/virtio/Kconfig | 5 + hw/virtio/meson.build | 2 + hw/virtio/vhost-user-gpio-pci.c | 69 ++++++ hw/virtio/vhost-user-gpio.c | 343 ++++++++++++++++++++++++++++ include/hw/virtio/vhost-user-gpio.h | 35 +++ 5 files changed, 454 insertions(+) create mode 100644 hw/virtio/vhost-user-gpio-pci.c create mode 100644 hw/virtio/vhost-user-gpio.c create mode 100644 include/hw/virtio/vhost-user-gpio.h
-- 2.31.1.272.g89b43f80a514
On Fri, Feb 04, 2022 at 01:52:47PM +0000, Alex Bennée wrote:
"Michael S. Tsirkin" mst@redhat.com writes:
On Wed, Jan 12, 2022 at 05:04:57PM +0530, Viresh Kumar wrote:
Hello,
This patchset adds vhost-user-gpio device's support in Qemu. The support for the same has already been added to virtio specification and Linux Kernel.
A Rust based backend is also in progress and is tested against this patchset:
So I'm waiting for v2 of this, right?
If you can give any pointers for how to properly instantiate the stub in qtest then we can spin v2 pretty quickly. I tried but it didn't work:
Subject: [RFC PATCH] tests/qtest: attempt to enable tests for virtio-gpio (!working) Date: Fri, 21 Jan 2022 15:15:34 +0000 Message-Id: 20220121151534.3654562-1-alex.bennee@linaro.org X-Mailer: git-send-email 2.30.2 In-Reply-To: 20220120040234.ehcjcdr6wrvlz3yc@vireshk-i7 References: 20220120040234.ehcjcdr6wrvlz3yc@vireshk-i7
it's all a bit opaque as to why it didn't.
A bit rushed short term, it this isn't resolved soon I'll try to help. Maybe try CC other vhost-user maintainers (for blk,gpu etc) meanwhile.
-- Viresh
Viresh Kumar (2): hw/virtio: add boilerplate for vhost-user-gpio device hw/virtio: add vhost-user-gpio-pci boilerplate
hw/virtio/Kconfig | 5 + hw/virtio/meson.build | 2 + hw/virtio/vhost-user-gpio-pci.c | 69 ++++++ hw/virtio/vhost-user-gpio.c | 343 ++++++++++++++++++++++++++++ include/hw/virtio/vhost-user-gpio.h | 35 +++ 5 files changed, 454 insertions(+) create mode 100644 hw/virtio/vhost-user-gpio-pci.c create mode 100644 hw/virtio/vhost-user-gpio.c create mode 100644 include/hw/virtio/vhost-user-gpio.h
-- 2.31.1.272.g89b43f80a514
-- Alex Bennée
"Michael S. Tsirkin" mst@redhat.com writes:
On Fri, Feb 04, 2022 at 01:52:47PM +0000, Alex Bennée wrote:
"Michael S. Tsirkin" mst@redhat.com writes:
On Wed, Jan 12, 2022 at 05:04:57PM +0530, Viresh Kumar wrote:
Hello,
This patchset adds vhost-user-gpio device's support in Qemu. The support for the same has already been added to virtio specification and Linux Kernel.
A Rust based backend is also in progress and is tested against this patchset:
So I'm waiting for v2 of this, right?
If you can give any pointers for how to properly instantiate the stub in qtest then we can spin v2 pretty quickly. I tried but it didn't work:
Subject: [RFC PATCH] tests/qtest: attempt to enable tests for virtio-gpio (!working) Date: Fri, 21 Jan 2022 15:15:34 +0000 Message-Id: 20220121151534.3654562-1-alex.bennee@linaro.org X-Mailer: git-send-email 2.30.2 In-Reply-To: 20220120040234.ehcjcdr6wrvlz3yc@vireshk-i7 References: 20220120040234.ehcjcdr6wrvlz3yc@vireshk-i7
it's all a bit opaque as to why it didn't.
A bit rushed short term, it this isn't resolved soon I'll try to help. Maybe try CC other vhost-user maintainers (for blk,gpu etc) meanwhile.
I have expanded the CC list for this thread and the RFC patch to see if anyone has pointers. I'll pull this series into my vhost cleanups series for post 7.0.
Viresh Kumar viresh.kumar@linaro.org writes:
Hello,
This patchset adds vhost-user-gpio device's support in Qemu. The support for the same has already been added to virtio specification and Linux Kernel.
A Rust based backend is also in progress and is tested against this patchset:
Queued to virtio/virtio-cleanups-and-gpio-v2, thanks.
stratos-dev@op-lists.linaro.org
-
Alex Bennée -
Michael S. Tsirkin -
Viresh Kumar