Hi Dmitry, > Subject: Re: [PATCH v5 2/3] drm/virtio: Add support for saving and restoring > virtio_gpu_objects > > On 10/3/25 08:34, [email protected] wrote: > > +int virtio_gpu_object_restore_all(struct virtio_gpu_device *vgdev) { > > + struct virtio_gpu_object *bo, *tmp; > > + struct virtio_gpu_mem_entry *ents; > > + unsigned int nents; > > + int ret = 0; > > + > > + spin_lock(&vgdev->obj_restore_lock); > > + list_for_each_entry_safe(bo, tmp, &vgdev->obj_restore_list, list) { > > + ret = virtio_gpu_object_shmem_init(vgdev, bo, &ents, &nents); > > + if (ret) > > + break; > > + > > + if (bo->params.blob) { > > + virtio_gpu_cmd_resource_create_blob(vgdev, bo, &bo- > >params, > > + ents, nents); > > + } else if (bo->params.virgl) { > > + virtio_gpu_cmd_resource_create_3d(vgdev, bo, &bo- > >params, > > + NULL, NULL); > > + > > + if (bo->attached) { > > + bo->attached = false; > > + virtio_gpu_object_attach(vgdev, bo, ents, > nents); > > + } > > + } else { > > No need to restore blob and 3d resources that we don't support restore of and > that won't be in the obj_restore_list since only shmem objs are added to the > list. > We are very interested in restoration of blob as well. It is actually the primary type of resource we want to recover because those are used as guest frame buffer we render in QEMU. Can you tell me why it should be excluded? Would it be because of ambiguity of the location of backing pages for it (e.g. VRAM)?
And 3D is not our primary interest so I don't have any issue excluding it but it would be great if you can explain the reason for it as well. Thanks! > -- > Best regards, > Dmitry
