From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: virtio-dev-return-5381-cohuck=redhat.com@lists.oasis-open.org Sender: List-Post: List-Help: List-Unsubscribe: List-Subscribe: Received: from lists.oasis-open.org (oasis-open.org [10.110.1.242]) by lists.oasis-open.org (Postfix) with ESMTP id 97058986026 for ; Fri, 8 Feb 2019 14:47:01 +0000 (UTC) MIME-Version: 1.0 References: <20190204054053.GE29758@stefanha-x1.localdomain> <20190204101316.4e3e6rj32suwdmur@sirius.home.kraxel.org> <20190205100427.GA2693@work-vm> <20190206070350.vaonutyqljccuh5y@sirius.home.kraxel.org> <20190208075703.GK16257@stefanha-x1.localdomain> In-Reply-To: <20190208075703.GK16257@stefanha-x1.localdomain> From: Frank Yang Date: Fri, 8 Feb 2019 06:46:49 -0800 Message-ID: Content-Type: multipart/alternative; boundary="0000000000000928bb0581630845" Subject: Re: [virtio-dev] Memory sharing device To: Stefan Hajnoczi Cc: Gerd Hoffmann , Roman Kiryanov , "Dr. David Alan Gilbert" , virtio-dev@lists.oasis-open.org List-ID: --0000000000000928bb0581630845 Content-Type: text/plain; charset="UTF-8" On Thu, Feb 7, 2019 at 11:57 PM Stefan Hajnoczi 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 > --0000000000000928bb0581630845 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Feb 7, 2019 at 11:57 PM Stefa= n 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 Uni= x
> 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? T= his
> would then work on memory in the same process, with callbacks register= ed to
> trigger upon transmission.

virtio-vsock is independent of UNIX domain sockets.=C2=A0 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.=C2=A0 Today virtio-vsock re= lies
on a Linux host machine because the vhost_vsock.ko driver is used to
integrate into the host network stack.=C2=A0 The Linaro implementation move= d
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).


--0000000000000928bb0581630845--