search for: do_mdev_entri

On Wed, 23 Oct 2019 21:07:48 +0800 Jason Wang <jasowang at redhat.com> wrote: > Add support to parse mdev class id table. > > Reviewed-by: Parav Pandit <parav at mellanox.com> > Signed-off-by: Jason Wang <jasowang at redhat.com> > --- > drivers/vfio/mdev/vfio_mdev.c | 2 ++ > scripts/mod/devicetable-offsets.c | 3 +++ > scripts/mod/file2alias.c

On Wed, 23 Oct 2019 21:07:48 +0800 Jason Wang <jasowang at redhat.com> wrote: > Add support to parse mdev class id table. > > Reviewed-by: Parav Pandit <parav at mellanox.com> > Signed-off-by: Jason Wang <jasowang at redhat.com> > --- > drivers/vfio/mdev/vfio_mdev.c | 2 ++ > scripts/mod/devicetable-offsets.c | 3 +++ > scripts/mod/file2alias.c

Add support to parse mdev class id table. Reviewed-by: Parav Pandit <parav at mellanox.com> Signed-off-by: Jason Wang <jasowang at redhat.com> --- drivers/vfio/mdev/vfio_mdev.c | 2 ++ scripts/mod/devicetable-offsets.c | 3 +++ scripts/mod/file2alias.c | 10 ++++++++++ 3 files changed, 15 insertions(+) diff --git a/drivers/vfio/mdev/vfio_mdev.c

Add support to parse mdev class id table. Reviewed-by: Parav Pandit <parav at mellanox.com> Signed-off-by: Jason Wang <jasowang at redhat.com> --- drivers/vfio/mdev/vfio_mdev.c | 2 ++ scripts/mod/devicetable-offsets.c | 3 +++ scripts/mod/file2alias.c | 11 +++++++++++ 3 files changed, 16 insertions(+) diff --git a/drivers/vfio/mdev/vfio_mdev.c

On 2019/10/24 ??5:42, Alex Williamson wrote: > On Wed, 23 Oct 2019 21:07:48 +0800 > Jason Wang <jasowang at redhat.com> wrote: > >> Add support to parse mdev class id table. >> >> Reviewed-by: Parav Pandit <parav at mellanox.com> >> Signed-off-by: Jason Wang <jasowang at redhat.com> >> --- >> drivers/vfio/mdev/vfio_mdev.c | 2 ++

On Thu, 24 Oct 2019 11:31:04 +0800 Jason Wang <jasowang at redhat.com> wrote: > On 2019/10/24 ??5:42, Alex Williamson wrote: > > On Wed, 23 Oct 2019 21:07:48 +0800 > > Jason Wang <jasowang at redhat.com> wrote: > > > >> Add support to parse mdev class id table. > >> > >> Reviewed-by: Parav Pandit <parav at mellanox.com> >

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