On Tue, Nov 5, 2019 at 2:55 AM Gerd Hoffmann <kraxel@xxxxxxxxxx> wrote: > Each buffer also has some properties to carry metadata, some fixed (id, size, application), but > also allow free form (name = value, framebuffers would have > width/height/stride/format for example). Sounds a lot like the recently added DMA_BUF_SET_NAME ioctls: https://patchwork.freedesktop.org/patch/310349/ For virtio-wayland + virtio-vdec, the problem is sharing -- not allocation. As the buffer reaches a kernel boundary, it's properties devolve into [fd, size]. Userspace can typically handle sharing metadata. The issue is the guest dma-buf fd doesn't mean anything on the host. One scenario could be: 1) Guest userspace (say, gralloc) allocates using virtio-gpu. When allocating, we call uuidgen() and then pass that via RESOURCE_CREATE hypercall to the host. 2) When exporting the dma-buf, we call DMA_BUF_SET_NAME (the buffer name will be "virtgpu-buffer-${UUID}"). 3) When importing, virtio-{vdec, video} reads the dma-buf name in userspace, and calls fd to handle. The name is sent to the host via a hypercall, giving host virtio-{vdec, video} enough information to identify the buffer. This solution is entirely userspace -- we can probably come up with something in kernel space [generate_random_uuid()] if need be. We only need two universal IDs: {device ID, buffer ID}. > On Wed, Nov 6, 2019 at 2:28 PM Geoffrey McRae <geoff@xxxxxxxxxxxxxxx> wrote: > The entire point of this for our purposes is due to the fact that we can > not allocate the buffer, it's either provided by the GPU driver or > DirectX. If virtio-gpu were to allocate the buffer we might as well > forget > all this and continue using the ivshmem device. We have a similar problem with closed source drivers. As @lfy mentioned, it's possible to map memory directory into virtio-gpu's PCI bar and it's actually a planned feature. Would that work for your use case?
