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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id E2D4FEDEC5C for ; Wed, 13 Sep 2023 14:19:19 +0000 (UTC) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qgQhf-0002p3-0j; Wed, 13 Sep 2023 10:18:51 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qgQhd-0002ol-Q2 for qemu-devel@nongnu.org; Wed, 13 Sep 2023 10:18:50 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qgQha-0007r6-5h for qemu-devel@nongnu.org; Wed, 13 Sep 2023 10:18:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1694614725; 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: in-reply-to:in-reply-to:references:references; bh=4cjOPKJK8kJbNrrfaNwOPldfkz5IYXw7eT/fQo2YKNU=; b=iaDsELhX0S69qLlUDPtDx2u9fU7q8s8f5KI6AX3/Lx4JBHnShqhMgkI9FyunFFqyElmg3j HbJNDSzXBIdmKE23n8CQfO9fY8S3TOxc8vsIguoY7iTiAFaXH6lN0rGI1ZqReTEsBdIrk/ qMtXe/4ze24iJ9OfXVUN+K94i1M1Bfc= Received: from mail-pg1-f198.google.com (mail-pg1-f198.google.com [209.85.215.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-266--r5UAWdSPNWDS__TdP55Yw-1; Wed, 13 Sep 2023 10:18:43 -0400 X-MC-Unique: -r5UAWdSPNWDS__TdP55Yw-1 Received: by mail-pg1-f198.google.com with SMTP id 41be03b00d2f7-56f75e70190so7362199a12.3 for ; Wed, 13 Sep 2023 07:18:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694614719; x=1695219519; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=4cjOPKJK8kJbNrrfaNwOPldfkz5IYXw7eT/fQo2YKNU=; b=j2Z9tuf9yZ03p37MX40aAiB3Ns5X6XyLcHCuCG2Kg7sHBcCj3pEvYdMarVeh22Y5+9 wmjwJkbTcAeop+Sk0etdPjrAKErvsOcEjdWbR8w5E5Hr4f/zl63WIkcmC1smYiyr6H+F h/3yQdy1cckGQ11Ll5TtZ4fpu9nxIp48YTwRXTLGguhAeNn/+tuNhO0B3kRXKkQUaspI YggHWn1vfv3VHL9YfzK9hKiMlWGk/dtef6uZhQLu3ANzJZyEuYd2KfR+seWC48wc2cJJ PN/SI5ziZ4ctIJDvBAJnPDWm7ZiFvLqBrJzLyj3D9B99PTlUG7VUuHy0pC6a8ISvN0ga rINA== X-Gm-Message-State: AOJu0Yzh7BZW/ltLlc1IF1qUXdFz+SV7MPICWGb0ABR3GeNI6ESQ4CEW pMP/Zc3+fyBdGr22/XadmRq5pRdYg7XS6vt/BArdDpkHKFwfaskApXPCFv2ElZ7g8wwpcHdvM9X AHxpYhebarEeTu8VWnly48oNdC4IRgfU= X-Received: by 2002:a17:90b:38d2:b0:26d:43f9:11dd with SMTP id nn18-20020a17090b38d200b0026d43f911ddmr2391932pjb.0.1694614719032; Wed, 13 Sep 2023 07:18:39 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHmx/ocnxpiY4B9P8H02WpotJCJrvPg1BigAUA4M9k0RHWOtkiiN2a2ztOf5TEYtrqChYplvibI+pVgKM2Zwds= X-Received: by 2002:a17:90b:38d2:b0:26d:43f9:11dd with SMTP id nn18-20020a17090b38d200b0026d43f911ddmr2391901pjb.0.1694614718671; Wed, 13 Sep 2023 07:18:38 -0700 (PDT) MIME-Version: 1.0 References: <20230831093252.2461282-1-ray.huang@amd.com> <20230831093252.2461282-11-ray.huang@amd.com> <58a4e81f-b0ce-49db-8a6a-f6b5bdc3d2d6@daynix.com> <11c227e8-a464-41ce-a435-82c570746388@daynix.com> <5e88f5d5-5aa2-4052-b250-69c2a443344f@daynix.com> <3918c96c-f106-494d-8e97-6d86cef8df27@daynix.com> In-Reply-To: <3918c96c-f106-494d-8e97-6d86cef8df27@daynix.com> From: Albert Esteve Date: Wed, 13 Sep 2023 16:18:27 +0200 Message-ID: Subject: Re: [QEMU PATCH v4 10/13] virtio-gpu: Resource UUID To: Akihiko Odaki Cc: Huang Rui , Gerd Hoffmann , "Michael S . Tsirkin" , Stefano Stabellini , Anthony PERARD , Antonio Caggiano , "Dr . David Alan Gilbert" , Robert Beckett , Dmitry Osipenko , =?UTF-8?B?QWxleCBCZW5uw6ll?= , "qemu-devel@nongnu.org" , "xen-devel@lists.xenproject.org" , Gurchetan Singh , "ernunes@redhat.com" , =?UTF-8?Q?Philippe_Mathieu=2DDaud=C3=A9?= , Alyssa Ross , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , "Deucher, Alexander" , "Koenig, Christian" , "Ragiadakou, Xenia" , "Pelloux-Prayer, Pierre-Eric" , "Huang, Honglei1" , "Zhang, Julia" , "Chen, Jiqian" Content-Type: multipart/alternative; boundary="00000000000056833706053e3c54" Received-SPF: pass client-ip=170.10.133.124; envelope-from=aesteve@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org --00000000000056833706053e3c54 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Sep 13, 2023 at 3:43=E2=80=AFPM Akihiko Odaki wrote: > On 2023/09/13 21:58, Albert Esteve wrote: > > > > > > On Wed, Sep 13, 2023 at 2:22=E2=80=AFPM Akihiko Odaki > > wrote: > > > > On 2023/09/13 20:34, Albert Esteve wrote: > > > > > > > > > On Wed, Sep 13, 2023 at 12:34=E2=80=AFPM Akihiko Odaki > > > > > > >> wrote: > > > > > > On 2023/09/13 16:55, Albert Esteve wrote: > > > > Hi Antonio, > > > > > > > > If I'm not mistaken, this patch is related with: > > > > > > > > > https://lists.gnu.org/archive/html/qemu-devel/2023-09/msg01853.html > > > > > > > > < > https://lists.gnu.org/archive/html/qemu-devel/2023-09/msg01853.html < > https://lists.gnu.org/archive/html/qemu-devel/2023-09/msg01853.html>> > > > > > > > > > < > https://lists.gnu.org/archive/html/qemu-devel/2023-09/msg01853.html < > https://lists.gnu.org/archive/html/qemu-devel/2023-09/msg01853.html> > > > > > < > https://lists.gnu.org/archive/html/qemu-devel/2023-09/msg01853.html < > https://lists.gnu.org/archive/html/qemu-devel/2023-09/msg01853.html>>> > > > > IMHO, ideally, virtio-gpu and vhost-user-gpu both, would > > use the > > > > infrastructure from the patch I linked to store the > > > > virtio objects, so that they can be later shared with > > other devices. > > > > > > I don't think such sharing is possible because the resources > are > > > identified by IDs that are local to the device. That also > > complicates > > > migration. > > > > > > Regards, > > > Akihiko Odaki > > > > > > Hi Akihiko, > > > > > > As far as I understand, the feature to export dma-bufs from the > > > virtgpu was introduced as part of the virtio cross-device sharin= g > > > proposal [1]. Thus, it shall be posible. When virtgpu ASSING_UUI= D, > > > it exports and identifies the dmabuf resource, so that when the > > dmabuf gets > > > shared inside the guest (e.g., with virtio-video), we can use th= e > > assigned > > > UUID to find the dmabuf in the host (using the patch that I > > linked above), > > > and import it. > > > > > > [1] - https://lwn.net/Articles/828988/ > > > > > > > > The problem is that virtio-gpu can have other kind of resources lik= e > > pixman and OpenGL textures and manage them and DMA-BUFs with unifie= d > > resource ID. > > > > > > I see. > > > > > > So you cannot change: > > g_hash_table_insert(g->resource_uuids, > > GUINT_TO_POINTER(assign.resource_id), uuid); > > by: > > virtio_add_dmabuf(uuid, assign.resource_id); > > > > assign.resource_id is not DMA-BUF file descriptor, and the underlyi= ng > > resource my not be DMA-BUF at first place. > > > > > > I didn't really look into the patch in-depth, so the code was intended > > to give an idea of how the implementation would look like with > > the cross-device patch API. Indeed, it is not the resource_id, > > (I just took a brief look at the virtio specificacion 1.2), but the > > underlying > > resource what we want to use here. > > > > > > Also, since this lives in the common code that is not used only by > > virtio-gpu-gl but also virtio-gpu, which supports migration, we als= o > > need to take care of that. It is not a problem for DMA-BUF as > > DMA-BUF is > > not migratable anyway, but the situation is different in this case. > > > > Implementing cross-device sharing is certainly a possibility, but > that > > requires more than dealing with DMA-BUFs. > > > > > > So, if I understood correctly, dmabufs are just a subset of the resourc= es > > that the gpu manages, or can assign UUIDs to. I am not sure why > > the virt gpu driver would want to send a ASSIGN_UUID for anything > > that is not a dmabuf (are we sure it does?), but I am not super > familiarized > > with virtgpu to begin with. > > In my understanding, an resource will be first created as OpenGL or > Vulkan textures and then exported as a DMA-BUF file descriptor. For > these resource types exporting/importing code is mandatory. > > For pixman buffers (i.e., non-virgl device), I don't see a compelling > reason to have cross-device sharing. It is possible to omit resource > UUID feature from non-virgl device to avoid implementing complicated > migration. > I see, thanks for the clarification. I would assume you could avoid the UUID feature for those resources, but I will need to check the driver implementation. It is worth checking though, if that would simplify the implementation. > > > But I see that internally, the GPU specs relate a UUID with a > resource_id, > > so we still need both tables: > > - one to relate UUID with resource_id to be able to locate the > > underlying resource > > - the table that holds the dmabuf with the UUID for cross-device sharin= g > > > > With that in mind, sounds to me that the support for cross-device > > sharing could > > be added on top of this patch, once > > https://lists.gnu.org/archive/html/qemu-devel/2023-09/msg01850.html > > > > lands. > > That is possible, but I think it's better to implement cross-device > sharing at the same time introducing virtio-dmabuf. > > The current design of virtio-dmabuf looks somewhat inconsistent; it's > named "dmabuf", but internally the UUIDs are stored into something named > "resource_uuids" and it has SharedObjectType so it's more like a generic > resource sharing mechanism. If you actually have an implementation of > cross-device sharing using virtio-dmabuf, it will be clear what kind of > feature is truly necessary. > > Yeah, the file was named as virtio-dmabuf following the kernel implementation. Also, because for the moment it only aims to share dmabufs. However, virtio specs leave the virtio object defintion vague [1] (I guess purposely). It is up to the specific devices to define what an object means for them. So the implementation tries to follow that, and leave the contents of the table generic. The table can hold any kind of object, and the API exposes type-specific functions (for dmabufs, or others). [1] - https://docs.oasis-open.org/virtio/virtio/v1.2/csd01/virtio-v1.2-csd01.html= #x1-10500011 > Regards, > Akihiko Odaki > > --00000000000056833706053e3c54 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Sep 13, 2023 at 3:43= =E2=80=AFPM Akihiko Odaki <a= kihiko.odaki@daynix.com> wrote:
On 2023/09/13 21:58, Albert Esteve wrote:
>
>
> On Wed, Sep 13, 2023 at 2:22=E2=80=AFPM Akihiko Odaki <akihiko.odaki@daynix.com<= /a>
> <mailto:akihiko.odaki@daynix.com>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0On 2023/09/13 20:34, Albert Esteve wrote:
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > On Wed, Sep 13, 2023 at 12:34=E2=80=AFPM Akih= iko Odaki
>=C2=A0 =C2=A0 =C2=A0<akihiko.odaki@daynix.com <mailto:akihiko.odaki@daynix.com><= br> >=C2=A0 =C2=A0 =C2=A0 > <mailto:akihiko.odaki@daynix.com
>=C2=A0 =C2=A0 =C2=A0<mailto:akihiko.odaki@daynix.com>>> wrote:
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0On 2023/09/13 16:55, Alber= t Esteve wrote:
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > Hi Antonio,
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > If I'm not mista= ken, this patch is related with:
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0https://l= ists.gnu.org/archive/html/qemu-devel/2023-09/msg01853.html
>=C2=A0 =C2=A0 =C2=A0<https= ://lists.gnu.org/archive/html/qemu-devel/2023-09/msg01853.html>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<https://lists.gnu.org/archive/html/qemu-devel/2023-09/msg01853.html &= lt;https://lists.gnu.org/archive/= html/qemu-devel/2023-09/msg01853.html>>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<https://lists.gnu.org/archive/html/qemu-devel/2023-09/msg01853.html &= lt;https://lists.gnu.org/archive/= html/qemu-devel/2023-09/msg01853.html>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<https://lists.gnu.org/archive/html/qemu-devel/2023-09/msg01853.html &= lt;https://lists.gnu.org/archive/= html/qemu-devel/2023-09/msg01853.html>>>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > IMHO, ideally, virti= o-gpu and vhost-user-gpu both, would
>=C2=A0 =C2=A0 =C2=A0use the
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > infrastructure from = the patch I linked to store the
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > virtio objects, so t= hat they can be later shared with
>=C2=A0 =C2=A0 =C2=A0other devices.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0I don't think such sha= ring is possible because the resources are
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0identified by IDs that are= local to the device. That also
>=C2=A0 =C2=A0 =C2=A0complicates
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0migration.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Regards,
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Akihiko Odaki
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > Hi Akihiko,
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > As far as I understand, the feature to export= dma-bufs=C2=A0from the
>=C2=A0 =C2=A0 =C2=A0 > virtgpu was introduced as part of the virtio = cross-device sharing
>=C2=A0 =C2=A0 =C2=A0 > proposal [1]. Thus, it shall be posible. When= virtgpu=C2=A0ASSING_UUID,
>=C2=A0 =C2=A0 =C2=A0 > it exports and identifies the dmabuf resource= , so that when the
>=C2=A0 =C2=A0 =C2=A0dmabuf gets
>=C2=A0 =C2=A0 =C2=A0 > shared inside the guest (e.g., with virtio-vi= deo), we can use the
>=C2=A0 =C2=A0 =C2=A0assigned
>=C2=A0 =C2=A0 =C2=A0 > UUID to find the dmabuf in the host (using th= e patch that I
>=C2=A0 =C2=A0 =C2=A0linked above),
>=C2=A0 =C2=A0 =C2=A0 > and import it.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > [1] - https://lwn.net/Articles/828988/=
>=C2=A0 =C2=A0 =C2=A0<https://lwn.net/Articles/828988/>= <https://lwn.net/Articles/828988/
>=C2=A0 =C2=A0 =C2=A0<https://lwn.net/Articles/828988/>= >
>
>=C2=A0 =C2=A0 =C2=A0The problem is that virtio-gpu can have other kind = of resources like
>=C2=A0 =C2=A0 =C2=A0pixman and OpenGL textures and manage them and DMA-= BUFs with unified
>=C2=A0 =C2=A0 =C2=A0resource ID.
>
>
> I see.
>
>
>=C2=A0 =C2=A0 =C2=A0So you cannot change:
>=C2=A0 =C2=A0 =C2=A0g_hash_table_insert(g->resource_uuids,
>=C2=A0 =C2=A0 =C2=A0GUINT_TO_POINTER(assign.resource_id), uuid);
>=C2=A0 =C2=A0 =C2=A0by:
>=C2=A0 =C2=A0 =C2=A0virtio_add_dmabuf(uuid, assign.resource_id);
>
>=C2=A0 =C2=A0 =C2=A0assign.resource_id is not DMA-BUF file descriptor, = and the underlying
>=C2=A0 =C2=A0 =C2=A0resource my not be DMA-BUF at first place.
>
>
> I didn't really look into the patch in-depth, so the=C2=A0code was= intended
> to give an idea of how the implementation would look like with
> the cross-device patch API. Indeed, it is not the resource_id,
> (I just took a brief look at the virtio specificacion=C2=A01.2), but t= he
> underlying
> resource what we want to use here.
>
>
>=C2=A0 =C2=A0 =C2=A0Also, since this lives in the common code that is n= ot used only by
>=C2=A0 =C2=A0 =C2=A0virtio-gpu-gl but also virtio-gpu, which supports m= igration, we also
>=C2=A0 =C2=A0 =C2=A0need to take care of that. It is not a problem for = DMA-BUF as
>=C2=A0 =C2=A0 =C2=A0DMA-BUF is
>=C2=A0 =C2=A0 =C2=A0not migratable anyway, but the situation is differe= nt in this case.
>
>=C2=A0 =C2=A0 =C2=A0Implementing cross-device sharing is certainly a po= ssibility, but that
>=C2=A0 =C2=A0 =C2=A0requires more than dealing with DMA-BUFs.
>
>
> So, if I understood correctly, dmabufs=C2=A0are just a subset of the r= esources
> that the gpu manages, or can assign UUIDs to. I am not sure why
> the virt gpu driver would want to send a ASSIGN_UUID for anything
> that is not a dmabuf (are we sure it does?), but I am not super famili= arized
> with virtgpu=C2=A0to begin with.

In my understanding, an resource will be first created as OpenGL or
Vulkan textures and then exported as a DMA-BUF file descriptor. For
these resource types exporting/importing code is mandatory.

For pixman buffers (i.e., non-virgl device), I don't see a compelling <= br> reason to have cross-device sharing. It is possible to omit resource
UUID feature from non-virgl device to avoid implementing complicated
migration.

I see, thanks for the clarif= ication.
I would assume you could avoid the UUID feature for thos= e resources, but
I will need to check the driver implementation. = It is worth checking though, if
that would simplify the implement= ation.
=C2=A0

> But I see that internally, the GPU specs relate a UUID with a resource= _id,
> so we still need both tables:
> - one to relate UUID with resource_id to be able to locate the
> underlying resource
> - the table that holds the dmabuf with the UUID for cross-device shari= ng
>
> With that in mind, sounds to me that the support for cross-device
> sharing could
> be added on top of this patch, once
> https://lists.gnu.org/archiv= e/html/qemu-devel/2023-09/msg01850.html
> <https://lists.gnu.org/ar= chive/html/qemu-devel/2023-09/msg01850.html>
> lands.

That is possible, but I think it's better to implement cross-device sharing at the same time introducing virtio-dmabuf.

The current design of virtio-dmabuf looks somewhat inconsistent; it's <= br> named "dmabuf", but internally the UUIDs are stored into somethin= g named
"resource_uuids" and it has SharedObjectType so it's more lik= e a generic
resource sharing mechanism. If you actually have an implementation of
cross-device sharing using virtio-dmabuf, it will be clear what kind of feature is truly necessary.


Yeah, the file was named as virtio-dma= buf following the kernel
implementation. Also, because for the mo= ment it only aims to share
dmabufs. However, virtio specs leave t= he virtio object defintion=C2=A0vague [1]
(I guess purposely). It= is up to the specific devices to define what an object
means for= them. So the implementation tries to follow that, and
leave the = contents of the table generic. The table can hold any kind of object,
=
and the API exposes type-specific functions (for dmabufs,=C2=A0or othe= rs).

=C2=A0
Regards,
Akihiko Odaki

--00000000000056833706053e3c54--