On Thu, Feb 7, 2019 at 11:57 PM Stefan Hajnoczi <stefa...@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 >
