> > 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). Yep. So the host driver would allocate the pages, in a way that the hw can access them of course. qemu (or another vmm) would mmap() those buffer pages, using the usual sound app interface, which would be alsa on linux. Virtio got support for shared memory recently (it is in the version 1.2 draft), virtio-pci transport uses a pci bar for the shared memory regions. qemu (or other vmms) can use that to map the buffer pages into guest address space. There are plans use shared memory in virtio-gpu too, for pretty much the same reasons. Some kinds of gpu buffers must be allocated by the host gpu driver, to make sure the host hardware can use the buffers as intended. > > 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. Yep, dma-buf based buffer passing doesn't help much for audio. cheers, Gerd
