From mboxrd@z Thu Jan 1 00:00:00 1970 From: Claude Code Review Bot To: dri-devel-reviews@example.com Subject: Claude review: drm/xe/vm: Add srcid to xe_vm_get_property_ioctl fault report Date: Thu, 04 Jun 2026 11:40:33 +1000 Message-ID: In-Reply-To: <20260603150828.3751112-3-jonathan.cavitt@intel.com> References: <20260603150828.3751112-1-jonathan.cavitt@intel.com> <20260603150828.3751112-3-jonathan.cavitt@intel.com> X-Mailer: Claude Code Patch Reviewer Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Patch Review **UAPI change:** The `__u8 pad` in `struct xe_vm_fault` is renamed to `__u8= srcid`. Since `pad` was MBZ and occupied the same offset, this is ABI-comp= atible =E2=80=94 old userspace that set pad=3D0 will just read srcid=3D0 (o= r whatever value is there), and old kernels receiving new userspace won't b= reak because the pad check was on the `drm_xe_vm_get_property` struct, not = on the `xe_vm_fault` struct itself. Looking at `xe_vm.c:4200-4202`, the pad check is on `args->pad` (the `drm_x= e_vm_get_property` struct's pad, not `xe_vm_fault`'s pad), so this is indee= d unaffected =E2=80=94 the cover letter's "Readd pad check" note correctly = identifies that the `drm_xe_vm_get_property.pad` check should remain. **Nit:** `xe_to_user_srcid()` is a trivial 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. I understand these exist as pl= aceholders for potential future remapping (similar to the XXX comment about= enum matching in `xe_guc_pagefault.c:74-76`), so this is consistent with t= he codebase style. The `xe_vm_fault_entry` struct addition and the `xe_vm_add_fault_entry_pf` = plumbing are both correct and straightforward. No blocking issues with this patch. --- Generated by Claude Code Patch Reviewer