-gpio driver")
Signed-off-by: Vincent Whitchurch
---
drivers/gpio/gpio-virtio.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/gpio/gpio-virtio.c b/drivers/gpio/gpio-virtio.c
index 84f96b78f32a..9f4941bc5760 100644
--- a/drivers/gpio/gpio-virtio.c
+++ b/drivers
On Thu, Nov 11, 2021 at 05:57:30PM +0100, Michael S. Tsirkin wrote:
> On Thu, Nov 11, 2021 at 05:04:12PM +0100, Vincent Whitchurch wrote:
> > - wait_for_completion(>completion);
> > + /*
> > +* We only need to wait for the last one since the device is require
this by calling virtio_get_buf() from the notify handler like other
virtio drivers and by actually waiting for all the buffers to be
completed.
Fixes: 3cfc88380413d20f ("i2c: virtio: add a virtio i2c frontend driver")
Acked-by: Viresh Kumar
Signed-off-by: Vincent Whitchurch
---
Notes:
On Fri, Nov 12, 2021 at 03:35:29AM +0100, Viresh Kumar wrote:
> On 11-11-21, 17:04, Vincent Whitchurch wrote:
> > static int virtio_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg *msgs,
> > @@ -141,7 +140,6 @@ static int virtio_i2c_xfer(struct i2c_adapter *adap,
> >
create
bounce buffers and hold on to them until the device eventually returns
the buffers), so just disable the timeout support for now.
Fixes: 3cfc88380413d20f ("i2c: virtio: add a virtio i2c frontend driver")
Acked-by: Jie Deng
Signed-off-by: Vincent Whitchurch
---
drivers/i2c/
this by calling virtio_get_buf() from the notify handler like other
virtio drivers and by actually waiting for all the buffers to be
completed.
Fixes: 3cfc88380413d20f ("i2c: virtio: add a virtio i2c frontend driver")
Acked-by: Viresh Kumar
Signed-off-by: Vincent Whitchurch
---
drivers/
in v2:
- Added Acked-by and Fixes tags
Vincent Whitchurch (2):
i2c: virtio: disable timeout handling
i2c: virtio: fix completion handling
drivers/i2c/busses/i2c-virtio.c | 46 ++---
1 file changed, 19 insertions(+), 27 deletions(-)
--
2.28.0
On Wed, Nov 03, 2021 at 07:37:45AM +0100, Viresh Kumar wrote:
> On 03-11-21, 06:18, Chen, Conghui wrote:
> > >>> Over the long term, I think the backend should provide that timeout
> > >>> value and guarantee that its processing time should not exceed that
> > >>> value.
> > >> If you mean that
On Thu, Oct 21, 2021 at 05:30:28AM +0200, Jie Deng wrote:
> On 2021/10/20 19:03, Viresh Kumar wrote:
> > On 20-10-21, 12:55, Vincent Whitchurch wrote:
> >> If the timeout cannot be disabled, then the driver should be fixed to
> >> always copy buffers and hold on to them
On Wed, Oct 20, 2021 at 12:47:09PM +0200, Viresh Kumar wrote:
> On 20-10-21, 12:38, Vincent Whitchurch wrote:
> > I don't quite understand how that would be safe since
> > virtqueue_add_sgs() can fail after a few iterations and all queued
> > request buffers can have FAIL_NEXT
The flags are currently overwritten, leading to the wrong direction
being passed to the DMA unmap functions.
Fixes: 72b5e8958738aaa4 ("virtio-ring: store DMA metadata in desc_extra for
split virtqueue")
Signed-off-by: Vincent Whitchurch
---
drivers/virtio/virtio_ring.c | 2 +-
1 fi
On Wed, Oct 20, 2021 at 09:04:45AM +0200, Jie Deng wrote:
> On 2021/10/20 14:41, Viresh Kumar wrote:
> > On 20-10-21, 14:35, Jie Deng wrote:
> >> Yes, but we need to know what's the best value to be configured for a
> >> specific "other side".
> >>
> >> I think the "other side" should be more
On Wed, Oct 20, 2021 at 11:17:21AM +0200, Viresh Kumar wrote:
> On 20-10-21, 16:54, Jie Deng wrote:
> >
> > On 2021/10/19 16:22, Viresh Kumar wrote:
> > > On 19-10-21, 09:46, Vincent Whitchurch wrote:
> > > > static void virt
this by calling virtio_get_buf() from the notify handler like other
virtio drivers and by actually waiting for all the buffers to be
completed.
Signed-off-by: Vincent Whitchurch
---
drivers/i2c/busses/i2c-virtio.c | 34 +++--
1 file changed, 15 insertions(+), 19 deletions
create
bounce buffers and hold on to them until the device eventually returns
the buffers), so just disable the timeout support for now.
Signed-off-by: Vincent Whitchurch
---
drivers/i2c/busses/i2c-virtio.c | 14 +-
1 file changed, 5 insertions(+), 9 deletions(-)
diff --git a/drivers
This fixes a couple of bugs in the buffer handling in virtio-i2c which can
result in incorrect data on the I2C bus or memory corruption in the guest.
I tested this on UML (virtio-uml needs a bug fix too, I will sent that out
later) with the device implementation in rust-vmm/vhost-device.
Vincent
In order to prepare for allowing vhost to operate on kernel buffers,
push the virtqueue desc/avail/used area pointers down to a new "user"
struct.
No functional change intended.
Signed-off-by: Vincent Whitchurch
---
drivers/vhost/vdpa.c | 6 +--
drivers/vhost/vh
Extract the mutex locking for the vhost ioctl into common code. This
will allow the common code to easily add some extra handling required
for adding a kernel API to control vhost.
Signed-off-by: Vincent Whitchurch
---
drivers/vhost/common.c | 7 ++-
drivers/vhost/net.c| 14
Add support for kernel control to virtio-net. For the vhost-*-kernel
devices, the ioctl to set the backend only provides the socket to
vhost-net but does not start the handling of the virtqueues. The
handling of the virtqueues is started and stopped by the kernel.
Signed-off-by: Vincent
There is some duplicated code for handling of file_operations among
vhost drivers. Move this to a common file.
Having file_operations in a common place also makes adding functions for
obaining a handle to a vhost device from a file descriptor simpler.
Signed-off-by: Vincent Whitchurch
for testing the support for kernel buffers in vhost.
A selftest which uses this driver will be added.
Signed-off-by: Vincent Whitchurch
---
drivers/vdpa/Kconfig | 8 +
drivers/vdpa/Makefile | 1 +
drivers/vdpa/vhost_kernel_test/Makefile | 2
can it
control the placement and attributes of the virtqueues, nor start/stop
the virtqueue handling after the kernel starts using it.
Signed-off-by: Vincent Whitchurch
---
drivers/vhost/common.c | 201 +
drivers/vhost/vhost.c | 92
In order to prepare for supporting buffers in kernel space, add a
vhost_iov struct to wrap the userspace iovec, add helper functions for
accessing this struct, and use these helpers from all vhost drivers.
Signed-off-by: Vincent Whitchurch
---
drivers/vhost/net.c | 13 ++--
drivers
-by: Vincent Whitchurch
---
drivers/vhost/scsi.c | 24 +---
1 file changed, 13 insertions(+), 11 deletions(-)
diff --git a/drivers/vhost/scsi.c b/drivers/vhost/scsi.c
index 532e204f2b1b..bcf53685439d 100644
--- a/drivers/vhost/scsi.c
+++ b/drivers/vhost/scsi.c
@@ -462,7 +462,7
file
descriptors in different sequences during active use works correctly.
Signed-off-by: Vincent Whitchurch
---
tools/testing/selftests/Makefile | 1 +
.../vhost_kernel/vhost_kernel_test.c | 287 ++
.../vhost_kernel/vhost_kernel_test.sh | 125
for that is added in a later patch.
Signed-off-by: Vincent Whitchurch
---
drivers/vhost/Kconfig | 6 ++
drivers/vhost/vhost.c | 222 +-
drivers/vhost/vhost.h | 34 +++
3 files changed, 257 insertions(+), 5 deletions(-)
diff --git a/drivers/vhost/Kconfig b/drivers
, and the mailbox
API to trigger interrupts between the CPUs.
This patchset is also available at:
https://github.com/vwax/linux/tree/vhost/rfc
Vincent Whitchurch (10):
vhost: scsi: use copy_to_iter()
vhost: push virtqueue area pointers into a user struct
vhost: add iov wrapper
vhost: add
On Mon, Aug 23, 2021 at 11:19:56PM +0200, Michael S. Tsirkin wrote:
> On Mon, Aug 23, 2021 at 10:14:37AM +0200, Vincent Whitchurch wrote:
> > vhost always uses SMP-conditional barriers, but these may not be
> > sufficient when vhost is used to communicate between heterogeneous
barriers if requested by userspace.
Signed-off-by: Vincent Whitchurch
---
drivers/vhost/vhost.c | 23 ++-
drivers/vhost/vhost.h | 2 ++
include/uapi/linux/vhost.h | 2 ++
3 files changed, 18 insertions(+), 9 deletions(-)
diff --git a/drivers/vhost/vhost.c b/drivers
Do not call vDPA drivers' callbacks with vq indicies larger than what
the drivers indicate that they support. vDPA drivers do not bounds
check the indices.
Signed-off-by: Vincent Whitchurch
---
drivers/virtio/virtio_vdpa.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/virtio
On Fri, Sep 18, 2020 at 11:47:20AM +0200, Guennadi Liakhovetski wrote:
> On Fri, Sep 18, 2020 at 09:47:45AM +0200, Arnaud POULIQUEN wrote:
> > IMO, as this API is defined in the Linux documentation [5] we should
> > respect it, to ensure
> > one generic implementation. The RPMsg sample client[4]
On Thu, Sep 10, 2020 at 01:13:51PM +0200, Guennadi Liakhovetski wrote:
> +int vhost_rpmsg_start_lock(struct vhost_rpmsg *vr, struct vhost_rpmsg_iter
> *iter,
> +unsigned int qid, ssize_t len)
> + __acquires(vq->mutex)
> +{
> + struct vhost_virtqueue *vq = vr->vq +
On Thu, Sep 17, 2020 at 07:47:06AM +0200, Guennadi Liakhovetski wrote:
> On Tue, Sep 15, 2020 at 02:13:23PM +0200, Arnaud POULIQUEN wrote:
> > So i would be agree with Vincent[2] which proposed to switch on a RPMsg API
> > and creating a vhost rpmsg device. This is also proposed in the
> >
On Thu, Jun 18, 2020 at 04:14:12PM +0200, Guennadi Liakhovetski wrote:
> On Thu, Jun 18, 2020 at 03:52:42PM +0200, Vincent Whitchurch wrote:
> > Note that "the Linux side" is ambiguous for AMP since both sides can be
> > Linux, as they happen to be in my case. I'm running
On Thu, Jun 18, 2020 at 12:39:40PM +0200, Guennadi Liakhovetski wrote:
> On Thu, Jun 18, 2020 at 11:33:24AM +0200, Vincent Whitchurch wrote:
> > By the "normal rpmsg API" I mean register_rpmsg_driver(), rpmsg_send(),
> > etc. That API is not tied to virtio in any way an
On Thu, Jun 18, 2020 at 11:03:42AM +0200, Guennadi Liakhovetski wrote:
> On Wed, Jun 17, 2020 at 09:17:42PM +0200, Vincent Whitchurch wrote:
> > On Wed, May 27, 2020 at 08:05:41PM +0200, Guennadi Liakhovetski wrote:
> > > Linux supports running the RPMsg protocol over th
On Wed, May 27, 2020 at 08:05:41PM +0200, Guennadi Liakhovetski wrote:
> Linux supports running the RPMsg protocol over the VirtIO transport
> protocol, but currently there is only support for VirtIO clients and
> no support for a VirtIO server. This patch adds a vhost-based RPMsg
> server
37 matches
Mail list logo
