(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
>>
>>