Re: [virtio-dev] Memory sharing device

[Frank Yang <lfy@google.com>]

(Virtio-serial also doesn't seem like a good option due to specialization to console forwarding and having an encoded limit on the number of connections)

On Wed, Feb 6, 2019 at 7:09 AM Frank Yang <lfy@google.com> wrote:

On Tue, Feb 5, 2019 at 11:03 PM Gerd Hoffmann <kraxel@redhat.com> wrote:

On Tue, Feb 05, 2019 at 01:06:42PM -0800, Roman Kiryanov wrote:
> Hi Dave,
>
> > In virtio-fs we have two separate stages:
> >Â Âa) A shared arena is setup (and that's what the spec Stefan pointed to is about) -
> >Â Â Â it's statically allocated at device creation and corresponds to a chunk
> >Â Â Â of guest physical address space
>
> We do exactly the same:
> https://android.googlesource.com/platform/external/qemu/+/emu-master-dev/hw/pci/goldfish_address_space.c#659
>
> >Â Âb) During operation the guest kernel asks for files to be mapped into
> >Â Â Â part of that arena dynamically, using commands sent over the queue
> >Â Â Â - our queue carries FUSE commands, and we've added two new FUSE
> >   commands to perform the map/unmap. They talk in terms of offsets
> >Â Â Â within the shared arena, rather than GPAs.
>
> In our case we have no files to map, only pointers returned from
> OpenGL or Vulkan.
> Do you have the approach to share for this use case?

Fundamentally the same:Â The memory region (PCI bar in case of
virtio-pci) reserves address space. The guest manages the address
space, it can ask the host to map host gpu resources there.

Well, that is at least the plan. Some incomplete WIP patches exist, I'm
still busy hammering virtio-gpu ttm code into shape so it can support
different kinds of gpu objects.

> Do you this it is possible to have virtio-pipe where we could send
> arbitrary blobs between
> guest and host?

Well, there are virtio-serial and virtio-vsock which both give you a
pipe between host and guest, simliar to a serial line / tcp socket.
Dunno how good they are at handling larger blobs though.

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.

cheers,
 Gerd