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

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

Patch Review

This patch adds the object tracking infrastructure: a per-device restore list protected by a mutex, and logic to re-create objects on the host after hibernation.

**Issue 1 (minor): VRAM objects initialized but never tracked**

In `virtgpu_vram.c`:
```c
INIT_LIST_HEAD(&vram->base.restore_node);
```

VRAM objects get their `restore_node` initialized but are never added to the restore list. The `virtio_gpu_remove_from_restore_list()` call in `virtio_gpu_vram_free()` would be a harmless no-op on an initialized-but-not-linked list node. If VRAM objects are intentionally excluded from restoration (like virgl objects), a brief comment explaining why would be helpful, as the restore_node removal in the free path suggests they might have been intended for tracking.

**Issue 2 (minor): Misleading error code in `virtgpu_dma_buf_obj_resubmit()`**

```c
if (!bo->sgt) {
    DRM_ERROR("no sgt bound to virtio_gpu_object\n");
    return -ENOMEM;
}
```

`-ENOMEM` doesn't describe "no sgt bound". `-EINVAL` or `-ENOENT` would be more accurate.

**Issue 3 (nit): Inconsistent allocation macro**

`virtgpu_dma_buf_obj_resubmit()` uses `kvmalloc_array()` directly:
```c
ents = kvmalloc_array(bo->sgt->nents,
              sizeof(struct virtio_gpu_mem_entry),
              GFP_KERNEL);
```

while `virtio_gpu_object_shmem_init()` uses the `kvmalloc_objs` macro for the same type. Minor inconsistency.

**Issue 4 (nit): Extra blank line**

After `virtgpu_dma_buf_obj_resubmit()` there are two blank lines before `static const struct drm_gem_object_funcs`. Should be one.

**Observation: Restore logic correctness**

The `virtio_gpu_object_restore_all()` logic correctly handles three cases:
1. Imported dma-buf objects → `virtgpu_dma_buf_obj_resubmit()`
2. Blob objects → `shmem_init` + `cmd_resource_create_blob()`
3. Regular (non-blob, non-virgl) objects → `shmem_init` + `cmd_create_resource()` + `object_attach()`

The conditional `if (bo->params.blob || bo->attached)` before `shmem_init` correctly gates the ents/nents initialization to paths that use them. However, `ents` and `nents` are uninitialized at declaration — adding `= NULL` / `= 0` would silence potential compiler warnings and improve clarity.

---

---
Generated by Claude Code Patch Reviewer