search for: sample_vfio_mdev_mdpi

On 11/5/19 11:05 PM, Jason Wang wrote: > diff --git a/samples/Kconfig b/samples/Kconfig > index c8dacb4dda80..13a2443e18e0 100644 > --- a/samples/Kconfig > +++ b/samples/Kconfig > @@ -131,6 +131,16 @@ config SAMPLE_VFIO_MDEV_MDPY > mediated device. It is a simple framebuffer and supports > the region display interface (VFIO_GFX_PLANE_TYPE_REGION). > > +config

On 11/5/19 11:05 PM, Jason Wang wrote: > diff --git a/samples/Kconfig b/samples/Kconfig > index c8dacb4dda80..13a2443e18e0 100644 > --- a/samples/Kconfig > +++ b/samples/Kconfig > @@ -131,6 +131,16 @@ config SAMPLE_VFIO_MDEV_MDPY > mediated device. It is a simple framebuffer and supports > the region display interface (VFIO_GFX_PLANE_TYPE_REGION). > > +config

On Wed, 6 Nov 2019 14:50:30 -0800 Randy Dunlap <rdunlap at infradead.org> wrote: > On 11/5/19 11:05 PM, Jason Wang wrote: > > diff --git a/samples/Kconfig b/samples/Kconfig > > index c8dacb4dda80..13a2443e18e0 100644 > > --- a/samples/Kconfig > > +++ b/samples/Kconfig > > @@ -131,6 +131,16 @@ config SAMPLE_VFIO_MDEV_MDPY > > mediated device. It is

On Tue, Sep 10, 2019 at 04:19:35PM +0800, Jason Wang wrote: > This sample driver creates mdev device that simulate virtio net device > over virtio mdev transport. The device is implemented through vringh > and workqueue. > > Signed-off-by: Jason Wang <jasowang at redhat.com> > --- > samples/Kconfig | 7 + > samples/vfio-mdev/Makefile | 1 + >

This sample driver creates mdev device that simulate virtio net device over virtio mdev transport. The device is implemented through vringh and workqueue. A device specific dma ops is to make sure HVA is used directly as the IOVA. This should be sufficient for kernel virtio driver to work. Only 'virtio' type is supported right now. I plan to add 'vhost' type on top which requires

This sample driver creates mdev device that simulate virtio net device over virtio mdev transport. The device is implemented through vringh and workqueue. Signed-off-by: Jason Wang <jasowang at redhat.com> --- samples/Kconfig | 7 + samples/vfio-mdev/Makefile | 1 + samples/vfio-mdev/mvnet.c | 766 +++++++++++++++++++++++++++++++++++++ 3 files changed, 774 insertions(+)

This sample driver creates mdev device that simulate virtio net device over virtio mdev transport. The device is implemented through vringh and workqueue. A device specific dma ops is to make sure HVA is used directly as the IOVA. This should be sufficient for kernel virtio driver to work. Only 'virtio' type is supported right now. I plan to add 'vhost' type on top which requires

This sample driver creates mdev device that simulate virtio net device over virtio mdev transport. The device is implemented through vringh and workqueue. A device specific dma ops is to make sure HVA is used directly as the IOVA. This should be sufficient for kernel virtio driver to work. Only 'virtio' type is supported right now. I plan to add 'vhost' type on top which requires

This sample driver creates mdev device that simulate virtio net device over virtio mdev transport. The device is implemented through vringh and workqueue. A device specific dma ops is to make sure HVA is used directly as the IOVA. This should be sufficient for kernel virtio driver to work. Only 'virtio' type is supported right now. I plan to add 'vhost' type on top which requires

This sample driver creates mdev device that simulate virtio net device over virtio mdev transport. The device is implemented through vringh and workqueue. A device specific dma ops is to make sure HVA is used directly as the IOVA. This should be sufficient for kernel virtio driver to work. Only 'virtio' type is supported right now. I plan to add 'vhost' type on top which requires

On Wed, Nov 06, 2019 at 09:35:31PM +0800, Jason Wang wrote: > This sample driver creates mdev device that simulate virtio net device > over virtio mdev transport. The device is implemented through vringh > and workqueue. A device specific dma ops is to make sure HVA is used > directly as the IOVA. This should be sufficient for kernel virtio > driver to work. > > Only

On Wed, Nov 06, 2019 at 09:35:31PM +0800, Jason Wang wrote: > This sample driver creates mdev device that simulate virtio net device > over virtio mdev transport. The device is implemented through vringh > and workqueue. A device specific dma ops is to make sure HVA is used > directly as the IOVA. This should be sufficient for kernel virtio > driver to work. > > Only

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