Claude review: drm/xe/uapi: Define drm_xe_vm_get_property

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

Patch Review

**uAPI naming concern: `struct xe_vm_fault` lacks `drm_xe_` prefix.** All other xe uAPI structs use `drm_xe_` prefix (e.g., `drm_xe_vm_bind`, `drm_xe_vm_get_property`). The `struct xe_vm_fault` should be `struct drm_xe_vm_fault` for consistency. Same for the `FAULT_*` defines — they are very generic namespace polluters and should have a `DRM_XE_` or similar prefix (e.g., `DRM_XE_FAULT_ACCESS_TYPE_READ`).

**Struct padding/alignment concern.** In `struct xe_vm_fault`:
```c
__u64 address;
__u32 address_precision;
__u8 access_type;
__u8 fault_type;
__u8 fault_level;
__u8 pad;
__u64 reserved[4];
```
The layout is fine from a padding perspective (4+1+1+1+1 = 8, aligns to the next `__u64`). Total size is 48 bytes, which is reasonable.

**The `data`/`value` union semantics are unusual.** The documentation says if `size` is 0, the driver fills in the required size. But there's also a `value` field for "scalar queries" — yet no scalar property is defined. This adds complexity for a hypothetical future use case. Not a blocker, but worth questioning whether the union is needed in v1 of this uAPI.

**Missing `pad` validation.** The ioctl handler in patch 4 checks `reserved[0..2]` but does not check `args->pad`. For uAPI, MBZ fields should be validated to ensure forward compatibility.

---
Generated by Claude Code Patch Reviewer