Claude review: drm/xe/xe_vm: Implement xe_vm_get_property_ioctl

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

Patch Review

**Missing MBZ validation for `pad` and `extensions`**: The ioctl handler checks `args->reserved[0..2]` but doesn't validate:
- `args->pad` (documented as MBZ)
- `args->extensions` (should be 0 or a valid extension pointer)

This should be:
```c
if (XE_IOCTL_DBG(xe, args->reserved[0] || args->reserved[1] ||
                     args->reserved[2] || args->pad))
    return -EINVAL;
```

**Unnecessary identity functions**: `xe_to_user_fault_type()` and `xe_to_user_fault_level()` are pure identity functions that just return their argument. While the comment says the mapping is "approximately 1-to-1", having two no-op functions adds clutter. If these are placeholders for future divergence, a brief comment on each would be more useful than the wrapping functions.

**`fill_faults` copies full `args->size` even if fewer faults exist**: If between the size check in `xe_vm_get_property_helper` and the iteration in `fill_faults`, the number of faults hasn't changed, this is fine because `kcalloc` zeroes the buffer. But the `copy_to_user` at line 1206 always copies `args->size` bytes regardless of how many entries `i` were actually populated. It would be cleaner to copy `i * entry_size` bytes instead of `args->size`, and update `args->size` to reflect what was actually copied.

**Race between size query and data fetch**: The two-call pattern (first call to get size, second to get data) is inherently racy since faults can be added between calls. The code handles this correctly by clamping in `xe_vm_get_property_helper` (`args->size > size` returns `-EINVAL`). However, this means userspace can get `-EINVAL` in a legitimate scenario where faults were cleared/reduced between the two calls. Since faults currently only accumulate (never cleared), this particular race doesn't manifest in practice, but it's worth considering for robustness if a clear mechanism is added later.

**Minor**: The `struct xe_vm_fault fault_entry = { 0 }` initialization at line 1177 should be `= {}` (standard C designated initializer) or `memset`, though `= { 0 }` is widely used in the kernel.

---
Generated by Claude Code Patch Reviewer