[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
- Re: Hermetic virtio-vsock in QEMU, Stefano Garzarella, 2024/05/07
- Re: Hermetic virtio-vsock in QEMU, Roman Kiryanov, 2024/05/08
- Re: Hermetic virtio-vsock in QEMU, Stefano Garzarella, 2024/05/08
- Re: Hermetic virtio-vsock in QEMU, Marc-André Lureau, 2024/05/08
- Re: Hermetic virtio-vsock in QEMU, Stefano Garzarella, 2024/05/08
- Re: Hermetic virtio-vsock in QEMU,
Paolo Bonzini <=
- Re: Hermetic virtio-vsock in QEMU, Daniel P . Berrangé, 2024/05/08
- Re: Hermetic virtio-vsock in QEMU, Paolo Bonzini, 2024/05/08
- Re: Hermetic virtio-vsock in QEMU, Daniel P . Berrangé, 2024/05/08