similar to: [PATCH net-next] vringh: fix copy direction of vringh_iov_push_kern()

On Mon, 23 Sep 2019 21:03:30 +0800 Jason Wang <jasowang at redhat.com> wrote: > We want to copy from iov to buf, so the direction was wrong. > > Signed-off-by: Jason Wang <jasowang at redhat.com> > --- > drivers/vhost/vringh.c | 8 +++++++- > 1 file changed, 7 insertions(+), 1 deletion(-) Why is this included in the series? Seems like an unrelated fix being held

On Mon, 23 Sep 2019 21:03:30 +0800 Jason Wang <jasowang at redhat.com> wrote: > We want to copy from iov to buf, so the direction was wrong. > > Signed-off-by: Jason Wang <jasowang at redhat.com> > --- > drivers/vhost/vringh.c | 8 +++++++- > 1 file changed, 7 insertions(+), 1 deletion(-) Why is this included in the series? Seems like an unrelated fix being held

We want to copy from iov to buf, so the direction was wrong. Signed-off-by: Jason Wang <jasowang at redhat.com> --- drivers/vhost/vringh.c | 8 +++++++- 1 file changed, 7 insertions(+), 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

On Mon, Sep 23, 2019 at 09:45:59AM -0600, Alex Williamson wrote: > On Mon, 23 Sep 2019 21:03:30 +0800 > Jason Wang <jasowang at redhat.com> wrote: > > > We want to copy from iov to buf, so the direction was wrong. > > > > Signed-off-by: Jason Wang <jasowang at redhat.com> > > --- > > drivers/vhost/vringh.c | 8 +++++++- > > 1 file

On Thu, Oct 24, 2019 at 11:57:18AM +0800, Jason Wang wrote: > We want to copy from iov to buf, so the direction was wrong. > > Note: no real user for the helper, but it will be used by future > features. > > Signed-off-by: Jason Wang <jasowang at redhat.com> I'm still inclined to merge it now, incorrect code tends to proliferate. > --- >

On Mon, 23 Sep 2019 12:00:41 -0400 "Michael S. Tsirkin" <mst at redhat.com> wrote: > On Mon, Sep 23, 2019 at 09:45:59AM -0600, Alex Williamson wrote: > > On Mon, 23 Sep 2019 21:03:30 +0800 > > Jason Wang <jasowang at redhat.com> wrote: > > > > > We want to copy from iov to buf, so the direction was wrong. > > > > > >

Getting use of virtio rings correct is tricky, and a recent patch saw an implementation of in-kernel rings (as separate from userspace). This patch attempts to abstract the business of dealing with the virtio ring layout from the access (userspace or direct); to do this, we use function pointers, which gcc inlines correctly. Signed-off-by: Rusty Russell <rusty at rustcorp.com.au> ---

Getting use of virtio rings correct is tricky, and a recent patch saw an implementation of in-kernel rings (as separate from userspace). This patch attempts to abstract the business of dealing with the virtio ring layout from the access (userspace or direct); to do this, we use function pointers, which gcc inlines correctly. Signed-off-by: Rusty Russell <rusty at rustcorp.com.au> ---

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

This introduces vringh, which are generic accessors for virtio rings (host side). There's a host-side implementation in vhost, but it assumes that the rings are in userspace, and is tied to the vhost implementation. I have patches to adapt it to use vringh, but I'm pushing this in the next merge window for Sjur, who has CAIF patches which need it. This also includes a test program in

This introduces vringh, which are generic accessors for virtio rings (host side). There's a host-side implementation in vhost, but it assumes that the rings are in userspace, and is tied to the vhost implementation. I have patches to adapt it to use vringh, but I'm pushing this in the next merge window for Sjur, who has CAIF patches which need it. This also includes a test program in

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

Replace `userpace` with `userspace`. Cc: Simon Horman <simon.horman at corigine.com> Signed-off-by: Stefano Garzarella <sgarzare at redhat.com> --- drivers/vhost/vringh.c | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/drivers/vhost/vringh.c b/drivers/vhost/vringh.c index a1e27da54481..694462ba3242 100644 --- a/drivers/vhost/vringh.c +++

On Mon, 2013-07-29 at 10:05 +0300, Michael S. Tsirkin wrote: > On Wed, Jul 24, 2013 at 08:31:34PM -0700, Sudeep Dutt wrote: > > From: Ashutosh Dixit <ashutosh.dixit at intel.com> > > > > This patch introduces the host "Virtio over PCIe" interface for > > Intel MIC. It allows creating user space backends on the host and > > instantiating virtio

On Mon, 2013-07-29 at 10:05 +0300, Michael S. Tsirkin wrote: > On Wed, Jul 24, 2013 at 08:31:34PM -0700, Sudeep Dutt wrote: > > From: Ashutosh Dixit <ashutosh.dixit at intel.com> > > > > This patch introduces the host "Virtio over PCIe" interface for > > Intel MIC. It allows creating user space backends on the host and > > instantiating virtio