Re: guest / host buffer sharing ...

[Tomasz Figa]

Hi Frank,

On Fri, Nov 8, 2019 at 12:10 AM Frank Yang <address@hidden> wrote:
>
> 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.

I don't think we really have any issues with that. :)

We just need a standard for:
a) assignment of buffer IDs that the guest can refer to,
b) making all virtual devices understand the IDs from a) when such are
passed to them by the guest.

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

I recall that we already agreed on exposing host memory to the guests
using PCI BARs. There should be work-in-progress patches for
virtio-gpu to use that instead of shadow buffers and transfers.

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

That's one of the reasons we use host-based allocations in VMs running
on Chrome OS. That said, I think everyone here agrees that it's a good
optimization that should be specified and implemented.

P.S. The common mailing list netiquette recommends bottom posting and
plain text emails.

Best regards,
Tomasz

>
> On Thu, Nov 7, 2019 at 4:13 AM Stefan Hajnoczi <address@hidden> wrote:
>>
>> On Wed, Nov 6, 2019 at 1:50 PM Gerd Hoffmann <address@hidden> 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
>>