Oh, that was actually not what I thought of. The idea was to use the VM PDs root reservation object to allocate the trap handler and so simplify the handling. Moving that into the amdgpu_vm structure was not part of this plan. It's not really a page table and so probably better suited in fpriv after all. On the other hand we want to modify it through the VM IOCTLs and so making it part of the VM is probably not so bad. I need to think about that a bit more when I have time.

Hi Christian,

Good Morning!

Thanks for your feed backs and reviews, No rush, but when you have some free time, Just a quick follow up on the trap object ownership discussion.

My thinking was that the trap state is tied to the GPUVM mappings (TBA/TMA), and queues using the same GPUVM share the same trap state. Since the control path is also moving through the VM ioctl interface, keeping the trap object in amdgpu_vm felt natural to me.

However, I'm happy to follow whichever approach you think is best in the long term.

Thanks, Srini