qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [virtio-dev] Re: guest / host buffer sharing ...


From: Gerd Hoffmann
Subject: Re: [virtio-dev] Re: guest / host buffer sharing ...
Date: Wed, 27 Nov 2019 08:58:03 +0100
User-agent: NeoMutt/20180716

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]