Claude review: drm/xe/vm: Add srcid to xe_vm_get_property_ioctl fault report

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

Patch Review

**Issue 1 (Bug): `pad` validation removed from `drm_xe_vm_get_property`**

The patch removes the `args->pad` check from the ioctl input validation:

```c
// Before:
if (XE_IOCTL_DBG(xe, (args->reserved[0] || args->reserved[1] ||
                      args->reserved[2] || args->extensions ||
                      args->pad)))

// After:
if (XE_IOCTL_DBG(xe, (args->reserved[0] || args->reserved[1] ||
                      args->reserved[2] || args->extensions)))
```

The `pad` field in `struct drm_xe_vm_get_property` (`xe_drm.h:1344`) still exists and is still documented as MBZ. This removal is unrelated to the srcid feature — the srcid change is in `struct xe_vm_fault`, a completely different struct. Dropping this validation means userspace can now pass garbage in the `pad` field without error, which prevents using that field for future extensions (since old kernels would silently accept non-zero values). This looks like an accidental change and should be reverted.

**Issue 2 (Minor): `xe_to_user_srcid` is a pure identity function**

```c
static u8 xe_to_user_srcid(u8 srcid)
{
	return srcid;
}
```

This follows the pattern of `xe_to_user_fault_type` and `xe_to_user_fault_level` (which are also identity functions), so it's consistent. However, the comment at `xe_vm.c:4091` explains these exist to map "from current bspec specification to user spec abstraction." If there's no planned translation for srcid, this is unnecessary indirection. This is a style nit — acceptable if the convention is to have one per field for future-proofing.

**Issue 3 (UAPI documentation gap): No `#define` constants for srcid values**

The other fields in `struct xe_vm_fault` all have `#define` constants documenting their valid values:

```c
#define FAULT_ACCESS_TYPE_READ    0
#define FAULT_ACCESS_TYPE_WRITE   1
...
#define FAULT_LEVEL_PTE           0
#define FAULT_LEVEL_PDE           1
...
```

The new `srcid` field has no such documentation. Userspace receives a raw hardware register value with no guidance on interpretation. At minimum, the UAPI header should note that these are hardware-defined source IDs, or provide defines for known values. Without this, the field is opaque to userspace consumers.

**Correctness items that are fine:**
- `xe_vm_fault_entry` gains `srcid` at the right place and it's populated in `xe_vm_add_fault_entry_pf`.
- The UAPI struct `xe_vm_fault` repurposes `pad` → `srcid` — since this is an output-only struct (kernel fills it, copies to user), old userspace just sees a previously-zero byte now carrying data, which is safe. New userspace on old kernels sees `srcid=0`, which is harmless.
- The `fill_faults` function correctly converts and copies the field.

---
Generated by Claude Code Patch Reviewer