On Mon, 2019-11-11 at 16:54 -0800, Gurchetan Singh wrote: > 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. > Audio also needs to share buffers with firmware running on DSPs. > 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}. > I need something where I can take a guest buffer and then convert it to physical scatter gather page list. I can then either pass the SG page list to the DSP firmware (for DMAC IP programming) or have the host driver program the DMAC directly using the page list (who programs DMAC depends on DSP architecture). DSP FW has no access to userspace so we would need some additional API on top of DMA_BUF_SET_NAME etc to get physical hardware pages ? Liam
