From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.4 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0C03EC432C0 for ; Wed, 27 Nov 2019 07:58:16 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id D13D4207DD for ; Wed, 27 Nov 2019 07:58:15 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="BpsFZlzE" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726267AbfK0H6P (ORCPT ); Wed, 27 Nov 2019 02:58:15 -0500 Received: from us-smtp-delivery-1.mimecast.com ([207.211.31.120]:41231 "EHLO us-smtp-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726240AbfK0H6P (ORCPT ); Wed, 27 Nov 2019 02:58:15 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1574841494; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=WdcPJ0Dwg19OMCk56up1PNjeYkMKncWwty2/pCthIu0=; b=BpsFZlzED/vUSdFucMqV/NuVEFJQTeZsVyGuQyHEmP91i2PYfBhQhRHjDEEkMB+7Oieu9k I2EPvLvLCnBYTN6HiarcNUwOOA8klqRD4bxaBqx1SfYlx/QZZ6T4SUg4zcq0ewX4+PKIyM t0+t5gi1PGLO1njNB6JdMhlN/ovbSzM= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-251-HLqzj73PNTm1dOZITTNkCQ-1; Wed, 27 Nov 2019 02:58:08 -0500 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 57B34107ACE4; Wed, 27 Nov 2019 07:58:05 +0000 (UTC) Received: from sirius.home.kraxel.org (ovpn-116-67.ams2.redhat.com [10.36.116.67]) by smtp.corp.redhat.com (Postfix) with ESMTP id 6C8F560BE2; Wed, 27 Nov 2019 07:58:04 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id 5BCF416E18; Wed, 27 Nov 2019 08:58:03 +0100 (CET) Date: Wed, 27 Nov 2019 08:58:03 +0100 From: Gerd Hoffmann To: Liam Girdwood Cc: Gurchetan Singh , David Stevens , Stefan Hajnoczi , Keiichi Watanabe , geoff@hostfission.com, virtio-dev@lists.oasis-open.org, Alex Lau , Alexandre Courbot , qemu-devel@nongnu.org, Tomasz Figa , Hans Verkuil , Daniel Vetter , =?utf-8?B?U3TDqXBoYW5l?= Marchesin , Dylan Reid , Dmitry Morozov , Pawel Osciak , Linux Media Mailing List Subject: Re: [virtio-dev] Re: guest / host buffer sharing ... Message-ID: <20191127075803.e5i72nzayi4t6aw2@sirius.home.kraxel.org> References: <20191105105456.7xbhtistnbp272lj@sirius.home.kraxel.org> <20191106084344.GB189998@stefanha-x1.localdomain> <4a5dd822e86757f004d04af62fb7dd35ba75392d.camel@linux.intel.com> <20191120095349.oobeosin3lujgcja@sirius.home.kraxel.org> <296b7d844a283996a16769ecf3daade5198ae307.camel@linux.intel.com> MIME-Version: 1.0 In-Reply-To: <296b7d844a283996a16769ecf3daade5198ae307.camel@linux.intel.com> User-Agent: NeoMutt/20180716 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-MC-Unique: HLqzj73PNTm1dOZITTNkCQ-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Sender: linux-media-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org > > I'm not convinced this is useful for audio ... > >=20 > > I basically see two modes of operation which are useful: > >=20 > > (1) send audio data via virtqueue. > > (2) map host audio buffers into the guest address space. > >=20 > > 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.=20 >=20 > Yes, in regular non VM mode, it's the host driver which allocs the > buffers. >=20 > My end goal is to be able to share physical SG pages from host to > guests and HW (including DSP firmwares).=20 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. >=20 > 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