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