search for: vhost_transport

...dd add 'features' to virtio-vsock device. > > > > Thanks, > > Stefano > > Why would a remote care about buffer sizes? > > Let's first see what the issues are. If they exist > we can either fix the bugs, or code the bug as a feature in spec. > The vhost_transport '.stream_enqueue' callback [virtio_transport_stream_enqueue()] calls the virtio_transport_send_pkt_info(), passing the user message. This function allocates a new packet, copying the user message, but (before this series) it limits the packet size to the VIRTIO_VSOCK_DEFAULT_RX_BUF_SIZE (4K...

...dd add 'features' to virtio-vsock device. > > > > Thanks, > > Stefano > > Why would a remote care about buffer sizes? > > Let's first see what the issues are. If they exist > we can either fix the bugs, or code the bug as a feature in spec. > The vhost_transport '.stream_enqueue' callback [virtio_transport_stream_enqueue()] calls the virtio_transport_send_pkt_info(), passing the user message. This function allocates a new packet, copying the user message, but (before this series) it limits the packet size to the VIRTIO_VSOCK_DEFAULT_RX_BUF_SIZE (4K...

...nsport_get_ops(). In some cases, like in the virtio_transport_reset_no_sock(), we don't have any socket assigned to the packet received, so we can't use the virtio_transport_get_ops(). In order to allow virtio_transport_reset_no_sock() to use the '.send_pkt' callback from the 'vhost_transport' or 'virtio_transport', we add the 'struct virtio_transport *' to it and to its caller: virtio_transport_recv_pkt(). We moved the 'vhost_transport' and 'virtio_transport' definition, to pass their address to the virtio_transport_recv_pkt(). Signed-off-by: Stefa...

...gt; > Stefano > > > > > > Why would a remote care about buffer sizes? > > > > > > Let's first see what the issues are. If they exist > > > we can either fix the bugs, or code the bug as a feature in spec. > > > > > > > The vhost_transport '.stream_enqueue' callback > > [virtio_transport_stream_enqueue()] calls the virtio_transport_send_pkt_info(), > > passing the user message. This function allocates a new packet, copying > > the user message, but (before this series) it limits the packet size to > >...

...gt; > Stefano > > > > > > Why would a remote care about buffer sizes? > > > > > > Let's first see what the issues are. If they exist > > > we can either fix the bugs, or code the bug as a feature in spec. > > > > > > > The vhost_transport '.stream_enqueue' callback > > [virtio_transport_stream_enqueue()] calls the virtio_transport_send_pkt_info(), > > passing the user message. This function allocates a new packet, copying > > the user message, but (before this series) it limits the packet size to > >...

...port never allowed half-closed socket on the host side. As Jorgen explained [1] this is due to the implementation of VMCI. Since we want to have the same behaviour across all transports, this series adds a section in the "Implementation notes" to exaplain this behaviour, and changes the vhost_transport to behave the same way. [1] https://patchwork.ozlabs.org/cover/847998/#1831400 Stefano Garzarella (2): vsock: add half-closed socket details in the implementation notes vhost/vsock: don't allow half-closed socket in the host drivers/vhost/vsock.c | 17 ++++++++++++++++- net/vmw_vsock...

...port never allowed half-closed socket on the host side. As Jorgen explained [1] this is due to the implementation of VMCI. Since we want to have the same behaviour across all transports, this series adds a section in the "Implementation notes" to exaplain this behaviour, and changes the vhost_transport to behave the same way. [1] https://patchwork.ozlabs.org/cover/847998/#1831400 Stefano Garzarella (2): vsock: add half-closed socket details in the implementation notes vhost/vsock: don't allow half-closed socket in the host drivers/vhost/vsock.c | 17 ++++++++++++++++- net/vmw_vsock...

...remote care about buffer sizes? > > > > > > > > > > Let's first see what the issues are. If they exist > > > > > we can either fix the bugs, or code the bug as a feature in spec. > > > > > > > > > > > > > The vhost_transport '.stream_enqueue' callback > > > > [virtio_transport_stream_enqueue()] calls the virtio_transport_send_pkt_info(), > > > > passing the user message. This function allocates a new packet, copying > > > > the user message, but (before this series) it limits...

...remote care about buffer sizes? > > > > > > > > > > Let's first see what the issues are. If they exist > > > > > we can either fix the bugs, or code the bug as a feature in spec. > > > > > > > > > > > > > The vhost_transport '.stream_enqueue' callback > > > > [virtio_transport_stream_enqueue()] calls the virtio_transport_send_pkt_info(), > > > > passing the user message. This function allocates a new packet, copying > > > > the user message, but (before this series) it limits...

...vhost_work *work) virtio_transport_deliver_tap_pkt(pkt); /* Only accept correctly addressed packets */ - if (le64_to_cpu(pkt->hdr.src_cid) == vsock->guest_cid) + if (le64_to_cpu(pkt->hdr.src_cid) == vsock->guest_cid && + le64_to_cpu(pkt->hdr.dst_cid) == + vhost_transport_get_local_cid()) virtio_transport_recv_pkt(&vhost_transport, pkt); else virtio_transport_free_pkt(pkt); -- 2.23.0

...vhost_work *work) virtio_transport_deliver_tap_pkt(pkt); /* Only accept correctly addressed packets */ - if (le64_to_cpu(pkt->hdr.src_cid) == vsock->guest_cid) + if (le64_to_cpu(pkt->hdr.src_cid) == vsock->guest_cid && + le64_to_cpu(pkt->hdr.dst_cid) == + vhost_transport_get_local_cid()) virtio_transport_recv_pkt(&vhost_transport, pkt); else virtio_transport_free_pkt(pkt); -- 2.23.0

...> > > As Jorgen explained [1] this is due to the implementation of VMCI. > > > > Since we want to have the same behaviour across all transports, this > > series adds a section in the "Implementation notes" to exaplain this > > behaviour, and changes the vhost_transport to behave the same way. > > > > [1] https://patchwork.ozlabs.org/cover/847998/#1831400 > > Half closed sockets are very useful, and lots of > applications use tricks to swap a vsock for a tcp socket, > which might as a result break. Got it! > > If VMCI really care...

...> > > As Jorgen explained [1] this is due to the implementation of VMCI. > > > > Since we want to have the same behaviour across all transports, this > > series adds a section in the "Implementation notes" to exaplain this > > behaviour, and changes the vhost_transport to behave the same way. > > > > [1] https://patchwork.ozlabs.org/cover/847998/#1831400 > > Half closed sockets are very useful, and lots of > applications use tricks to swap a vsock for a tcp socket, > which might as a result break. Got it! > > If VMCI really care...

...> > > > > Thanks, > > > Stefano > > > > Why would a remote care about buffer sizes? > > > > Let's first see what the issues are. If they exist > > we can either fix the bugs, or code the bug as a feature in spec. > > > > The vhost_transport '.stream_enqueue' callback > [virtio_transport_stream_enqueue()] calls the virtio_transport_send_pkt_info(), > passing the user message. This function allocates a new packet, copying > the user message, but (before this series) it limits the packet size to > the VIRTIO_VSOCK_DEF...

...t; > > > Why would a remote care about buffer sizes? > > > > > > > > Let's first see what the issues are. If they exist > > > > we can either fix the bugs, or code the bug as a feature in spec. > > > > > > > > > > The vhost_transport '.stream_enqueue' callback > > > [virtio_transport_stream_enqueue()] calls the virtio_transport_send_pkt_info(), > > > passing the user message. This function allocates a new packet, copying > > > the user message, but (before this series) it limits the packet siz...

...? > > > > > > > > > > > > Let's first see what the issues are. If they exist > > > > > > we can either fix the bugs, or code the bug as a feature in spec. > > > > > > > > > > > > > > > > The vhost_transport '.stream_enqueue' callback > > > > > [virtio_transport_stream_enqueue()] calls the virtio_transport_send_pkt_info(), > > > > > passing the user message. This function allocates a new packet, copying > > > > > the user message, but (before this se...

...a/drivers/vhost/vsock.c b/drivers/vhost/vsock.c > index 6d7e4f022748..b235f4bbe8ea 100644 > --- a/drivers/vhost/vsock.c > +++ b/drivers/vhost/vsock.c > @@ -831,7 +831,8 @@ static int __init vhost_vsock_init(void) > { > int ret; > > - ret = vsock_core_init(&vhost_transport.transport); > + ret = vsock_core_register(&vhost_transport.transport, > + VSOCK_TRANSPORT_F_H2G); > if (ret < 0) > return ret; > return misc_register(&vhost_vsock_misc); > @@ -840,7 +841,7 @@ static i...

...a/drivers/vhost/vsock.c b/drivers/vhost/vsock.c > index 6d7e4f022748..b235f4bbe8ea 100644 > --- a/drivers/vhost/vsock.c > +++ b/drivers/vhost/vsock.c > @@ -831,7 +831,8 @@ static int __init vhost_vsock_init(void) > { > int ret; > > - ret = vsock_core_init(&vhost_transport.transport); > + ret = vsock_core_register(&vhost_transport.transport, > + VSOCK_TRANSPORT_F_H2G); > if (ret < 0) > return ret; > return misc_register(&vhost_vsock_misc); > @@ -840,7 +841,7 @@ static i...

...tions(+), 81 deletions(-) diff --git a/drivers/vhost/vsock.c b/drivers/vhost/vsock.c index 6d7e4f022748..375af01a5b64 100644 --- a/drivers/vhost/vsock.c +++ b/drivers/vhost/vsock.c @@ -386,6 +386,8 @@ static bool vhost_vsock_more_replies(struct vhost_vsock *vsock) static struct virtio_transport vhost_transport = { .transport = { + .features = VSOCK_TRANSPORT_F_H2G, + .get_local_cid = vhost_transport_get_local_cid, .init = virtio_transport_do_socket_init, @@ -831,7 +833,7 @@ static int __init vhost_vsock_init(void) { int ret; - ret = vsock_cor...

Hi all, this series adds the multi-transports support to vsock, following this proposal: https://www.spinics.net/lists/netdev/msg575792.html With the multi-transports support, we can use vsock with nested VMs (using also different hypervisors) loading both guest->host and host->guest transports at the same time. Before this series, vmci-transport supported this behavior but only using