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.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_2 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 68E59C17441 for ; Mon, 11 Nov 2019 17:45:06 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 41D4020818 for ; Mon, 11 Nov 2019 17:45:06 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 41D4020818 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:55848 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iUDkN-0007TD-CW for qemu-devel@archiver.kernel.org; Mon, 11 Nov 2019 12:45:05 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:35552) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iUBlJ-0002qo-Ey for qemu-devel@nongnu.org; Mon, 11 Nov 2019 10:37:54 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iUBlI-0005q8-D6 for qemu-devel@nongnu.org; Mon, 11 Nov 2019 10:37:53 -0500 Received: from mga02.intel.com ([134.134.136.20]:62639) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1iUBlI-0004dD-3W for qemu-devel@nongnu.org; Mon, 11 Nov 2019 10:37:52 -0500 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Nov 2019 07:36:45 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.68,293,1569308400"; d="scan'208";a="215709477" Received: from jlahtine-desk.ger.corp.intel.com ([10.252.20.50]) by orsmga002.jf.intel.com with ESMTP; 11 Nov 2019 07:36:39 -0800 Message-ID: Subject: Re: [virtio-dev] Re: guest / host buffer sharing ... From: Liam Girdwood To: David Stevens , Stefan Hajnoczi Date: Mon, 11 Nov 2019 15:36:38 +0000 In-Reply-To: References: <20191105105456.7xbhtistnbp272lj@sirius.home.kraxel.org> <20191106084344.GB189998@stefanha-x1.localdomain> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5-0ubuntu0.18.04.1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 134.134.136.20 X-Mailman-Approved-At: Mon, 11 Nov 2019 12:43:55 -0500 X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: geoff@hostfission.com, virtio-dev@lists.oasis-open.org, Alex Lau , Daniel Vetter , Alexandre Courbot , qemu-devel@nongnu.org, Tomasz Figa , Keiichi Watanabe , Gerd Hoffmann , Hans Verkuil , =?ISO-8859-1?Q?St=E9phane?= Marchesin , Dylan Reid , Gurchetan Singh , Dmitry Morozov , Pawel Osciak , Linux Media Mailing List Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" 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