search for: kern_xfer

...ns(+), 1 deletion(-) diff --git a/drivers/vhost/vringh.c b/drivers/vhost/vringh.c index 08ad0d1f0476..a0a2d74967ef 100644 --- a/drivers/vhost/vringh.c +++ b/drivers/vhost/vringh.c @@ -852,6 +852,12 @@ static inline int xfer_kern(void *src, void *dst, size_t len) return 0; } +static inline int kern_xfer(void *dst, void *src, size_t len) +{ + memcpy(dst, src, len); + return 0; +} + /** * vringh_init_kern - initialize a vringh for a kernelspace vring. * @vrh: the vringh to initialize. @@ -958,7 +964,7 @@ EXPORT_SYMBOL(vringh_iov_pull_kern); ssize_t vringh_iov_push_kern(struct vringh_kiov *wiov...

...ns(+), 1 deletion(-) diff --git a/drivers/vhost/vringh.c b/drivers/vhost/vringh.c index 08ad0d1f0476..a0a2d74967ef 100644 --- a/drivers/vhost/vringh.c +++ b/drivers/vhost/vringh.c @@ -852,6 +852,12 @@ static inline int xfer_kern(void *src, void *dst, size_t len) return 0; } +static inline int kern_xfer(void *dst, void *src, size_t len) +{ + memcpy(dst, src, len); + return 0; +} + /** * vringh_init_kern - initialize a vringh for a kernelspace vring. * @vrh: the vringh to initialize. @@ -958,7 +964,7 @@ EXPORT_SYMBOL(vringh_iov_pull_kern); ssize_t vringh_iov_push_kern(struct vringh_kiov *wiov...

...rs/vhost/vringh.c b/drivers/vhost/vringh.c > index 08ad0d1f0476..a0a2d74967ef 100644 > --- a/drivers/vhost/vringh.c > +++ b/drivers/vhost/vringh.c > @@ -852,6 +852,12 @@ static inline int xfer_kern(void *src, void *dst, size_t len) > return 0; > } > > +static inline int kern_xfer(void *dst, void *src, size_t len) > +{ > + memcpy(dst, src, len); > + return 0; > +} > + > /** > * vringh_init_kern - initialize a vringh for a kernelspace vring. > * @vrh: the vringh to initialize. > @@ -958,7 +964,7 @@ EXPORT_SYMBOL(vringh_iov_pull_kern); > ssi...

...rs/vhost/vringh.c b/drivers/vhost/vringh.c > index 08ad0d1f0476..a0a2d74967ef 100644 > --- a/drivers/vhost/vringh.c > +++ b/drivers/vhost/vringh.c > @@ -852,6 +852,12 @@ static inline int xfer_kern(void *src, void *dst, size_t len) > return 0; > } > > +static inline int kern_xfer(void *dst, void *src, size_t len) > +{ > + memcpy(dst, src, len); > + return 0; > +} > + > /** > * vringh_init_kern - initialize a vringh for a kernelspace vring. > * @vrh: the vringh to initialize. > @@ -958,7 +964,7 @@ EXPORT_SYMBOL(vringh_iov_pull_kern); > ssi...

...avail pointer. - * @used: the userpace used pointer. + * @desc: the userspace descriptor pointer. + * @avail: the userspace avail pointer. + * @used: the userspace used pointer. * * Returns an error if num is invalid: you should check pointers * yourself! @@ -911,9 +911,9 @@ static inline int kern_xfer(const struct vringh *vrh, void *dst, * @features: the feature bits for this ring. * @num: the number of elements. * @weak_barriers: true if we only need memory barriers, not I/O. - * @desc: the userpace descriptor pointer. - * @avail: the userpace avail pointer. - * @used: the userpace used p...

...ns(+), 1 deletion(-) diff --git a/drivers/vhost/vringh.c b/drivers/vhost/vringh.c index 08ad0d1f0476..a0a2d74967ef 100644 --- a/drivers/vhost/vringh.c +++ b/drivers/vhost/vringh.c @@ -852,6 +852,12 @@ static inline int xfer_kern(void *src, void *dst, size_t len) return 0; } +static inline int kern_xfer(void *dst, void *src, size_t len) +{ + memcpy(dst, src, len); + return 0; +} + /** * vringh_init_kern - initialize a vringh for a kernelspace vring. * @vrh: the vringh to initialize. @@ -958,7 +964,7 @@ EXPORT_SYMBOL(vringh_iov_pull_kern); ssize_t vringh_iov_push_kern(struct vringh_kiov *wiov...

....c > > index 08ad0d1f0476..a0a2d74967ef 100644 > > --- a/drivers/vhost/vringh.c > > +++ b/drivers/vhost/vringh.c > > @@ -852,6 +852,12 @@ static inline int xfer_kern(void *src, void *dst, size_t len) > > return 0; > > } > > > > +static inline int kern_xfer(void *dst, void *src, size_t len) > > +{ > > + memcpy(dst, src, len); > > + return 0; > > +} > > + > > /** > > * vringh_init_kern - initialize a vringh for a kernelspace vring. > > * @vrh: the vringh to initialize. > > @@ -958,7 +964,7 @@ E...

...rs/vhost/vringh.c b/drivers/vhost/vringh.c > index 08ad0d1f0476..a0a2d74967ef 100644 > --- a/drivers/vhost/vringh.c > +++ b/drivers/vhost/vringh.c > @@ -852,6 +852,12 @@ static inline int xfer_kern(void *src, void *dst, size_t len) > return 0; > } > > +static inline int kern_xfer(void *dst, void *src, size_t len) > +{ > + memcpy(dst, src, len); > + return 0; > +} > + > /** > * vringh_init_kern - initialize a vringh for a kernelspace vring. > * @vrh: the vringh to initialize. > @@ -958,7 +964,7 @@ EXPORT_SYMBOL(vringh_iov_pull_kern); > ssi...

...a2d74967ef 100644 > > > --- a/drivers/vhost/vringh.c > > > +++ b/drivers/vhost/vringh.c > > > @@ -852,6 +852,12 @@ static inline int xfer_kern(void *src, void *dst, size_t len) > > > return 0; > > > } > > > > > > +static inline int kern_xfer(void *dst, void *src, size_t len) > > > +{ > > > + memcpy(dst, src, len); > > > + return 0; > > > +} > > > + > > > /** > > > * vringh_init_kern - initialize a vringh for a kernelspace vring. > > > * @vrh: the vringh to ini...

Hi all: This is an update version of vDPA support in kernel. vDPA device is a device that uses a datapath which complies with the virtio specifications with vendor specific control path. vDPA devices can be both physically located on the hardware or emulated by software. vDPA hardware devices are usually implemented through PCIE with the following types: - PF (Physical Function) - A single

Hi all: This is an update version of vDPA support in kernel. vDPA device is a device that uses a datapath which complies with the virtio specifications with vendor specific control path. vDPA devices can be both physically located on the hardware or emulated by software. vDPA hardware devices are usually implemented through PCIE with the following types: - PF (Physical Function) - A single

Hi all: This is an updated version of kernel support for vDPA device. Various changes were made based on the feedback since last verion. One major change is to drop the sysfs API and leave the management interface for future development, and introudce the incremental DMA bus operations. Please see changelog for more information. The work on vhost, IFCVF (intel VF driver for vDPA) and qemu is

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