Re: [QEMU PATCH v4 10/13] virtio-gpu: Resource UUID

2023-09-15 Thread Albert Esteve 
On Thu, Sep 14, 2023 at 6:56 PM Akihiko Odaki 
wrote:

> On 2023/09/14 17:29, Albert Esteve wrote:
> >
> >
> > On Thu, Sep 14, 2023 at 9:17 AM Akihiko Odaki  > > wrote:
> >
> > On 2023/09/13 23:18, Albert Esteve wrote:
> >  >
> >  >
> >  > On Wed, Sep 13, 2023 at 3:43 PM Akihiko Odaki
> > mailto:akihiko.od...@daynix.com>
> >  >  > >> wrote:
> >  >
> >  > On 2023/09/13 21:58, Albert Esteve wrote:
> >  >  >
> >  >  >
> >  >  > On Wed, Sep 13, 2023 at 2:22 PM Akihiko Odaki
> >  > mailto:akihiko.od...@daynix.com>
> > >
> >  >  >  > 
> >  >  >  >  >  >
> >  >  > On 2023/09/13 20:34, Albert Esteve wrote:
> >  >  >  >
> >  >  >  >
> >  >  >  > On Wed, Sep 13, 2023 at 12:34 PM 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
> >  >  >  >  >
> >  >  >  >
> >  >  >
> >  >
> >   <
> 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 <
> https://lists.gnu.org/archive/html/qemu-devel/2023-09/msg01853.html>
> >  >  >  >  > IMHO, ideally, virtio-gpu and vhost-user-gpu
> > both,
> >  > would
> >  >  > use the
> >  >  >  >

Re: [QEMU PATCH v4 10/13] virtio-gpu: Resource UUID

2023-09-14 Thread Akihiko Odaki 

On 2023/09/14 17:29, Albert Esteve wrote:



On Thu, Sep 14, 2023 at 9:17 AM Akihiko Odaki > wrote:


On 2023/09/13 23:18, Albert Esteve wrote:
 >
 >
 > On Wed, Sep 13, 2023 at 3:43 PM Akihiko Odaki
mailto:akihiko.od...@daynix.com>
 > >> wrote:
 >
 >     On 2023/09/13 21:58, Albert Esteve wrote:
 >      >
 >      >
 >      > On Wed, Sep 13, 2023 at 2:22 PM Akihiko Odaki
 >     mailto:akihiko.od...@daynix.com>
>
 >      > 
 >           >
 >      >     On 2023/09/13 20:34, Albert Esteve wrote:
 >      >      >
 >      >      >
 >      >      > On Wed, Sep 13, 2023 at 12:34 PM Akihiko Odaki
 >      >     mailto:akihiko.od...@daynix.com> >
 >      >>
 >      >      > 
 >     >
 >      >     
 >      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
 >      >     complicates
 >   

Re: [QEMU PATCH v4 10/13] virtio-gpu: Resource UUID

2023-09-14 Thread Albert Esteve 
On Thu, Sep 14, 2023 at 9:17 AM Akihiko Odaki 
wrote:

> On 2023/09/13 23:18, Albert Esteve wrote:
> >
> >
> > On Wed, Sep 13, 2023 at 3:43 PM Akihiko Odaki  > > wrote:
> >
> > On 2023/09/13 21:58, Albert Esteve wrote:
> >  >
> >  >
> >  > On Wed, Sep 13, 2023 at 2:22 PM Akihiko Odaki
> > mailto:akihiko.od...@daynix.com>
> >  >  > >> wrote:
> >  >
> >  > On 2023/09/13 20:34, Albert Esteve wrote:
> >  >  >
> >  >  >
> >  >  > On Wed, Sep 13, 2023 at 12:34 PM Akihiko Odaki
> >  > mailto:akihiko.od...@daynix.com>
> > >
> >  >  >  > 
> >  >  >  >  >  >
> >  >  > 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 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
> > 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.
> >  >
>

Re: [QEMU PATCH v4 10/13] virtio-gpu: Resource UUID

2023-09-14 Thread Akihiko Odaki 

On 2023/09/13 23:18, Albert Esteve wrote:



On Wed, Sep 13, 2023 at 3:43 PM Akihiko Odaki > wrote:


On 2023/09/13 21:58, Albert Esteve wrote:
 >
 >
 > On Wed, Sep 13, 2023 at 2:22 PM Akihiko Odaki
mailto:akihiko.od...@daynix.com>
 > >> wrote:
 >
 >     On 2023/09/13 20:34, Albert Esteve wrote:
 >      >
 >      >
 >      > On Wed, Sep 13, 2023 at 12:34 PM Akihiko Odaki
 >     mailto:akihiko.od...@daynix.com>
>
 >      > 
 >           >
 >      >     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
 >     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, w

Re: [QEMU PATCH v4 10/13] virtio-gpu: Resource UUID

2023-09-13 Thread Albert Esteve 
On Wed, Sep 13, 2023 at 4:18 PM Albert Esteve  wrote:

>
>
> On Wed, Sep 13, 2023 at 3:43 PM Akihiko Odaki 
> wrote:
>
>> On 2023/09/13 21:58, Albert Esteve wrote:
>> >
>> >
>> > On Wed, Sep 13, 2023 at 2:22 PM Akihiko Odaki > > > wrote:
>> >
>> > On 2023/09/13 20:34, Albert Esteve wrote:
>> >  >
>> >  >
>> >  > On Wed, Sep 13, 2023 at 12:34 PM Akihiko Odaki
>> > mailto:akihiko.od...@daynix.com>
>> >  > > > >> 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>>>
>> >  >  > 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 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/
>> >  <
>> 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
>> 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 clarif

Re: [QEMU PATCH v4 10/13] virtio-gpu: Resource UUID

2023-09-13 Thread Albert Esteve 
On Wed, Sep 13, 2023 at 3:43 PM Akihiko Odaki 
wrote:

> On 2023/09/13 21:58, Albert Esteve wrote:
> >
> >
> > On Wed, Sep 13, 2023 at 2:22 PM Akihiko Odaki  > > wrote:
> >
> > On 2023/09/13 20:34, Albert Esteve wrote:
> >  >
> >  >
> >  > On Wed, Sep 13, 2023 at 12:34 PM Akihiko Odaki
> > mailto:akihiko.od...@daynix.com>
> >  >  > >> 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 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
> 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.

Re: [QEMU PATCH v4 10/13] virtio-gpu: Resource UUID

2023-09-13 Thread Akihiko Odaki 

On 2023/09/13 21:58, Albert Esteve wrote:



On Wed, Sep 13, 2023 at 2:22 PM Akihiko Odaki > wrote:


On 2023/09/13 20:34, Albert Esteve wrote:
 >
 >
 > On Wed, Sep 13, 2023 at 12:34 PM Akihiko Odaki
mailto:akihiko.od...@daynix.com>
 > >> 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
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 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 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.



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.


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

Re: [QEMU PATCH v4 10/13] virtio-gpu: Resource UUID

2023-09-13 Thread Albert Esteve 
On Wed, Sep 13, 2023 at 2:22 PM Akihiko Odaki 
wrote:

> On 2023/09/13 20:34, Albert Esteve wrote:
> >
> >
> > On Wed, Sep 13, 2023 at 12:34 PM 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 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 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 familiarized
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

Re: [QEMU PATCH v4 10/13] virtio-gpu: Resource UUID

2023-09-13 Thread Akihiko Odaki 

On 2023/09/13 20:34, Albert Esteve wrote:



On Wed, Sep 13, 2023 at 12:34 PM 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 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.


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.


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.

Re: [QEMU PATCH v4 10/13] virtio-gpu: Resource UUID

2023-09-13 Thread Albert Esteve 
On Wed, Sep 13, 2023 at 12:34 PM 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 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/

Re: [QEMU PATCH v4 10/13] virtio-gpu: Resource UUID

2023-09-13 Thread Akihiko Odaki 

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 complicates 
migration.


Regards,
Akihiko Odaki

Re: [QEMU PATCH v4 10/13] virtio-gpu: Resource UUID

2023-09-13 Thread Albert Esteve 
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.

Which, in terms of code, would mean changing:
g_hash_table_insert(g->resource_uuids,
GUINT_TO_POINTER(assign.resource_id), uuid);
by:
virtio_add_dmabuf(uuid, assign.resource_id);

...and simplify part of the infrastructure.

Let me know what you think.

Regard,
Albert

Re: [QEMU PATCH v4 10/13] virtio-gpu: Resource UUID

2023-09-09 Thread Akihiko Odaki 

On 2023/09/09 18:09, Huang Rui wrote:

On Thu, Aug 31, 2023 at 06:36:57PM +0800, Akihiko Odaki wrote:

On 2023/08/31 18:32, Huang Rui wrote:

From: Antonio Caggiano 

Enable resource UUID feature and implement command resource assign UUID.
This is done by introducing a hash table to map resource IDs to their
UUIDs.


The hash table does not seem to be stored during migration.


May I know whether you point g->resource_uuids table data in VirtIOGPU
device should be stored in virtio_gpu_save() and resumed in
virtio_gpu_load() for virtio migration?


Yes, that's what I meant.

Regards,
Akihiko Odaki

Re: [QEMU PATCH v4 10/13] virtio-gpu: Resource UUID

2023-09-09 Thread Huang Rui 
On Thu, Aug 31, 2023 at 06:36:57PM +0800, Akihiko Odaki wrote:
> On 2023/08/31 18:32, Huang Rui wrote:
> > From: Antonio Caggiano 
> > 
> > Enable resource UUID feature and implement command resource assign UUID.
> > This is done by introducing a hash table to map resource IDs to their
> > UUIDs.
> 
> The hash table does not seem to be stored during migration.

May I know whether you point g->resource_uuids table data in VirtIOGPU
device should be stored in virtio_gpu_save() and resumed in
virtio_gpu_load() for virtio migration?

> 
> > 
> > Signed-off-by: Antonio Caggiano 
> > Signed-off-by: Huang Rui 
> > ---
> > 
> > v1->v2:
> > - Separate declarations from code.
> > 
> >   hw/display/trace-events|  1 +
> >   hw/display/virtio-gpu-base.c   |  2 ++
> >   hw/display/virtio-gpu-virgl.c  | 21 +
> >   hw/display/virtio-gpu.c| 41 ++
> >   include/hw/virtio/virtio-gpu.h |  4 
> >   5 files changed, 69 insertions(+)
> > 
> > diff --git a/hw/display/trace-events b/hw/display/trace-events
> > index 2336a0ca15..54d6894c59 100644
> > --- a/hw/display/trace-events
> > +++ b/hw/display/trace-events
> > @@ -41,6 +41,7 @@ virtio_gpu_cmd_res_create_blob(uint32_t res, uint64_t 
> > size) "res 0x%x, size %" P
> >   virtio_gpu_cmd_res_unref(uint32_t res) "res 0x%x"
> >   virtio_gpu_cmd_res_back_attach(uint32_t res) "res 0x%x"
> >   virtio_gpu_cmd_res_back_detach(uint32_t res) "res 0x%x"
> > +virtio_gpu_cmd_res_assign_uuid(uint32_t res) "res 0x%x"
> >   virtio_gpu_cmd_res_xfer_toh_2d(uint32_t res) "res 0x%x"
> >   virtio_gpu_cmd_res_xfer_toh_3d(uint32_t res) "res 0x%x"
> >   virtio_gpu_cmd_res_xfer_fromh_3d(uint32_t res) "res 0x%x"
> > diff --git a/hw/display/virtio-gpu-base.c b/hw/display/virtio-gpu-base.c
> > index 4f2b0ba1f3..f44388715c 100644
> > --- a/hw/display/virtio-gpu-base.c
> > +++ b/hw/display/virtio-gpu-base.c
> > @@ -236,6 +236,8 @@ virtio_gpu_base_get_features(VirtIODevice *vdev, 
> > uint64_t features,
> >   features |= (1 << VIRTIO_GPU_F_CONTEXT_INIT);
> >   }
> >   
> > +features |= (1 << VIRTIO_GPU_F_RESOURCE_UUID);
> > +
> >   return features;
> >   }
> >   
> > diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-virgl.c
> > index 17b634d4ee..1a996a08fc 100644
> > --- a/hw/display/virtio-gpu-virgl.c
> > +++ b/hw/display/virtio-gpu-virgl.c
> > @@ -36,6 +36,7 @@ static void virgl_cmd_create_resource_2d(VirtIOGPU *g,
> >   {
> >   struct virtio_gpu_resource_create_2d c2d;
> >   struct virgl_renderer_resource_create_args args;
> > +struct virtio_gpu_simple_resource *res;
> >   
> >   VIRTIO_GPU_FILL_CMD(c2d);
> >   trace_virtio_gpu_cmd_res_create_2d(c2d.resource_id, c2d.format,
> > @@ -53,6 +54,14 @@ static void virgl_cmd_create_resource_2d(VirtIOGPU *g,
> >   args.nr_samples = 0;
> >   args.flags = VIRTIO_GPU_RESOURCE_FLAG_Y_0_TOP;
> >   virgl_renderer_resource_create(&args, NULL, 0);
> > +
> > +res = g_new0(struct virtio_gpu_simple_resource, 1);
> > +if (!res) {
> > +cmd->error = VIRTIO_GPU_RESP_ERR_OUT_OF_MEMORY;
> > +return;
> 
> virglrenderer thinks the resource is alive in such a situation.

Yes, so we can move the resource allocation in front of below virglrenderer
resource creation.

virgl_renderer_resource_create(&args, NULL, 0);

> 
> > +}
> > +res->resource_id = c2d.resource_id;
> > +QTAILQ_INSERT_HEAD(&g->reslist, res, next);
> >   }
> >   
> >   static void virgl_cmd_create_resource_3d(VirtIOGPU *g,
> > @@ -60,6 +69,7 @@ static void virgl_cmd_create_resource_3d(VirtIOGPU *g,
> >   {
> >   struct virtio_gpu_resource_create_3d c3d;
> >   struct virgl_renderer_resource_create_args args;
> > +struct virtio_gpu_simple_resource *res;
> >   
> >   VIRTIO_GPU_FILL_CMD(c3d);
> >   trace_virtio_gpu_cmd_res_create_3d(c3d.resource_id, c3d.format,
> > @@ -77,6 +87,14 @@ static void virgl_cmd_create_resource_3d(VirtIOGPU *g,
> >   args.nr_samples = c3d.nr_samples;
> >   args.flags = c3d.flags;
> >   virgl_renderer_resource_create(&args, NULL, 0);
> > +
> > +res = g_new0(struct virtio_gpu_simple_resource, 1);
> > +if (!res) {
> > +cmd->error = VIRTIO_GPU_RESP_ERR_OUT_OF_MEMORY;
> > +return;
> > +}
> > +res->resource_id = c3d.resource_id;
> > +QTAILQ_INSERT_HEAD(&g->reslist, res, next);
> >   }
> >   
> >   static void virgl_resource_destroy(VirtIOGPU *g,
> > @@ -682,6 +700,9 @@ void virtio_gpu_virgl_process_cmd(VirtIOGPU *g,
> >   /* TODO add security */
> >   virgl_cmd_ctx_detach_resource(g, cmd);
> >   break;
> > +case VIRTIO_GPU_CMD_RESOURCE_ASSIGN_UUID:
> > +virtio_gpu_resource_assign_uuid(g, cmd);
> > +break;
> >   case VIRTIO_GPU_CMD_GET_CAPSET_INFO:
> >   virgl_cmd_get_capset_info(g, cmd);
> >   break;
> > diff --git a/hw/display/virtio-gpu.c b/hw/display/virtio-gpu.c
> > index cc4c1f81bb..770e4747e3 1

Re: [QEMU PATCH v4 10/13] virtio-gpu: Resource UUID

2023-08-31 Thread Akihiko Odaki 

On 2023/08/31 18:32, Huang Rui wrote:

From: Antonio Caggiano 

Enable resource UUID feature and implement command resource assign UUID.
This is done by introducing a hash table to map resource IDs to their
UUIDs.


The hash table does not seem to be stored during migration.



Signed-off-by: Antonio Caggiano 
Signed-off-by: Huang Rui 
---

v1->v2:
- Separate declarations from code.

  hw/display/trace-events|  1 +
  hw/display/virtio-gpu-base.c   |  2 ++
  hw/display/virtio-gpu-virgl.c  | 21 +
  hw/display/virtio-gpu.c| 41 ++
  include/hw/virtio/virtio-gpu.h |  4 
  5 files changed, 69 insertions(+)

diff --git a/hw/display/trace-events b/hw/display/trace-events
index 2336a0ca15..54d6894c59 100644
--- a/hw/display/trace-events
+++ b/hw/display/trace-events
@@ -41,6 +41,7 @@ virtio_gpu_cmd_res_create_blob(uint32_t res, uint64_t size) "res 
0x%x, size %" P
  virtio_gpu_cmd_res_unref(uint32_t res) "res 0x%x"
  virtio_gpu_cmd_res_back_attach(uint32_t res) "res 0x%x"
  virtio_gpu_cmd_res_back_detach(uint32_t res) "res 0x%x"
+virtio_gpu_cmd_res_assign_uuid(uint32_t res) "res 0x%x"
  virtio_gpu_cmd_res_xfer_toh_2d(uint32_t res) "res 0x%x"
  virtio_gpu_cmd_res_xfer_toh_3d(uint32_t res) "res 0x%x"
  virtio_gpu_cmd_res_xfer_fromh_3d(uint32_t res) "res 0x%x"
diff --git a/hw/display/virtio-gpu-base.c b/hw/display/virtio-gpu-base.c
index 4f2b0ba1f3..f44388715c 100644
--- a/hw/display/virtio-gpu-base.c
+++ b/hw/display/virtio-gpu-base.c
@@ -236,6 +236,8 @@ virtio_gpu_base_get_features(VirtIODevice *vdev, uint64_t 
features,
  features |= (1 << VIRTIO_GPU_F_CONTEXT_INIT);
  }
  
+features |= (1 << VIRTIO_GPU_F_RESOURCE_UUID);

+
  return features;
  }
  
diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-virgl.c

index 17b634d4ee..1a996a08fc 100644
--- a/hw/display/virtio-gpu-virgl.c
+++ b/hw/display/virtio-gpu-virgl.c
@@ -36,6 +36,7 @@ static void virgl_cmd_create_resource_2d(VirtIOGPU *g,
  {
  struct virtio_gpu_resource_create_2d c2d;
  struct virgl_renderer_resource_create_args args;
+struct virtio_gpu_simple_resource *res;
  
  VIRTIO_GPU_FILL_CMD(c2d);

  trace_virtio_gpu_cmd_res_create_2d(c2d.resource_id, c2d.format,
@@ -53,6 +54,14 @@ static void virgl_cmd_create_resource_2d(VirtIOGPU *g,
  args.nr_samples = 0;
  args.flags = VIRTIO_GPU_RESOURCE_FLAG_Y_0_TOP;
  virgl_renderer_resource_create(&args, NULL, 0);
+
+res = g_new0(struct virtio_gpu_simple_resource, 1);
+if (!res) {
+cmd->error = VIRTIO_GPU_RESP_ERR_OUT_OF_MEMORY;
+return;


virglrenderer thinks the resource is alive in such a situation.


+}
+res->resource_id = c2d.resource_id;
+QTAILQ_INSERT_HEAD(&g->reslist, res, next);
  }
  
  static void virgl_cmd_create_resource_3d(VirtIOGPU *g,

@@ -60,6 +69,7 @@ static void virgl_cmd_create_resource_3d(VirtIOGPU *g,
  {
  struct virtio_gpu_resource_create_3d c3d;
  struct virgl_renderer_resource_create_args args;
+struct virtio_gpu_simple_resource *res;
  
  VIRTIO_GPU_FILL_CMD(c3d);

  trace_virtio_gpu_cmd_res_create_3d(c3d.resource_id, c3d.format,
@@ -77,6 +87,14 @@ static void virgl_cmd_create_resource_3d(VirtIOGPU *g,
  args.nr_samples = c3d.nr_samples;
  args.flags = c3d.flags;
  virgl_renderer_resource_create(&args, NULL, 0);
+
+res = g_new0(struct virtio_gpu_simple_resource, 1);
+if (!res) {
+cmd->error = VIRTIO_GPU_RESP_ERR_OUT_OF_MEMORY;
+return;
+}
+res->resource_id = c3d.resource_id;
+QTAILQ_INSERT_HEAD(&g->reslist, res, next);
  }
  
  static void virgl_resource_destroy(VirtIOGPU *g,

@@ -682,6 +700,9 @@ void virtio_gpu_virgl_process_cmd(VirtIOGPU *g,
  /* TODO add security */
  virgl_cmd_ctx_detach_resource(g, cmd);
  break;
+case VIRTIO_GPU_CMD_RESOURCE_ASSIGN_UUID:
+virtio_gpu_resource_assign_uuid(g, cmd);
+break;
  case VIRTIO_GPU_CMD_GET_CAPSET_INFO:
  virgl_cmd_get_capset_info(g, cmd);
  break;
diff --git a/hw/display/virtio-gpu.c b/hw/display/virtio-gpu.c
index cc4c1f81bb..770e4747e3 100644
--- a/hw/display/virtio-gpu.c
+++ b/hw/display/virtio-gpu.c
@@ -966,6 +966,37 @@ virtio_gpu_resource_detach_backing(VirtIOGPU *g,
  virtio_gpu_cleanup_mapping(g, res);
  }
  
+void virtio_gpu_resource_assign_uuid(VirtIOGPU *g,

+ struct virtio_gpu_ctrl_command *cmd)
+{
+struct virtio_gpu_simple_resource *res;
+struct virtio_gpu_resource_assign_uuid assign;
+struct virtio_gpu_resp_resource_uuid resp;
+QemuUUID *uuid = NULL;


This initialization is unnecessary.


+
+VIRTIO_GPU_FILL_CMD(assign);
+virtio_gpu_bswap_32(&assign, sizeof(assign));
+trace_virtio_gpu_cmd_res_assign_uuid(assign.resource_id);
+
+res = virtio_gpu_find_check_resource(g, assign.resource_id, false, __func__, 
&cmd->error);
+if (!res) {
+return;
+}
+