On Tue, May 28, 2024 at 5:53 PM Stefano Garzarella <sgarz...@redhat.com> wrote: > > On Tue, May 28, 2024 at 05:49:32PM GMT, Paolo Bonzini wrote: > >On Tue, May 28, 2024 at 5:41 PM Stefano Garzarella <sgarz...@redhat.com> > >wrote: > >> >I think it's either that or implementing virtio-vsock in userspace > >> >(https://lore.kernel.org/qemu-devel/30baeb56-64d2-4ea3-8e53-6a5c50999...@redhat.com/, > >> >search for "To connect host<->guest"). > >> > >> For in this case AF_VSOCK can't be used in the host, right? > >> So it's similar to vhost-user-vsock. > > > >Not sure if I understand but in this case QEMU knows which CIDs are > >forwarded to the host (either listen on vsock and connect to the host, > >or vice versa), so there is no kernel and no VMADDR_FLAG_TO_HOST > >involved. > > I meant that the application in the host that wants to connect to the > guest cannot use AF_VSOCK in the host, but must use the one where QEMU > is listening (e.g. AF_INET, AF_UNIX), right? > > I think one of Alex's requirements was that the application in the host > continue to use AF_VSOCK as in their environment.
Can the host use VMADDR_CID_LOCAL for host-to-host communication? If so, the proposed "-object vsock-forward" syntax can connect to it and it should work as long as the application on the host does not assume that it is on CID 3. Paolo
