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 893D4EDEC4F for ; Wed, 13 Sep 2023 12:58:52 +0000 (UTC) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qgPRw-0004lp-6O; Wed, 13 Sep 2023 08:58:32 -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 1qgPRs-0004lM-82 for qemu-devel@nongnu.org; Wed, 13 Sep 2023 08:58:28 -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 1qgPRp-0005Kg-BT for qemu-devel@nongnu.org; Wed, 13 Sep 2023 08:58:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1694609904; 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=39ec+42JeB+j1CbwXASOlDxqz4wzR2fUyc8rEMzvKgY=; b=XCQcJUhwALR6jbzeAJJk37m+vVTridoRwHwUf1v0UFXT9s1BYb9GSQRDhT2iA5rtAGIqnY Is5+rokWai6X0YiM5X5QNrA32NMMZk0E2j5uHK+BSuasFjfjuxnZH3A6caSKiQ5yaSP4zn d1Ind7kcxMh/HBQCsNeydSh/6CIJj6s= Received: from mail-pj1-f71.google.com (mail-pj1-f71.google.com [209.85.216.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-102-DlgmH5B7NZOyZq7JRqnKFw-1; Wed, 13 Sep 2023 08:58:20 -0400 X-MC-Unique: DlgmH5B7NZOyZq7JRqnKFw-1 Received: by mail-pj1-f71.google.com with SMTP id 98e67ed59e1d1-267f666104aso890121a91.0 for ; Wed, 13 Sep 2023 05:58:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694609899; x=1695214699; 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=39ec+42JeB+j1CbwXASOlDxqz4wzR2fUyc8rEMzvKgY=; b=aPlK5Lmu+uTGhYSD1N92BUFSjqLv44Gssw3g7QSrSX7cQtWPRv06ve4+FOMHOUY0/H yQc04otDEixbn5Y5BTIa5TZVrt83W7kY8EHmBO9j6uY2ofI8Ifn/AYRw0K3YrZEehK0n 4Vk0y4n+/+1drMAQbGswL5sMwo3elMZRAtDwi64oXOw8jd7Gz4Qlxq8ekHek5Czm/+j8 ywrSPbby7eyr1KU/2klrooBUzJxvHCPgnCx951GSyqkdl5oK4YYAB/A8J34bMK2hJDi7 rPGAC5fkCmYVYjqNefxlct6MOWBYyrFC2hLmroT/VPJRSpJssyeejTye/jJ4PfK5tdZv I19w== X-Gm-Message-State: AOJu0YzYTDzZW9HwxFb+KR9ugPYpQ2HBuhScWWQ0mZCfvh/m1YtskRnv ZALWb7/N8wmTRYFNggySwswZOebH1ZUAvQG3Xg0V1BY2Oz2CyjhNv7aGKKhivMnAmuVDDMS6aRM BLrwfgAuZfcLj9FylWfvxih4yekx0sq0= X-Received: by 2002:a17:90b:1902:b0:269:4fe8:687 with SMTP id mp2-20020a17090b190200b002694fe80687mr3917102pjb.19.1694609899652; Wed, 13 Sep 2023 05:58:19 -0700 (PDT) X-Google-Smtp-Source: AGHT+IH61qvMRdN3LPMiWAjCSRDtpzdel5iiJmmJEhut4Q0QbARnWkG/bcS1VhoV1g2d29bwNFmFQWLpet9R1u26/N8= X-Received: by 2002:a17:90b:1902:b0:269:4fe8:687 with SMTP id mp2-20020a17090b190200b002694fe80687mr3917071pjb.19.1694609899262; Wed, 13 Sep 2023 05:58:19 -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> In-Reply-To: <5e88f5d5-5aa2-4052-b250-69c2a443344f@daynix.com> From: Albert Esteve Date: Wed, 13 Sep 2023 14:58:07 +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="00000000000014281b06053d1d4f" 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 --00000000000014281b06053d1d4f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 > > > > > > > > > >> > > > 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 complicat= es > > 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 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 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 anything that is not a dmabuf (are we sure it does?), but I am not super familiarize= d with virtgpu to begin with. 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-device sharing could be added on top of this patch, once https://lists.gnu.org/archive/html/qemu-devel/2023-09/msg01850.html lands. I hope that makes sense. Regards, Albert --00000000000014281b06053d1d4f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Sep 13, 2023 at 2:22= =E2=80=AFPM Akihiko Odaki <a= kihiko.odaki@daynix.com> wrote:
On 2023/09/13 20:34, Albert Esteve wrote:
>
>
> On Wed, Sep 13, 2023 at 12:34=E2=80=AFPM Akihiko Odaki <akihiko.odaki@daynix.com=
> <mailto:akihiko.odaki@daynix.com>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0On 2023/09/13 16:55, Albert Esteve wrote:
>=C2=A0 =C2=A0 =C2=A0 > Hi Antonio,
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > If I'm not mistaken, this patch is relate= d with:
>=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<https= ://lists.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>><= br> >=C2=A0 =C2=A0 =C2=A0 > IMHO, ideally, virtio-gpu and vhost-user-gpu = both, would use the
>=C2=A0 =C2=A0 =C2=A0 > infrastructure from the patch I linked to sto= re the
>=C2=A0 =C2=A0 =C2=A0 > virtio objects, so that they can be later sha= red with other devices.
>
>=C2=A0 =C2=A0 =C2=A0I don't think such sharing is possible because = the resources are
>=C2=A0 =C2=A0 =C2=A0identified by IDs that are local to the device. Tha= t also complicates
>=C2=A0 =C2=A0 =C2=A0migration.
>
>=C2=A0 =C2=A0 =C2=A0Regards,
>=C2=A0 =C2=A0 =C2=A0Akihiko Odaki
>
> Hi Akihiko,
>
> As far as I understand, the feature to export dma-bufs=C2=A0from the > virtgpu was introduced as part of the virtio cross-device sharing
> proposal [1]. Thus, it shall be posible. When virtgpu=C2=A0ASSING_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 assi= gned
> UUID to find the dmabuf in the host (using the patch that I linked abo= ve),
> and import it.
>
> [1] - https://lwn.net/Articles/828988/ <https://l= wn.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.
=C2=A0

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.

<= div>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 lik= e 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 the underlying
resource what we want to use here.
<= div>=C2=A0

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 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= =C2=A0are 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 anything
that is not a dmabuf (ar= e we sure it does?), but I am not super familiarized
with virtgpu= =C2=A0to begin with.
But I see that internally, the GPU specs rel= ate 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 underl= ying 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-device sharing could
lands.

I h= ope that makes sense.
Regards,
Albert
--00000000000014281b06053d1d4f--