Re: Hermetic virtio-vsock in QEMU

[Paolo Bonzini]

On 5/8/24 11:38, Stefano Garzarella wrote:
> On Wed, May 08, 2024 at 01:13:09PM GMT, Marc-André Lureau wrote:
> > Hi
> >
> > On Wed, May 8, 2024 at 11:50 AM Stefano Garzarella 
> > <sgarzare@redhat.com> wrote:
> > > Hi Roman,
> > >
> > > On Tue, May 07, 2024 at 11:20:50PM GMT, Roman Kiryanov wrote:
> > > >Hi Stefano,
> > > >
> > > >On Tue, May 7, 2024 at 1:10 AM Stefano Garzarella 
> > > <sgarzare@redhat.com> wrote:
> > > >> I have no experience with Windows, but what we need for vhost-user 
> > > is:
> > > >>
> > > >> - AF_UNIX and be able to send file descriptors using ancillary data
> > > >>    (i.e. SCM_RIGHTS)
> > > >
> > > >As far as I understand, Windows does NOT support SCM_RIGHTS over 
> > > AF_UNIX.
> > >
> > > Thank you for the information. This is unfortunate and does not allow
> > > us to use vhost-user as it is on Windows.
> >
> > fwiw, Windows has other mechanisms to share resources between processes.
> >
> > To share/pass sockets, you can use WSADuplicateSocket. For shared
> > memory and other resources, DuplicateHandle API.
>
> Cool, thanks for sharing that. So it could be done, but I think we need
> to extend the vhost-user protocol to work with Windows.

It would be possible to implement the memfd backend for Windows, using 
the CreateFileMapping() API.

However, the vhost-user protocol's VHOST_USER_SET_MEM_TABLE requests do 
not have any padding that can be used to pass the handle to the target. 
An extended version would be necessary.

One difference between Unix and Windows is that, if the vhost-server 
messes up the handling of messages from the socket, and therefore it 
does not close the handle, it is leaked forever.  This is not a huge 
deal per se, but I think it means that QEMU is not allowed to "open" a 
privileged vhost-user server process with PROCESS_DUP_HANDLE rights 
(translation: QEMU cannot provide duplicate handles to a privileged 
vhost-user server process).

Also I'm not sure what the cost of DuplicateHandle() is, and whether 
it's a good idea to do it for every region on every 
VHOST_USER_SET_MEM_TABLE request.  But VHOST_USER_SET_MEM_TABLE is not a 
fast path, so perhaps it's okay.

I think a virtio-vsock implementation in QEMU would be easier, lacking 
another usecase for vhost-user on Windows.

The main design question is whether multiple virtio-vsock devices for 
the same guest should share the CID space or not (I think it should, but 
I'm not 100% sure).  To connect host<->guest you could have a QOM 
object, here I am naming it vsock-forward as an example:

  -object vsock-forward,socket=SocketAddress,port=uint32,mode=connect

     takes the address of a listening socket on the host, and all
     connections to the given vsock port would be forwarded to the
     socket.

  -object vsock-forward,socket=SocketAddress,port=uint32,mode=listen

     creates a listening socket on the host, and all connections to that
     socket would be forwarded to the vsock port, where the guest should
     set up a server.

i.e. "mode" is what QEMU does, whether connect to the address or listen 
on it.

Another possibility for the names is to copy "hostfwd" and "guestfwd" 
names that are in netdev -netdev, i.e. respectively:

  -object vsock-guestfwd,socket=SocketAddress,port=uint32
  -object vsock-hostfwd,socket=SocketAddress,port=uint32

but I think it's worse.

Paolo