On Tue, Mar 11, 2025 at 8:54 AM Jason Wang <jasow...@redhat.com> wrote: > > On Mon, Mar 10, 2025 at 10:15 PM Stefano Garzarella <sgarz...@redhat.com> > wrote: > > > > On Thu, 6 Mar 2025 at 01:17, Jason Wang <jasow...@redhat.com> wrote: > > > > > > On Wed, Mar 5, 2025 at 5:30 PM Stefano Garzarella <sgarz...@redhat.com> > > > wrote: > > > > > > > > On Wed, Mar 05, 2025 at 02:27:12AM -0500, Michael S. Tsirkin wrote: > > > > >On Tue, Mar 04, 2025 at 04:39:02PM -0800, Bobby Eshleman wrote: > > > > >> I think it might be a lot of complexity to bring into the picture > > > > >> from > > > > >> netdev, and I'm not sure there is a big win since the vsock device > > > > >> could > > > > >> also have a vsock->net itself? I think the complexity will come from > > > > >> the > > > > >> address translation, which I don't think netdev buys us because there > > > > >> would still be all of the work work to support vsock in netfilter? > > > > > > > > > >Ugh. > > > > > > > > > >Guys, let's remember what vsock is. > > > > > > > > > >It's a replacement for the serial device with an interface > > > > >that's easier for userspace to consume, as you get > > > > >the demultiplexing by the port number. > > > > > > Interesting, but at least VSOCKETS said: > > > > > > """ > > > config VSOCKETS > > > tristate "Virtual Socket protocol" > > > help > > > Virtual Socket Protocol is a socket protocol similar to TCP/IP > > > allowing communication between Virtual Machines and hypervisor > > > or host. > > > > > > You should also select one or more hypervisor-specific > > > transports > > > below. > > > > > > To compile this driver as a module, choose M here: the module > > > will be called vsock. If unsure, say N. > > > """ > > > > > > This sounds exactly like networking stuff and spec also said something > > > similar > > > > > > """ > > > The virtio socket device is a zero-configuration socket communications > > > device. It facilitates data transfer between the guest and device > > > without using the Ethernet or IP protocols. > > > """ > > > > > > > > > > > > >The whole point of vsock is that people do not want > > > > >any firewalling, filtering, or management on it. > > > > > > We won't get this, these are for ethernet and TCP/IP mostly. > > > > > > > > > > > > >It needs to work with no configuration even if networking is > > > > >misconfigured or blocked. > > > > > > I don't see any blockers that prevent us from zero configuration, or I > > > miss something? > > > > > > > > > > > I agree with Michael here. > > > > > > > > It's been 5 years and my memory is bad, but using netdev seemed like a > > > > mess, especially because in vsock we don't have anything related to > > > > IP/Ethernet/ARP, etc. > > > > > > We don't need to bother with that, kernel support protocols other than > > > TCP/IP. > > > > Do we have an example of any other non-Ethernet device that uses > > netdev? Just to see what we should do. > > Yes, I think can device is one example and it should have others. > > > > > I'm not completely against the idea, but from what I remember when I > > looked at it five years ago, it wasn't that easy and straightforward > > to use. > > Can just hook the packets into its own stack, maybe vsock can do the same. > > > > > > > > > > > > > > I see vsock more as AF_UNIX than netdev. > > > > > > But you have a device in guest that differs from the AF_UNIX. > > > > Yes, but the device is simply for carrying messages. > > Another thing that makes me think of AF_UNIX is the hybrid-vsock > > developed by Firecracker [1] that we also reused in vhost-user-vsock > > [2], where the mapping between AF_VSOCK and AF_UNIX is really > > implemented. > > I see. But the main difference is that vsock can work across the > boundary of guest and host. This makes it hard to be a 100% socket > implementation in the guest.
Or inventing a protocol to make vsosk can be transported via ethernet (not sure this is possible then). Thanks > > Thanks > > > > > Thanks, > > Stefano > > > > [1] > > https://github.com/firecracker-microvm/firecracker/blob/main/docs/vsock.md#firecracker-virtio-vsock-design > > [2] https://github.com/rust-vmm/vhost-device/tree/main/vhost-device-vsock > >
