[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <sejux5gvpakaopre6mk3fyudi2f56hiuxuevfzay3oohg773kd@5odm3x3fryuq>
Date: Tue, 28 May 2024 17:53:37 +0200
From: Stefano Garzarella <sgarzare@...hat.com>
To: Paolo Bonzini <pbonzini@...hat.com>
Cc: Alexander Graf <graf@...zon.com>, Alexander Graf <agraf@...raf.de>,
Dorjoy Chowdhury <dorjoychy111@...il.com>, virtualization@...ts.linux.dev, kvm@...r.kernel.org,
netdev@...r.kernel.org, stefanha@...hat.com
Subject: Re: How to implement message forwarding from one CID to another in
vhost driver
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@...hat.com> wrote:
>> >I think it's either that or implementing virtio-vsock in userspace
>> >(https://lore.kernel.org/qemu-devel/30baeb56-64d2-4ea3-8e53-6a5c50999979@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.
Stefano
Powered by blists - more mailing lists