search for: vsock_loopback

...ERS > index 760049454a23..c2a3dc3113ba 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -17239,6 +17239,7 @@ F: net/vmw_vsock/diag.c > F: net/vmw_vsock/af_vsock_tap.c > F: net/vmw_vsock/virtio_transport_common.c > F: net/vmw_vsock/virtio_transport.c > +F: net/vmw_vsock/vsock_loopback.c > F: drivers/net/vsockmon.c > F: drivers/vhost/vsock.c > F: tools/testing/vsock/ At this point you are most active in virtio-vsock and I am reviewing patches on a best-effort basis. Feel free to add yourself as maintainer. > diff --git a/net/vmw_vsock/vsock_loopback.c b/net/vmw_...

...ERS > index 760049454a23..c2a3dc3113ba 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -17239,6 +17239,7 @@ F: net/vmw_vsock/diag.c > F: net/vmw_vsock/af_vsock_tap.c > F: net/vmw_vsock/virtio_transport_common.c > F: net/vmw_vsock/virtio_transport.c > +F: net/vmw_vsock/vsock_loopback.c > F: drivers/net/vsockmon.c > F: drivers/vhost/vsock.c > F: tools/testing/vsock/ At this point you are most active in virtio-vsock and I am reviewing patches on a best-effort basis. Feel free to add yourself as maintainer. > diff --git a/net/vmw_vsock/vsock_loopback.c b/net/vmw_...

...3113ba 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -17239,6 +17239,7 @@ F: net/vmw_vsock/diag.c > > F: net/vmw_vsock/af_vsock_tap.c > > F: net/vmw_vsock/virtio_transport_common.c > > F: net/vmw_vsock/virtio_transport.c > > +F: net/vmw_vsock/vsock_loopback.c > > F: drivers/net/vsockmon.c > > F: drivers/vhost/vsock.c > > F: tools/testing/vsock/ > > At this point you are most active in virtio-vsock and I am reviewing > patches on a best-effort basis. Feel free to add yourself as > maintainer. > Sure, I'd be h...

v2: - style fixes [Dave] - removed RCU sync and changed 'the_vsock_loopback' in a global static variable [Stefan] - use G2H transport when local transport is not loaded and remote cid is VMADDR_CID_LOCAL [Stefan] - rebased on net-next v1: https://patchwork.kernel.org/cover/11251735/ This series introduces a new transport (vsock_loopback) to handle local commu...

...MAINTAINERS > > > +++ b/MAINTAINERS > > > @@ -17239,6 +17239,7 @@ F: net/vmw_vsock/diag.c > > > F: net/vmw_vsock/af_vsock_tap.c > > > F: net/vmw_vsock/virtio_transport_common.c > > > F: net/vmw_vsock/virtio_transport.c > > > +F: net/vmw_vsock/vsock_loopback.c > > > F: drivers/net/vsockmon.c > > > F: drivers/vhost/vsock.c > > > F: tools/testing/vsock/ > > > > At this point you are most active in virtio-vsock and I am reviewing > > patches on a best-effort basis. Feel free to add yourself as > > ma...

...MAINTAINERS > > > +++ b/MAINTAINERS > > > @@ -17239,6 +17239,7 @@ F: net/vmw_vsock/diag.c > > > F: net/vmw_vsock/af_vsock_tap.c > > > F: net/vmw_vsock/virtio_transport_common.c > > > F: net/vmw_vsock/virtio_transport.c > > > +F: net/vmw_vsock/vsock_loopback.c > > > F: drivers/net/vsockmon.c > > > F: drivers/vhost/vsock.c > > > F: tools/testing/vsock/ > > > > At this point you are most active in virtio-vsock and I am reviewing > > patches on a best-effort basis. Feel free to add yourself as > > ma...

On Tue, Nov 19, 2019 at 12:01:15PM +0100, Stefano Garzarella wrote: > This series introduces a new transport (vsock_loopback) to handle > local communication. > This could be useful to test vsock core itself and to allow developers > to test their applications without launching a VM. > > Before this series, vmci and virtio transports allowed this behavior, > but only in the guest. > We are moving th...

...rzarella wrote: > On Thu, Nov 21, 2019 at 10:59:48AM +0100, Stefano Garzarella wrote: > > On Thu, Nov 21, 2019 at 09:34:58AM +0000, Stefan Hajnoczi wrote: > > > On Tue, Nov 19, 2019 at 12:01:19PM +0100, Stefano Garzarella wrote: > > > > +static struct workqueue_struct *vsock_loopback_workqueue; > > > > +static struct vsock_loopback *the_vsock_loopback; > > > > > > the_vsock_loopback could be a static global variable (not a pointer) and > > > vsock_loopback_workqueue could also be included in the struct. > > > > > > The...

...nterrupts in the loopback transport as >there is no access to the queue with skbs from interrupt context. Both >virtio and vhost transports work in the same way. Yep, this is a good point! > >Signed-off-by: Arseniy Krasnov <AVKrasnov at sberdevices.ru> >--- > net/vmw_vsock/vsock_loopback.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) LGTM! (net-next material) Reviewed-by: Stefano Garzarella <sgarzare at redhat.com> Thanks, Stefano > >diff --git a/net/vmw_vsock/vsock_loopback.c b/net/vmw_vsock/vsock_loopback.c >index e3afc0c866f5..5c6360df1f31 10064...

> From: Stefano Garzarella [mailto:sgarzare at redhat.com] > Sent: Tuesday, November 19, 2019 12:01 PM > This series introduces a new transport (vsock_loopback) to handle > local communication. > This could be useful to test vsock core itself and to allow developers > to test their applications without launching a VM. > > Before this series, vmci and virtio transports allowed this behavior, > but only in the guest. > We are moving th...

> From: Stefano Garzarella [mailto:sgarzare at redhat.com] > Sent: Tuesday, November 19, 2019 12:01 PM > This series introduces a new transport (vsock_loopback) to handle > local communication. > This could be useful to test vsock core itself and to allow developers > to test their applications without launching a VM. > > Before this series, vmci and virtio transports allowed this behavior, > but only in the guest. > We are moving th...

On Thu, Nov 21, 2019 at 02:45:32PM +0000, Jorgen Hansen wrote: > > From: Stefano Garzarella [mailto:sgarzare at redhat.com] > > Sent: Tuesday, November 19, 2019 12:01 PM > > This series introduces a new transport (vsock_loopback) to handle > > local communication. > > This could be useful to test vsock core itself and to allow developers > > to test their applications without launching a VM. > > > > Before this series, vmci and virtio transports allowed this behavior, > > but only in th...

...t/vmw_vsock/af_vsock.c | 55 ++++++- > net/vmw_vsock/virtio_transport.c | 2 + > net/vmw_vsock/virtio_transport_common.c | 24 +++ > net/vmw_vsock/vsock_bpf.c | 175 +++++++++++++++++++++ > net/vmw_vsock/vsock_loopback.c | 2 + > tools/testing/selftests/bpf/config.aarch64 | 2 + > tools/testing/selftests/bpf/config.s390x | 3 + > tools/testing/selftests/bpf/config.x86_64 | 3 + > .../selftests/bpf/prog_tests/sockmap_listen.c | 163 +++++++++++...

...t.c | 6 ---- >> > > > > net/vmw_vsock/virtio_transport.c | 1 - >> > > > > net/vmw_vsock/virtio_transport_common.c | 7 ---- >> > > > > net/vmw_vsock/vmci_transport.c | 2 +- >> > > > > net/vmw_vsock/vsock_loopback.c | 1 - >> > > > > 9 files changed, 58 insertions(+), 36 deletions(-) >> > > > > >> > > > > diff --git a/drivers/vhost/vsock.c b/drivers/vhost/vsock.c >> > > > > index ae8891598a48..d5d6a3c3f273 100644 >> >...

Hi, now that we have multi-transport upstream, I started to take a look to support network namespace (netns) in vsock. As we partially discussed in the multi-transport proposal [1], it could be nice to support network namespace in vsock to reach the following goals: - isolate host applications from guest applications using the same ports with CID_ANY - assign the same CID of VMs running in

Hi, now that we have multi-transport upstream, I started to take a look to support network namespace (netns) in vsock. As we partially discussed in the multi-transport proposal [1], it could be nice to support network namespace in vsock to reach the following goals: - isolate host applications from guest applications using the same ports with CID_ANY - assign the same CID of VMs running in