Claude review: Introduce dmem driver and implement Xe support

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

Patch Review

Good abstraction. The vtable in `igt_dmem_driver.h` is clean and minimal.

**Issue: `xe_dmem_allocate_vram` leaks BO on bind failure.**
If `__xe_vm_bind_lr_sync` fails, the handle is stored in `xe_ctx->handles[n_bo]` but never closed:

```c
err = __xe_bo_create(xe_ctx->fd, 0, len, xe_ctx->vram_region,
                     DRM_XE_GEM_CREATE_FLAG_DEFER_BACKING,
                     NULL, &handle);
if (err)
    goto out;

xe_ctx->handles[n_bo] = handle;

err = __xe_vm_bind_lr_sync(xe_ctx->fd, xe_ctx->vm, handle, 0,
                           xe_ctx->addr, len, 0);
if (err)
    goto out;  /* handle stored but addr not incremented, BO not closed */
```

When bind fails, the caller sees the error and stops, but `free_vram` walks `handles[0..n_bo-1]` and will try to unbind at an address that was never bound. The stored handle will get a `gem_close` which is fine, but the `xe_vm_unbind_lr_sync` for that address will fail or operate on wrong memory. Consider closing the handle on bind failure, or at minimum zeroing the handle entry.

**Issue: `xe_ctx->addr` is monotonically increasing.** After `xe_dmem_free_vram`, `addr` is not reset. This means subsequent `allocate_vram` calls bind at ever-higher VAs. For the existing eviction test (single allocate/free cycle) this is fine, but the new `test_current` in patch 6 does three allocate/free cycles, which will consume `3 * cg_max` worth of VA space. Not fatal, but wasteful and could theoretically exhaust the VA range on very large VRAM systems.

**Minor: Error code mismatch in `xe_dmem_init`.** When no VRAM region is found, the function returns `-ENOMEM`, which is misleading. Something like `-ENODEV` would be more appropriate.

---
Generated by Claude Code Patch Reviewer