On Tue, May 28, 2024 at 06:38:24PM GMT, Paolo Bonzini wrote:
On Tue, May 28, 2024 at 5:53 PM Stefano Garzarella <sgarzare@xxxxxxxxxx> 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 <sgarzare@xxxxxxxxxx> wrote:
>> >I think it's either that or implementing virtio-vsock in userspace
>> >(https://lore.kernel.org/qemu-devel/30baeb56-64d2-4ea3-8e53-6a5c50999979@xxxxxxxxxx/,
>> >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?
Yep!
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.
Right, good point!
We can also support something similar in vhost-user-vsock, where instead
of using AF_UNIX and firecracker's hybrid vsock, we can redirect
everything to VMADDR_CID_LOCAL.
Alex what do you think? That would simplify things a lot to do.
The only difference is that the application in the host has to talk to
VMADDR_CID_LOCAL (1).
Stefano
