[PATCH 13/26] RFC drm/xe/eudebug: userptr vm pread/pwrite
Christian König
christian.koenig at amd.com
Wed Jan 29 10:33:52 UTC 2025
Am 29.01.25 um 09:03 schrieb Joonas Lahtinen:
> Quoting Christian König (2024-12-20 14:56:14)
>> Am 20.12.24 um 12:31 schrieb Mika Kuoppala:
>>> Implement debugger vm access for userptrs.
>>>
>>> When bind is done, take ref to current task so that
>>> we know from which vm the address was bound. Then during
>>> debugger pread/pwrite we use this target task as
>>> parameter to access the debuggee vm with access_process_vm().
>>>
>>> This is based on suggestions from Thomas, Joonas and Simona.
>> Yeah that looks much saner to me. I still have a couple of comments on
>> the general approach, but I'm going to write that up after my vacation.
> I see you've had some issues with mail servers, so just pinging here to
> see if any replies have got lost.
No, I'm just overworked and have like 10 things I need to take care of
at the same time :(
> Would be great to reach a consensus on the high level details before
> spinning off further series addressing the smaller items.
I would say that attaching debug metadata to the GPU VMA doesn't look
like the best design, but if you just do that inside XE it won't affect
any other part of the kernel.
My other concern I have is using ptrace_may_access, I would still try to
avoid that.
What if you first grab the DRM render node file descriptor which
represents the GPU address space you want to debug with pidfd_getfd()
and then either create the eudebug file descriptor from an IOCTL or
implement the necessary IOCTLs on the DRM render node directly?
That would make it unnecessary to export ptrace_may_access.
Regards,
Christian.
>
> Regards, Joonas
>
>> Regards,
>> Christian.
More information about the dri-devel
mailing list