search for: to_virtio_mdev_device

...ude <linux/virtio_ring.h> +#include <uapi/linux/virtio_mdev.h> +#include "mdev_private.h" + +#define DRIVER_VERSION "0.1" +#define DRIVER_AUTHOR "Red Hat Corporation" +#define DRIVER_DESC "VIRTIO based driver for Mediated device" + +#define to_virtio_mdev_device(dev) \ + container_of(dev, struct virtio_mdev_device, vdev) + +struct virtio_mdev_device { + struct virtio_device vdev; + struct mdev_device *mdev; + unsigned long version; + + struct virtqueue **vqs; + spinlock_t lock; +}; + +struct virtio_mdev_vq_info { + /* the actual virtqueue */ + struct virtq...

...nclude <uapi/linux/virtio_mdev.h> > +#include "mdev_private.h" > + > +#define DRIVER_VERSION "0.1" > +#define DRIVER_AUTHOR "Red Hat Corporation" > +#define DRIVER_DESC "VIRTIO based driver for Mediated device" > + > +#define to_virtio_mdev_device(dev) \ > + container_of(dev, struct virtio_mdev_device, vdev) > + > +struct virtio_mdev_device { > + struct virtio_device vdev; > + struct mdev_device *mdev; > + unsigned long version; > + > + struct virtqueue **vqs; > + spinlock_t lock; > +}; > + > +struct virti...

...nclude <uapi/linux/virtio_mdev.h> > +#include "mdev_private.h" > + > +#define DRIVER_VERSION "0.1" > +#define DRIVER_AUTHOR "Red Hat Corporation" > +#define DRIVER_DESC "VIRTIO based driver for Mediated device" > + > +#define to_virtio_mdev_device(dev) \ > + container_of(dev, struct virtio_mdev_device, vdev) > + > +struct virtio_mdev_device { > + struct virtio_device vdev; > + struct mdev_device *mdev; > + unsigned long version; > + > + struct virtqueue **vqs; > + spinlock_t lock; > +}; > + > +struct virti...

...+#include <linux/virtio.h> +#include <linux/virtio_config.h> +#include <linux/virtio_ring.h> + +#define DRIVER_VERSION "0.1" +#define DRIVER_AUTHOR "Red Hat Corporation" +#define DRIVER_DESC "VIRTIO based driver for Mediated device" + +#define to_virtio_mdev_device(dev) \ + container_of(dev, struct virtio_mdev_device, vdev) + +struct virtio_mdev_device { + struct virtio_device vdev; + struct mdev_device *mdev; + u64 features; + + /* The lock to protect virtqueue list */ + spinlock_t lock; + /* List of virtio_mdev_vq_info */ + struct list_head virtqueues; +};...

...+#include <linux/virtio.h> +#include <linux/virtio_config.h> +#include <linux/virtio_ring.h> + +#define DRIVER_VERSION "0.1" +#define DRIVER_AUTHOR "Red Hat Corporation" +#define DRIVER_DESC "VIRTIO based driver for Mediated device" + +#define to_virtio_mdev_device(dev) \ + container_of(dev, struct virtio_mdev_device, vdev) + +struct virtio_mdev_device { + struct virtio_device vdev; + struct mdev_device *mdev; + unsigned long version; + + /* The lock to protect virtqueue list */ + spinlock_t lock; + /* List of virtio_mdev_vq_info */ + struct list_head virtque...

...+#include <linux/virtio.h> +#include <linux/virtio_config.h> +#include <linux/virtio_ring.h> + +#define DRIVER_VERSION "0.1" +#define DRIVER_AUTHOR "Red Hat Corporation" +#define DRIVER_DESC "VIRTIO based driver for Mediated device" + +#define to_virtio_mdev_device(dev) \ + container_of(dev, struct virtio_mdev_device, vdev) + +struct virtio_mdev_device { + struct virtio_device vdev; + struct mdev_device *mdev; + unsigned long version; + + struct virtqueue **vqs; + /* The lock to protect virtqueue list */ + spinlock_t lock; + struct list_head virtqueues; +}; +...

...+#include <linux/virtio.h> +#include <linux/virtio_config.h> +#include <linux/virtio_ring.h> + +#define DRIVER_VERSION "0.1" +#define DRIVER_AUTHOR "Red Hat Corporation" +#define DRIVER_DESC "VIRTIO based driver for Mediated device" + +#define to_virtio_mdev_device(dev) \ + container_of(dev, struct virtio_mdev_device, vdev) + +struct virtio_mdev_device { + struct virtio_device vdev; + struct mdev_device *mdev; + u64 features; + + /* The lock to protect virtqueue list */ + spinlock_t lock; + /* List of virtio_mdev_vq_info */ + struct list_head virtqueues; +};...

Hi all: There are hardware that can do virtio datapath offloading while having its own control path. This path tries to implement a mdev based unified API to support using kernel virtio driver to drive those devices. This is done by introducing a new mdev transport for virtio (virtio_mdev) and register itself as a new kind of mdev driver. Then it provides a unified way for kernel virtio driver to

...tatic int virtio_mdev_find_vqs(struct virtio_device *vdev, unsigned nvqs, > + struct virtqueue *vqs[], > + vq_callback_t *callbacks[], > + const char * const names[], > + const bool *ctx, > + struct irq_affinity *desc) > +{ > + struct virtio_mdev_device *vm_dev = to_virtio_mdev_device(vdev); > + struct mdev_device *mdev = vm_get_mdev(vdev); > + const struct virtio_mdev_device_ops *ops = mdev_get_dev_ops(mdev); > + struct virtio_mdev_callback cb; > + int i, err, queue_idx = 0; > + > + vm_dev->vqs = kmalloc_array(queue_idx, sizeof(*vm_dev->vqs), > +...

..._ring.h> >> +#include "mdev_private.h" >> + >> +#define DRIVER_VERSION "0.1" >> +#define DRIVER_AUTHOR "Red Hat Corporation" >> +#define DRIVER_DESC "VIRTIO based driver for Mediated device" >> + >> +#define to_virtio_mdev_device(dev) \ >> + container_of(dev, struct virtio_mdev_device, vdev) >> + >> +struct virtio_mdev_device { >> + struct virtio_device vdev; >> + struct mdev_device *mdev; >> + unsigned long version; >> + >> + struct virtqueue **vqs; > Every lock must need...

Hi all: There are hardwares that can do virtio datapath offloading while having its own control path. This path tries to implement a mdev based unified API to support using kernel virtio driver to drive those devices. This is done by introducing a new mdev transport for virtio (virtio_mdev) and register itself as a new kind of mdev driver. Then it provides a unified way for kernel virtio driver

Hi all: There are hardware that can do virtio datapath offloading while having its own control path. This path tries to implement a mdev based unified API to support using kernel virtio driver to drive those devices. This is done by introducing a new mdev transport for virtio (virtio_mdev) and register itself as a new kind of mdev driver. Then it provides a unified way for kernel virtio driver to

Hi all: There are hardware that can do virtio datapath offloading while having its own control path. This path tries to implement a mdev based unified API to support using kernel virtio driver to drive those devices. This is done by introducing a new mdev transport for virtio (virtio_mdev) and register itself as a new kind of mdev driver. Then it provides a unified way for kernel virtio driver to

Hi all: There are hardwares that can do virtio datapath offloading while having its own control path. This path tries to implement a mdev based unified API to support using kernel virtio driver to drive those devices. This is done by introducing a new mdev transport for virtio (virtio_mdev) and register itself as a new kind of mdev driver. Then it provides a unified way for kernel virtio driver

Hi all: There are hardwares that can do virtio datapath offloading while having its own control path. This path tries to implement a mdev based unified API to support using kernel virtio driver to drive those devices. This is done by introducing a new mdev transport for virtio (virtio_mdev) and register itself as a new kind of mdev driver. Then it provides a unified way for kernel virtio driver

Hi all: There are hardwares that can do virtio datapath offloading while having its own control path. This path tries to implement a mdev based unified API to support using kernel virtio driver to drive those devices. This is done by introducing a new mdev transport for virtio (virtio_mdev) and register itself as a new kind of mdev driver. Then it provides a unified way for kernel virtio driver

Hi all: There are hardwares that can do virtio datapath offloading while having its own control path. This path tries to implement a mdev based unified API to support using kernel virtio driver to drive those devices. This is done by introducing a new mdev transport for virtio (virtio_mdev) and register itself as a new kind of mdev driver. Then it provides a unified way for kernel virtio driver

Hi all: There are hardwares that can do virtio datapath offloading while having its own control path. This path tries to implement a mdev based unified API to support using kernel virtio driver to drive those devices. This is done by introducing a new mdev transport for virtio (virtio_mdev) and register itself as a new kind of mdev driver. Then it provides a unified way for kernel virtio driver

Hi all: There are hardwares that can do virtio datapath offloading while having its own control path. This path tries to implement a mdev based unified API to support using kernel virtio driver to drive those devices. This is done by introducing a new mdev transport for virtio (virtio_mdev) and register itself as a new kind of mdev driver. Then it provides a unified way for kernel virtio driver

Hi all: There are hardware that can do virtio datapath offloading while having its own control path. This path tries to implement a mdev based unified API to support using kernel virtio driver to drive those devices. This is done by introducing a new mdev transport for virtio (virtio_mdev) and register itself as a new kind of mdev driver. Then it provides a unified way for kernel virtio driver to