On Thu, Feb 7, 2019 at 11:57 PM Stefan Hajnoczi <stefanha@redhat.com> wrote:

> On Wed, Feb 06, 2019 at 07:09:36AM -0800, Frank Yang wrote:
> > I've looked at virtio-vsock and it seems general, but requires Unix
> > sockets, which is not going to work for us on Windows and not going to
> work
> > as expected on macOS (most likely). Is there anything that is similar to
> > and as portable as goldfish pipe which is more like a raw virtqueue? This
> > would then work on memory in the same process, with callbacks registered
> to
> > trigger upon transmission.
>
> virtio-vsock is independent of UNIX domain sockets.  I'm not sure what
> you mean here.
>
> I think Linaro implemented virtio-vsock inside QEMU for the Android
> emulator but I'm not sure how far they got.  Today virtio-vsock relies
> on a Linux host machine because the vhost_vsock.ko driver is used to
> integrate into the host network stack.  The Linaro implementation moved
> that into QEMU userspace (with the drawback that socket(AF_VSOCK) no
> longer works on the host and you need to talk to QEMU instead).
>
>
Thanks for the info! Since we prefer to keep things as canonical as
possible (and thus not mess with existing infrastructure; benefit being
that we can use any upstream QEMU / Linux kernel), it doesn't solve our
vsock issue. We'd also like to decouple the concept of dynamically defined
drivers/devices from the transport. Finally, when host memory is
introduced, it's also possible to be faster than a raw virtqueue for all
data. I'll send out a spec.



> Stefan
>