Re: guest / host buffer sharing ...

[Frank Yang <lfy@google.com>]

[-- Attachment #1: Type: text/plain, Size: 3242 bytes --]

So I'm not really sure why people are having issues sharing buffers that
live on the GPU. Doesn't that show up as some integer ID on the host, and
some $GuestFramework (dmabuf, gralloc) ID on the guest, and it all works
out due to maintaining the correspondence in your particular stack of
virtual devices? For example, if you want to do video decode in hardware on
an Android guest, there should be a gralloc buffer whose handle contains
enough information to reconstruct the GPU buffer ID on the host, because
gralloc is how processes communicate gpu buffer ids to each other on
Android.

BTW, if we have a new device just for this, this should also be more
flexible than being udmabuf on the host. There are other OSes than Linux.
Keep in mind, also, that across different drivers even on Linux, e.g.,
NVIDIA proprietary, dmabuf might not always be available.

As for host CPU memory that is allocated in various ways, I think Android
Emulator has built a very flexible/general solution, esp if we need to
share a host CPU buffer allocated via something thats not completely under
our control, such as Vulkan. We reserve a PCI BAR for that and map memory
directly from the host Vk drier into there, via the address space device.
It's

https://android.googlesource.com/platform/external/qemu/+/refs/heads/emu-master-dev/hw/pci/goldfish_address_space.c

https://android.googlesource.com/platform/external/qemu/+/refs/heads/emu-master-dev/android/android-emu/android/emulation/address_space_device.cpp#205


Number of copies is also completely under the user's control, unlike
ivshmem. It also is not tied to any particular device such as gpu or codec.
Since the memory is owned by the host and directly mapped to the guest PCI
without any abstraction, it's contiguous, it doesn't carve out guest RAM,
doesn't waste CMA, etc.

On Thu, Nov 7, 2019 at 4:13 AM Stefan Hajnoczi <stefanha@gmail.com> wrote:

> On Wed, Nov 6, 2019 at 1:50 PM Gerd Hoffmann <kraxel@redhat.com> wrote:
> > > In the graphics buffer sharing use case, how does the other side
> > > determine how to interpret this data?
> >
> > The idea is to have free form properties (name=value, with value being
> > a string) for that kind of metadata.
> >
> > > Shouldn't there be a VIRTIO
> > > device spec for the messaging so compatible implementations can be
> > > written by others?
> >
> > Adding a list of common properties to the spec certainly makes sense,
> > so everybody uses the same names.  Adding struct-ed properties for
> > common use cases might be useful too.
>
> Why not define VIRTIO devices for wayland and friends?
>
> This new device exposes buffer sharing plus properties - effectively a
> new device model nested inside VIRTIO.  The VIRTIO device model has
> the necessary primitives to solve the buffer sharing problem so I'm
> struggling to see the purpose of this new device.
>
> Custom/niche applications that do not wish to standardize their device
> type can maintain out-of-tree VIRTIO devices.  Both kernel and
> userspace drivers can be written for the device and there is already
> VIRTIO driver code that can be reused.  They have access to the full
> VIRTIO device model, including feature negotiation and configuration
> space.
>
> Stefan
>
>

[-- Attachment #2: Type: text/html, Size: 4191 bytes --]