qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Hermetic virtio-vsock in QEMU


From: Paolo Bonzini
Subject: Re: Hermetic virtio-vsock in QEMU
Date: Wed, 8 May 2024 14:37:52 +0200
User-agent: Mozilla Thunderbird

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]