Claude review: drm/virtio: Add support for saving and restoring virtio_gpu_objects

[Claude Code Review Bot <claude-review@example.com>]

Patch Review

**Overall:** The restore-list tracking approach is sensible. Objects are tracked at creation and removed before free, with proper mutex protection. The restore path correctly differentiates between blob, non-blob, and imported dmabuf objects.

**Issue 1 — 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 crash, but VRAM objects won't survive hibernation. If this is intentional (VRAM objects are typically host-visible blobs that may require special handling), it should be documented in the commit message or with a comment.

**Issue 2 — 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 = 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 = false;
        virtio_gpu_object_attach(vgdev, bo, ents, nents);
    }
}
```

If `!bo->params.blob && !bo->attached`, `ents`/`nents` are never initialized, but they're also never used — the else-branch calls `virtio_gpu_cmd_create_resource` with `NULL, NULL` and skips attach. This is correct but could confuse a reader. An explicit `ents = NULL; nents = 0;` initialization at declaration would help.

**Issue 3 — 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 = cpu_to_le64(sg_dma_address(sl));
    ents[i].length = cpu_to_le32(sg_dma_len(sl));
```

This is correct for imported dmabufs (which always come through `dma_buf_map_attachment` and use DMA-mapped addresses), but differs from `virtio_gpu_object_shmem_init` which has a `use_dma_api` split for non-imported objects. Just confirming this is intentional — and it is, since imported objects always go through the DMA API path.

**Nit — Extra blank line after `virtgpu_dma_buf_obj_resubmit()`:**

```c
	return 0;
}


static const struct drm_gem_object_funcs virtgpu_gem_dma_buf_funcs = {
```

Double blank line should be single.

---

---
Generated by Claude Code Patch Reviewer