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.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,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 BE2FDC17440 for ; Tue, 12 Nov 2019 13:56:51 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 9FBA42196E for ; Tue, 12 Nov 2019 13:56:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727298AbfKLN4v (ORCPT ); Tue, 12 Nov 2019 08:56:51 -0500 Received: from mga09.intel.com ([134.134.136.24]:32849 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727201AbfKLN4u (ORCPT ); Tue, 12 Nov 2019 08:56:50 -0500 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Nov 2019 05:56:50 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.68,296,1569308400"; d="scan'208";a="194319994" Received: from hbenchen-mobl1.ger.corp.intel.com ([10.251.95.209]) by orsmga007.jf.intel.com with ESMTP; 12 Nov 2019 05:56:45 -0800 Message-ID: <4a5dd822e86757f004d04af62fb7dd35ba75392d.camel@linux.intel.com> Subject: Re: [virtio-dev] Re: guest / host buffer sharing ... From: Liam Girdwood To: Gurchetan Singh Cc: David Stevens , Stefan Hajnoczi , Gerd Hoffmann , 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 , =?ISO-8859-1?Q?St=E9phane?= Marchesin , Dylan Reid , Dmitry Morozov , Pawel Osciak , Linux Media Mailing List Date: Tue, 12 Nov 2019 13:56:43 +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 Sender: linux-media-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org 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 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.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,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 E3A0FC43331 for ; Tue, 12 Nov 2019 13:57:34 +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 B8B2621783 for ; Tue, 12 Nov 2019 13:57:34 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B8B2621783 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]:35314 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iUWfl-0007kU-UA for qemu-devel@archiver.kernel.org; Tue, 12 Nov 2019 08:57:33 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:53238) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iUWf8-0007JH-3p for qemu-devel@nongnu.org; Tue, 12 Nov 2019 08:56:55 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iUWf6-0002xb-Tu for qemu-devel@nongnu.org; Tue, 12 Nov 2019 08:56:53 -0500 Received: from mga03.intel.com ([134.134.136.65]:56277) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1iUWf6-0002wl-Jb for qemu-devel@nongnu.org; Tue, 12 Nov 2019 08:56:52 -0500 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Nov 2019 05:56:50 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.68,296,1569308400"; d="scan'208";a="194319994" Received: from hbenchen-mobl1.ger.corp.intel.com ([10.251.95.209]) by orsmga007.jf.intel.com with ESMTP; 12 Nov 2019 05:56:45 -0800 Message-ID: <4a5dd822e86757f004d04af62fb7dd35ba75392d.camel@linux.intel.com> Subject: Re: [virtio-dev] Re: guest / host buffer sharing ... From: Liam Girdwood To: Gurchetan Singh Date: Tue, 12 Nov 2019 13:56:43 +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.65 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 , Stefan Hajnoczi , qemu-devel@nongnu.org, Tomasz Figa , Keiichi Watanabe , David Stevens , Hans Verkuil , =?ISO-8859-1?Q?St=E9phane?= Marchesin , Dylan Reid , Linux Media Mailing List , Dmitry Morozov , Pawel Osciak , Gerd Hoffmann Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: virtio-dev-return-6322-cohuck=redhat.com@lists.oasis-open.org Sender: List-Post: List-Help: List-Unsubscribe: List-Subscribe: Received: from lists.oasis-open.org (oasis-open.org [10.110.1.242]) by lists.oasis-open.org (Postfix) with ESMTP id DEA4C985E61 for ; Tue, 12 Nov 2019 13:56:52 +0000 (UTC) Message-ID: <4a5dd822e86757f004d04af62fb7dd35ba75392d.camel@linux.intel.com> From: Liam Girdwood Date: Tue, 12 Nov 2019 13:56:43 +0000 In-Reply-To: References: <20191105105456.7xbhtistnbp272lj@sirius.home.kraxel.org> <20191106084344.GB189998@stefanha-x1.localdomain> Mime-Version: 1.0 Subject: Re: [virtio-dev] Re: guest / host buffer sharing ... Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable To: Gurchetan Singh Cc: David Stevens , Stefan Hajnoczi , Gerd Hoffmann , 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 , =?ISO-8859-1?Q?St=E9phane?= Marchesin , Dylan Reid , Dmitry Morozov , Pawel Osciak , Linux Media Mailing List List-ID: 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 =3D value, framebuffers would have > > width/height/stride/format for example). >=20 > Sounds a lot like the recently added DMA_BUF_SET_NAME ioctls: >=20 > https://patchwork.freedesktop.org/patch/310349/ >=20 > For virtio-wayland + virtio-vdec, the problem is sharing -- not > allocation. >=20 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. >=20 > One scenario could be: >=20 > 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. >=20 > 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}. >=20 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 --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org