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 588C2EDE994 for ; Thu, 14 Sep 2023 08:30:46 +0000 (UTC) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qghjp-0006RB-4W; Thu, 14 Sep 2023 04:30:13 -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 1qghjo-0006QX-5J for qemu-devel@nongnu.org; Thu, 14 Sep 2023 04:30:12 -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 1qghjl-00038W-2h for qemu-devel@nongnu.org; Thu, 14 Sep 2023 04:30:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1694680206; 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=yA6YEmooBezgU/7PUR3h+x7ndZimwJxchJ/tlSKweSU=; b=C7W9jFYR5xHKaVRzhDyZlWHWag1Aij2sRDHTdJpNSYnWBDy4bPcMXj6RoRDhHAyFz3x2MA dycezXP7/21naPTRSqiRuyM7Gn+h2jxfX6QQhrEWkLVf62p5eJPtd0IMlE+Ui3Nh94rXMp 5S9IGy1ejbz28D4Qae2Ne1tXZDW0nBg= Received: from mail-pj1-f69.google.com (mail-pj1-f69.google.com [209.85.216.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-36-mJ8R9zTdNVKGarRbLZjAgg-1; Thu, 14 Sep 2023 04:30:04 -0400 X-MC-Unique: mJ8R9zTdNVKGarRbLZjAgg-1 Received: by mail-pj1-f69.google.com with SMTP id 98e67ed59e1d1-27463dbb521so523694a91.2 for ; Thu, 14 Sep 2023 01:30:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694680203; x=1695285003; 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=yA6YEmooBezgU/7PUR3h+x7ndZimwJxchJ/tlSKweSU=; b=hGlc1hPEHPfPTp8vklhtnCfQ7FoshIuElgoPb0U0xw6XcGuUuAt1ju67BHGCJzEZYX qUnfRPnbZKCzcBdYBWtnIfQgVXvJg2uUz01cRgISklMetaQ+vZexWuCGCL7/uLJz5pB0 7BJa1w1kYDf7JPSrx+08kNg47DlEdW49Tk1jiuy3LzJALZVjNB+brWYvpIaWoSaq/L2E vSqi50I415GBRL2XfbweaiUDHNLaV0UQC8OOReUcvxtiENylEN+NewG6eVN6Rc8PPT0t PYEtQ++8rBwnTO9VFgPneDEgfFDFOGm8fFhB2V5OMNwS9wKAaXgc+1CB4Z6WLhwr/qwa WATA== X-Gm-Message-State: AOJu0YxirR6lV2dHFOFMEKW4MnTfbWoYD/vcC/PfzoYawnOqpIoDggYr fcV+vkO72HQ4qnVbcPmLi2PNwKhXEitSVEIlp8OEwS0GLzQpIhzg8tXaKFyZA5iHKbGBUhmyCxe 4TL3OMoZLWwdrlj0BZcOO4dMzvlpLyrE= X-Received: by 2002:a17:90a:8c88:b0:269:18f5:683e with SMTP id b8-20020a17090a8c8800b0026918f5683emr4549205pjo.3.1694680203472; Thu, 14 Sep 2023 01:30:03 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHvpnIrI0fs8uswe/o8Tr9VmbnQC1HIMGfwSGp6+i8vBzb9EeSU1mTm5ednofrRjwOe2msFRh39ayPz1qPNx1c= X-Received: by 2002:a17:90a:8c88:b0:269:18f5:683e with SMTP id b8-20020a17090a8c8800b0026918f5683emr4549172pjo.3.1694680203144; Thu, 14 Sep 2023 01:30:03 -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> <0adaf816-e050-43c3-8284-fc41627543ef@daynix.com> In-Reply-To: <0adaf816-e050-43c3-8284-fc41627543ef@daynix.com> From: Albert Esteve Date: Thu, 14 Sep 2023 10:29:51 +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="00000000000084498506054d7be3" 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 --00000000000084498506054d7be3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Sep 14, 2023 at 9:17=E2=80=AFAM Akihiko Odaki wrote: > On 2023/09/13 23:18, Albert Esteve wrote: > > > > > > 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>>> > > > > > > > > > > > > > > < > 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 < > 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 th= e > > > > > 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 > > sharing > > > > proposal [1]. Thus, it shall be posible. When > > virtgpu ASSING_UUID, > > > > 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 the > > > 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 like > > > pixman and OpenGL textures and manage them and DMA-BUFs with > > unified > > > 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 > > underlying > > > 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 also > > > need to take care of that. It is not a problem for DMA-BUF a= s > > > DMA-BUF is > > > not migratable anyway, but the situation is different in thi= s > > 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 > > resources > > > 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 anythin= g > > > 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 compelli= ng > > reason to have cross-device sharing. It is possible to omit resourc= e > > UUID feature from non-virgl device to avoid implementing complicate= d > > migration. > > > > > > I see, thanks for the clarification. > > I would assume you could avoid the UUID feature for those resources, bu= t > > 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 > > sharing > > > > > > With that in mind, sounds to me that the support for cross-devic= e > > > 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 kin= d > 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). > In the guest kernel, the name "virtio_dma_buf" represents the interface > between the *guest* kernel and *guest* user-space. It makes sense since > the cross-device resource sharing is managed by the userspace and > DMA-BUF is the only interface between them for this purpose. > > The situation is different for QEMU; QEMU interacts with backends using > backend-specific interfaces (OpenGL/pixman) and virgl is capable to > export textures as DMA-BUF. DMA-BUF is not universal in this sense. As > such, we cannot just borrow the kernel-side naming but invent one. > > It is not a gpu-specific feature. It is a generic cross-device sharing mechanism for virtio objects. In this case, virtio objects happen to be dmabufs in this first iteration. Hence, the name. virtio-gpu (and vhost-user-gpu) will use this feature only with virgl, that is fine, and transversal to the object-sharing mechanism. It allows to share dmabufs in the host following how they are shared in the guest. The virtgpu driver may call ASSIGN_UUID for other types of resources (not sure, but could be), but they will never be shared with other virtio devices. So they are not too relevant. Also, the shared objects table could potentially be accessed from any virtio device, not only virtio-gpu or virtio-video. What I am trying to say, is that the name focuses solely in its current usage, i.e., sharing dmabufs between virtio-gpu (as exporter), and virtio-video (as importer). If it grows to something more, imo it can be renamed later. Regards, Albert --00000000000084498506054d7be3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Sep 14, 2023 at 9:17= =E2=80=AFAM Akihiko Odaki <a= kihiko.odaki@daynix.com> wrote:
On 2023/09/13 23:18, Albert Esteve wrote:
>
>
> On Wed, Sep 13, 2023 at 3:43=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 21:58, 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 2:22=E2=80=AFPM Akihi= ko 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 20:34, Alber= t Esteve wrote:
>=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 >=C2=A0 =C2=A0 =C2=A0 > On Wed, Sep 13, 2023= at 12:34=E2=80=AFPM Akihiko Odaki
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0<akihiko.odaki@daynix.com <ma= ilto:akihiko.= odaki@daynix.com>
>=C2=A0 =C2=A0 =C2=A0<mailto:akihiko.odaki@daynix.com <mailto:akihiko.odaki@daynix.com>>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > <mailto:akihiko.odaki@daynix= .com
>=C2=A0 =C2=A0 =C2=A0<mailto:akihiko.odaki@daynix.com>
>=C2=A0 =C2=A0 =C2=A0 >=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=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0O= n 2023/09/13 16:55, Albert Esteve wrote:
>=C2=A0 =C2=A0 =C2=A0 >=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 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = > If I'm not mistaken, 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=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 =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> <https://lists.gnu.org/archive/html/qemu-devel/2023-09/msg0= 1853.html <https://lists.g= nu.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 >
>=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> <https://lists.gnu.org/archive/html/qemu-devel/2023-09/msg0= 1853.html <https://lists.g= nu.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 =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> <https://lists.gnu.org/archive/html/qemu-devel/2023-09/msg0= 1853.html <https://lists.g= nu.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 = > IMHO, ideally, virtio-gpu and vhost-user-gpu both,
>=C2=A0 =C2=A0 =C2=A0would
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0use the
>=C2=A0 =C2=A0 =C2=A0 >=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 >=C2=A0 =C2=A0 =C2=A0 = > virtio objects, so that they can be later shared with
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0other devices.
>=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=A0I= don't think such sharing is possible because the
>=C2=A0 =C2=A0 =C2=A0resources are
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0i= dentified by IDs that are local to the device. That also
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0complicates
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0m= igration.
>=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=A0R= egards,
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0A= kihiko Odaki
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=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 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > As far as I understa= nd, the feature to export
>=C2=A0 =C2=A0 =C2=A0dma-bufs=C2=A0from the
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > virtgpu was introduc= ed as part of the virtio cross-device
>=C2=A0 =C2=A0 =C2=A0sharing
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > proposal [1]. Thus, = it shall be posible. When
>=C2=A0 =C2=A0 =C2=A0virtgpu=C2=A0ASSING_UUID,
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > it exports and ident= ifies the dmabuf resource, so that
>=C2=A0 =C2=A0 =C2=A0when the
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0dmabuf gets
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > shared inside the gu= est (e.g., with virtio-video), we can
>=C2=A0 =C2=A0 =C2=A0use the
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0assigned
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > UUID to find the dma= buf in the host (using the patch that I
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0linked above),
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > and import it.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=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/>=
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0<https://lwn.net= /Articles/828988/
>=C2=A0 =C2=A0 =C2=A0<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 >=C2=A0 =C2=A0 =C2=A0<https://lwn.net= /Articles/828988/
>=C2=A0 =C2=A0 =C2=A0<https://lwn.net/Articles/828988/>= >>
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0The problem is that virtio= -gpu can have other kind of
>=C2=A0 =C2=A0 =C2=A0resources like
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0pixman and OpenGL textures= and manage them and DMA-BUFs with
>=C2=A0 =C2=A0 =C2=A0unified
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0resource ID.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > I see.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0So you cannot change:
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0g_hash_table_insert(g->= resource_uuids,
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0GUINT_TO_POINTER(assign.re= source_id), uuid);
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0by:
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0virtio_add_dmabuf(uuid, as= sign.resource_id);
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0assign.resource_id is not = DMA-BUF file descriptor, and the
>=C2=A0 =C2=A0 =C2=A0underlying
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0resource my not be DMA-BUF= at first place.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > I didn't really look into the patch in-de= pth, so the=C2=A0code was
>=C2=A0 =C2=A0 =C2=A0intended
>=C2=A0 =C2=A0 =C2=A0 > to give an idea of how the implementation wou= ld look like with
>=C2=A0 =C2=A0 =C2=A0 > the cross-device patch API. Indeed, it is not= the resource_id,
>=C2=A0 =C2=A0 =C2=A0 > (I just took a brief look at the virtio speci= ficacion=C2=A01.2), but the
>=C2=A0 =C2=A0 =C2=A0 > underlying
>=C2=A0 =C2=A0 =C2=A0 > resource what we want to use here.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Also, since this lives in = the common code that is not used
>=C2=A0 =C2=A0 =C2=A0only by
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0virtio-gpu-gl but also vir= tio-gpu, which supports migration,
>=C2=A0 =C2=A0 =C2=A0we also
>=C2=A0 =C2=A0 =C2=A0 >=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=A0 >=C2=A0 =C2=A0 =C2=A0DMA-BUF is
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0not migratable anyway, but= the situation is different in this
>=C2=A0 =C2=A0 =C2=A0case.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Implementing cross-device = sharing is certainly a possibility,
>=C2=A0 =C2=A0 =C2=A0but that
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0requires more than dealing= with DMA-BUFs.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > So, if I understood correctly, dmabufs=C2=A0a= re just a subset of the
>=C2=A0 =C2=A0 =C2=A0resources
>=C2=A0 =C2=A0 =C2=A0 > that the gpu manages, or can assign UUIDs to.= I am not sure why
>=C2=A0 =C2=A0 =C2=A0 > the virt gpu driver would want to send a ASSI= GN_UUID for anything
>=C2=A0 =C2=A0 =C2=A0 > that is not a dmabuf (are we sure it does?), = but I am not super
>=C2=A0 =C2=A0 =C2=A0familiarized
>=C2=A0 =C2=A0 =C2=A0 > with virtgpu=C2=A0to begin with.
>
>=C2=A0 =C2=A0 =C2=A0In my understanding, an resource will be first crea= ted as OpenGL or
>=C2=A0 =C2=A0 =C2=A0Vulkan textures and then exported as a DMA-BUF file= descriptor. For
>=C2=A0 =C2=A0 =C2=A0these resource types exporting/importing code is ma= ndatory.
>
>=C2=A0 =C2=A0 =C2=A0For pixman buffers (i.e., non-virgl device), I don&= #39;t see a compelling
>=C2=A0 =C2=A0 =C2=A0reason to have cross-device sharing. It is possible= to omit resource
>=C2=A0 =C2=A0 =C2=A0UUID feature from non-virgl device to avoid impleme= nting complicated
>=C2=A0 =C2=A0 =C2=A0migration.
>
>
> I see, thanks for the clarification.
> I would assume you could avoid the UUID feature for those resources, b= ut
> I will need to check the driver implementation. It is worth checking <= br> > though, if
> that would simplify the implementation.
>
>
>=C2=A0 =C2=A0 =C2=A0 > But I see that internally, the GPU specs rela= te a UUID with a
>=C2=A0 =C2=A0 =C2=A0resource_id,
>=C2=A0 =C2=A0 =C2=A0 > so we still need both tables:
>=C2=A0 =C2=A0 =C2=A0 > - one to relate UUID with resource_id to be a= ble to locate the
>=C2=A0 =C2=A0 =C2=A0 > underlying resource
>=C2=A0 =C2=A0 =C2=A0 > - the table that holds the dmabuf with the UU= ID for cross-device
>=C2=A0 =C2=A0 =C2=A0sharing
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > With that in mind, sounds to me that the supp= ort for cross-device
>=C2=A0 =C2=A0 =C2=A0 > sharing could
>=C2=A0 =C2=A0 =C2=A0 > be added on top of this patch, once
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0https://l= ists.gnu.org/archive/html/qemu-devel/2023-09/msg01850.html
>=C2=A0 =C2=A0 =C2=A0<https= ://lists.gnu.org/archive/html/qemu-devel/2023-09/msg01850.html>
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0<https= ://lists.gnu.org/archive/html/qemu-devel/2023-09/msg01850.html
>=C2=A0 =C2=A0 =C2=A0<https= ://lists.gnu.org/archive/html/qemu-devel/2023-09/msg01850.html>><= br> >=C2=A0 =C2=A0 =C2=A0 > lands.
>
>=C2=A0 =C2=A0 =C2=A0That is possible, but I think it's better to im= plement cross-device
>=C2=A0 =C2=A0 =C2=A0sharing at the same time introducing virtio-dmabuf.=
>
>=C2=A0 =C2=A0 =C2=A0The current design of virtio-dmabuf looks somewhat = inconsistent; it's
>=C2=A0 =C2=A0 =C2=A0named "dmabuf", but internally the UUIDs = are stored into something
>=C2=A0 =C2=A0 =C2=A0named
>=C2=A0 =C2=A0 =C2=A0"resource_uuids" and it has SharedObjectT= ype so it's more like a
>=C2=A0 =C2=A0 =C2=A0generic
>=C2=A0 =C2=A0 =C2=A0resource sharing mechanism. If you actually have an= implementation of
>=C2=A0 =C2=A0 =C2=A0cross-device sharing using virtio-dmabuf, it will b= e clear what kind of
>=C2=A0 =C2=A0 =C2=A0feature 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=C2=A0= vague [1]
> (I guess purposely). It is up to the specific devices to define what a= n
> 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 o= f
> object,
> and the API exposes type-specific functions (for dmabufs,=C2=A0or othe= rs).
In the guest kernel, the name "virtio_dma_buf" represents the int= erface
between the *guest* kernel and *guest* user-space. It makes sense since the cross-device resource sharing is managed by the userspace and
DMA-BUF is the only interface between them for this purpose.

The situation is different for QEMU; QEMU interacts with backends using backend-specific interfaces (OpenGL/pixman) and virgl is capable to
export textures as DMA-BUF. DMA-BUF is not universal in this sense. As
such, we cannot just borrow the kernel-side naming but invent one.

It is not a gpu-specific feature. It is a generic cro= ss-device sharing
mechanism for virtio objects. In this case, vir= tio objects happen to be
dmabufs in this first iteration. Hence, = the name.

virtio-gpu (and vhost-user-gpu) will use= this feature only with virgl, that is
fine, and transversal to t= he object-sharing mechanism. It allows
to share dmabufs in the ho= st following how they are shared in the guest.
The virtgpu=C2=A0d= river may call ASSIGN_UUID for other types of resources (not sure,
but could be), but they will never be shared with other virtio devices.
So they are not too relevant. Also, the shared objects table could= potentially
be accessed from any virtio device, not only virtio-= gpu or virtio-video.

What I am trying to say, is t= hat the name focuses solely in its current usage,
i.e., sharing d= mabufs between virtio-gpu (as exporter), and virtio-video (as importer).
If it grows to something more, imo it can=C2=A0be renamed later.

Regards,
Albert
--00000000000084498506054d7be3--