Hi Bobby,
first of all, thank you for starting this work again!

On Wed, Mar 12, 2025 at 07:28:33PM -0700, Bobby Eshleman wrote:

Hey all,

Apologies for forgetting the 'net-next' prefix on this one. Should I
resend or no?

I'd say let's do a firts review cycle on this, then you can re-post.
Please check also maintainer cced, it looks like someone is missing:
https://patchwork.kernel.org/project/netdevbpf/patch/20250312-vsock-netns-v2-1-84bffa1aa97a@gmail.com/

Best,
Bobby

On Wed, Mar 12, 2025 at 01:59:34PM -0700, Bobby Eshleman wrote:

quoted

Picking up Stefano's v1 [1], this series adds netns support to
vhost-vsock. Unlike v1, this series does not address guest-to-host (g2h)
namespaces, defering that for future implementation and discussion.

Any vsock created with /dev/vhost-vsock is a global vsock, accessible
from any namespace. Any vsock created with /dev/vhost-vsock-netns is a
"scoped" vsock, accessible only to sockets in its namespace. If a global
vsock or scoped vsock share the same CID, the scoped vsock takes
precedence.

This inside the netns, right?
I mean if we are in a netns, and there is a VM A attached to 
/dev/vhost-vsock-netns witch CID=42 and a VM B attached to 
/dev/vhost-vsock also with CID=42, this means that VM A will not be 
accessible in the netns, but it can be accessible outside of the netns,
right?

quoted

If a socket in a namespace connects with a global vsock, the CID becomes
unavailable to any VMM in that namespace when creating new vsocks. If
disconnected, the CID becomes available again.

IIUC if an application in the host running in a netns, is connected to a 
guest attached to /dev/vhost-vsock (e.g. CID=42), a new guest can't be 
ask for the same CID (42) on /dev/vhost-vsock-netns in the same netns 
till that connection is active. Is that right?

quoted

Testing

QEMU with /dev/vhost-vsock-netns support:
	https://github.com/beshleman/qemu/tree/vsock-netns

You can also use unmodified QEMU using `vhostfd` parameter of 
`vhost-vsock-pci` device:

# FD will contain the file descriptor to /dev/vhost-vsock-netns
exec {FD}<>/dev/vhost-vsock-netns

# pass FD to the device, this is used for example by libvirt
qemu-system-x86_64 -smp 2 -M q35,accel=kvm,memory-backend=mem \
   -drive file=fedora.qcow2,format=qcow2,if=virtio \
   -object memory-backend-memfd,id=mem,size=512M \
   -device vhost-vsock-pci,vhostfd=${FD},guest-cid=42 -nographic

That said, I agree we can extend QEMU with `netns` param too.

BTW, I'm traveling, I'll be back next Tuesday and I hope to take a 
deeper look to the patches.

Thanks,
Stefano

quoted

Test: Scoped vsocks isolated by namespace

  host# ip netns add ns1
  host# ip netns add ns2
  host# ip netns exec ns1 \
				  qemu-system-x86_64 \
					  -m 8G -smp 4 -cpu host -enable-kvm \
					  -serial mon:stdio \
					  -drive if=virtio,file=${IMAGE1} \
					  -device 
					  vhost-vsock-pci,netns=on,guest-cid=15
  host# ip netns exec ns2 \
				  qemu-system-x86_64 \
					  -m 8G -smp 4 -cpu host -enable-kvm \
					  -serial mon:stdio \
					  -drive if=virtio,file=${IMAGE2} \
					  -device vhost-vsock-pci,netns=on,guest-cid=15

  host# socat - VSOCK-CONNECT:15:1234
  2025/03/10 17:09:40 socat[255741] E connect(5, AF=40 cid:15 port:1234, 16): No such device

  host# echo foobar1 | sudo ip netns exec ns1 socat - VSOCK-CONNECT:15:1234
  host# echo foobar2 | sudo ip netns exec ns2 socat - VSOCK-CONNECT:15:1234

  vm1# socat - VSOCK-LISTEN:1234
  foobar1
  vm2# socat - VSOCK-LISTEN:1234
  foobar2

Test: Global vsocks accessible to any namespace

  host# qemu-system-x86_64 \
	  -m 8G -smp 4 -cpu host -enable-kvm \
	  -serial mon:stdio \)
	  -drive if=virtio,file=${IMAGE2} \
	  -device vhost-vsock-pci,guest-cid=15,netns=off

  host# echo foobar | sudo ip netns exec ns1 socat - VSOCK-CONNECT:15:1234

  vm# socat - VSOCK-LISTEN:1234
  foobar

Test: Connecting to global vsock makes CID unavailble to namespace

  host# qemu-system-x86_64 \
	  -m 8G -smp 4 -cpu host -enable-kvm \
	  -serial mon:stdio \
	  -drive if=virtio,file=${IMAGE2} \
	  -device vhost-vsock-pci,guest-cid=15,netns=off

  vm# socat - VSOCK-LISTEN:1234

  host# sudo ip netns exec ns1 socat - VSOCK-CONNECT:15:1234
  host# ip netns exec ns1 \
				  qemu-system-x86_64 \
					  -m 8G -smp 4 -cpu host -enable-kvm \
					  -serial mon:stdio \
					  -drive if=virtio,file=${IMAGE1} \
					  -device vhost-vsock-pci,netns=on,guest-cid=15

  qemu-system-x86_64: -device vhost-vsock-pci,netns=on,guest-cid=15: vhost-vsock: unable to set guest cid: Address already in use

Signed-off-by: Bobby Eshleman <redacted>
---
Changes in v2:
- only support vhost-vsock namespaces
- all g2h namespaces retain old behavior, only common API changes
  impacted by vhost-vsock changes
- add /dev/vhost-vsock-netns for "opt-in"
- leave /dev/vhost-vsock to old behavior
- removed netns module param
- Link to v1: https://lore.kernel.org/r/20200116172428.311437-1-sgarzare@redhat.com (local)

Changes in v1:
- added 'netns' module param to vsock.ko to enable the
  network namespace support (disabled by default)
- added 'vsock_net_eq()' to check the "net" assigned to a socket
  only when 'netns' support is enabled
- Link to RFC: https://patchwork.ozlabs.org/cover/1202235/

---
Stefano Garzarella (3):
      vsock: add network namespace support
      vsock/virtio_transport_common: handle netns of received packets
      vhost/vsock: use netns of process that opens the vhost-vsock-netns device

 drivers/vhost/vsock.c                   | 96 +++++++++++++++++++++++++++------
 include/linux/miscdevice.h              |  1 +
 include/linux/virtio_vsock.h            |  2 +
 include/net/af_vsock.h                  | 10 ++--
 net/vmw_vsock/af_vsock.c                | 85 +++++++++++++++++++++++------
 net/vmw_vsock/hyperv_transport.c        |  2 +-
 net/vmw_vsock/virtio_transport.c        |  5 +-
 net/vmw_vsock/virtio_transport_common.c | 14 ++++-
 net/vmw_vsock/vmci_transport.c          |  4 +-
 net/vmw_vsock/vsock_loopback.c          |  4 +-
 10 files changed, 180 insertions(+), 43 deletions(-)
---
base-commit: 0ea09cbf8350b70ad44d67a1dcb379008a356034
change-id: 20250312-vsock-netns-45da9424f726

Best regards,
--
Bobby Eshleman [off-list ref]