On Tue, Aug 01, 2017 at 06:07:48AM -0400, Tom St Denis wrote: > Hi, > > We're working on a user space debugger for AMDGPU devices and are trying to > figure out a "proper" way of taking mapped pages and converting them back to > physical addresses so the debugger can read memory that was sent to the GPU. > > The debugger largely operates at arms length from the application being > debugged so it has no knowledge of the buffers other than which PCI device > mapped it and the mapped address.
There is your issue, you should reconsider your design. You should add a debuging/tracing API to the amdgpu kernel driver that allow one process to snoop on another process buffers. It would be a lot more realistic user space interface. > > We also use the debugger to read back kernel programmed buffers (ring > buffers and the like) so we really need a kernel level solution. Not going to happen, this would be like /dev/mem on steroid and a big security risk. > > As a prototype I put a trace point in the AMDGPU driver when pci_map_page() > is called which preserves the physical and dma address and that works but > obviously is a bit of a hack and doesn't work if pages are mapped before the > trace is enabled. > > Ideally, some form of debugfs interface would be nice. > > Is there any sort of interface already I can take advantage of? I've tried > enabling the map/unmap tracepoints before loading amdgpu and it produced no > traffic in the trace file. I think you need to reconsider how to achieve your goal. It is a lot more sensefull to add new API to amdgpu driver than asking kernel to provide you with access to random physical memory. Jérôme _______________________________________________ iommu mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/iommu
