From mboxrd@z Thu Jan  1 00:00:00 1970
From: Claude Code Review Bot <claude-review@example.com>
To: dri-devel-reviews@example.com
Subject: Claude review: drm/virtio: Add support for saving and restoring virtio_gpu_objects
Date: Wed, 27 May 2026 14:17:08 +1000
Message-ID: <review-patch2-20260526192814.179673-3-dongwon.kim@intel.com>
In-Reply-To: <20260526192814.179673-3-dongwon.kim@intel.com>
References: <20260526192814.179673-1-dongwon.kim@intel.com> <20260526192814.179673-3-dongwon.kim@intel.com>
X-Mailer: Claude Code Patch Reviewer
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Patch Review

**Overall:** The restore-list tracking approach is sensible. Objects are tr=
acked at creation and removed before free, with proper mutex protection. Th=
e restore path correctly differentiates between blob, non-blob, and importe=
d dmabuf objects.

**Issue 1 =E2=80=94 VRAM objects silently excluded from restoration:**

`virtio_gpu_vram_create()` initializes the restore_node but never adds the =
object to the restore list:

```c
INIT_LIST_HEAD(&vram->base.restore_node);
// ... no call to virtio_gpu_add_object_to_restore_list()
```

Yet `virtio_gpu_vram_free()` calls `virtio_gpu_remove_from_restore_list(bo)=
`. The `list_del_init` on a self-referencing node is safe, so this won't cr=
ash, but VRAM objects won't survive hibernation. If this is intentional (VR=
AM objects are typically host-visible blobs that may require special handli=
ng), it should be documented in the commit message or with a comment.

**Issue 2 =E2=80=94 Uninitialized `ents` on non-blob/non-attached path (not=
 a bug):**

In `virtio_gpu_object_restore_all()`:

```c
if (bo->params.blob || bo->attached) {
    ret =3D 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 {
    virtio_gpu_cmd_create_resource(vgdev, bo, &bo->params,
                                   NULL, NULL);
    if (bo->attached) {
        bo->attached =3D false;
        virtio_gpu_object_attach(vgdev, bo, ents, nents);
    }
}
```

If `!bo->params.blob && !bo->attached`, `ents`/`nents` are never initialize=
d, but they're also never used =E2=80=94 the else-branch calls `virtio_gpu_=
cmd_create_resource` with `NULL, NULL` and skips attach. This is correct bu=
t could confuse a reader. An explicit `ents =3D NULL; nents =3D 0;` initial=
ization at declaration would help.

**Issue 3 =E2=80=94 virtgpu_dma_buf_obj_resubmit always uses DMA addresses:=
**

The resubmit path unconditionally uses `sg_dma_address`/`sg_dma_len`:

```c
for_each_sgtable_dma_sg(bo->sgt, sl, i) {
    ents[i].addr =3D cpu_to_le64(sg_dma_address(sl));
    ents[i].length =3D cpu_to_le32(sg_dma_len(sl));
```

This is correct for imported dmabufs (which always come through `dma_buf_ma=
p_attachment` and use DMA-mapped addresses), but differs from `virtio_gpu_o=
bject_shmem_init` which has a `use_dma_api` split for non-imported objects.=
 Just confirming this is intentional =E2=80=94 and it is, since imported ob=
jects always go through the DMA API path.

**Nit =E2=80=94 Extra blank line after `virtgpu_dma_buf_obj_resubmit()`:**

```c
	return 0;
}


static const struct drm_gem_object_funcs virtgpu_gem_dma_buf_funcs =3D {
```

Double blank line should be single.

---

---
Generated by Claude Code Patch Reviewer