search for: 08ad0d1f0476

...s 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> --- 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 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; +} + /** * vri...

...s 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> --- 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 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; +} + /** * vri...

...rivers/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 up within a proposal for a new feature. Thanks, Alex > 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(...

...rivers/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 up within a proposal for a new feature. Thanks, Alex > 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(...

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 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; +} + /** * vri...

...ng > held up within a proposal for a new feature. Thanks, > > Alex It's better to have it as patch 1/6, but it's a dependency of the example driver in the series. I can reorder when I apply. > > 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,...

...ng <jasowang at redhat.com> I'm still inclined to merge it now, incorrect code tends to proliferate. > --- > 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 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(...

..., then it will already be in the base kernel we use for the rest of the series. The remainder of the series certainly suggests a workflow through the vfio tree rather than virtio/vhost. Thanks, Alex > > > 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...

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