Re: [virtio-dev] Re: guest / host buffer sharing ...
On Wed, 2019-11-20 at 10:53 +0100, Gerd Hoffmann wrote: > Hi, > > > > > 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 ? > > > > > > The dma-buf api currently can share guest memory sg-lists. > > > > Ok, IIUC buffers can either be shared using the GPU proposed APIs > > (above) or using the dma-buf API to share via userspace ? My > > preference > > would be to use teh more direct GPU APIs sending physical page > > addresses from Guest to device driver. I guess this is your use > > case > > too ? > > I'm not convinced this is useful for audio ... > > I basically see two modes of operation which are useful: > > (1) send audio data via virtqueue. > (2) map host audio buffers into the guest address space. > > The audio driver api (i.e. alsa) typically allows to mmap() the audio > data buffers, so it is the host audio driver which handles the > allocation. Yes, in regular non VM mode, it's the host driver which allocs the buffers. My end goal is to be able to share physical SG pages from host to guests and HW (including DSP firmwares). > Let the audio hardware dma from/to userspace-allocated > buffers is not possible[1], but we would need that to allow qemu (or > other vmms) use guest-allocated buffers. My misunderstanding here on how the various proposals being discussed all pass buffers between guests & host. I'm reading that some are passing buffers via userspace descriptors and this would not be workable for audio. > > cheers, > Gerd > > [1] Disclaimer: It's been a while I looked at alsa more closely, so > there is a chance this might have changed without /me noticing. > Your all good here from audio. Disclaimer: I'm new to virtio. Liam
Re: [virtio-dev] Re: guest / host buffer sharing ...
On Tue, 2019-11-12 at 14:55 -0800, Gurchetan Singh wrote:
> On Tue, Nov 12, 2019 at 5:56 AM Liam Girdwood
> wrote:
> >
> > On Mon, 2019-11-11 at 16:54 -0800, Gurchetan Singh wrote:
> > > On Tue, Nov 5, 2019 at 2:55 AM Gerd Hoffmann
> > > 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).
>
> So you need the HW address space from a guest allocation?
Yes.
> Would your
> allocation hypercalls use something like the virtio_gpu_mem_entry
> (virtio_gpu.h) and the draft virtio_video_mem_entry (draft)?
IIUC, this looks like generic SG buffer allocation ?
>
> struct {
> __le64 addr;
> __le32 length;
> __le32 padding;
> };
>
> /* VIRTIO_GPU_CMD_RESOURCE_ATTACH_BACKING */
> struct virtio_gpu_resource_attach_backing {
> struct virtio_gpu_ctrl_hdr hdr;
> __le32 resource_id;
> __le32 nr_entries;
> *struct struct virtio_gpu_mem_entry */
> };
>
> struct virtio_video_mem_entry {
> __le64 addr;
> __le32 length;
> __u8 padding[4];
> };
>
> struct virtio_video_resource_attach_backing {
> struct virtio_video_ctrl_hdr hdr;
> __le32 resource_id;
> __le32 nr_entries;
> };
>
> >
> > 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 ?
>
> The dma-buf api currently can share guest memory sg-lists.
Ok, IIUC buffers can either be shared using the GPU proposed APIs
(above) or using the dma-buf API to share via userspace ? My preference
would be to use teh more direct GPU APIs sending physical page
addresses from Guest to device driver. I guess this is your use case
too ?
Thanks
Liam
>
> >
> > Liam
> >
> >
> >
> > -
> >
> > To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org
> > For additional commands, e-mail:
> > virtio-dev-h...@lists.oasis-open.org
> >
>
> -
> To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org
> For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
>
Re: [virtio-dev] Re: guest / host buffer sharing ...
On Mon, 2019-11-11 at 16:54 -0800, Gurchetan Singh wrote:
> On Tue, Nov 5, 2019 at 2:55 AM Gerd Hoffmann
> 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
Re: [virtio-dev] Re: guest / host buffer sharing ...
On Mon, 2019-11-11 at 12:04 +0900, David Stevens wrote: > Having a centralized buffer allocator device is one way to deal with > sharing buffers, since it gives a definitive buffer identifier that > can be used by all drivers/devices to refer to the buffer. That being > said, I think the device as proposed is insufficient, as such a > centralized buffer allocator should probably be responsible for > allocating all shared buffers, not just linear guest ram buffers. This would work for audio. I need to be able to :- 1) Allocate buffers on guests that I can pass as SG physical pages to DMA engine (via privileged VM driver) for audio data. Can be any memory as long as it's DMA-able. 2) Export hardware mailbox memory (in a real device PCI BAR) as RO to each guest to give guests low latency information on each audio stream. To support use cases like voice calls, gaming, system notifications and general audio processing. Liam
