On Wed, Aug 02, 2017 at 07:23:58PM +0200, Christian König wrote: > Am 02.08.2017 um 19:13 schrieb Jerome Glisse: > > On Wed, Aug 02, 2017 at 07:05:11PM +0200, Christian König wrote: > > > Am 02.08.2017 um 18:43 schrieb Jerome Glisse: > > > > On Wed, Aug 02, 2017 at 10:26:40AM +0200, Christian König wrote: > > > > > [SNIP] > > > > So to summarize you are saying you do not trust the value you get from > > > > pci_map_page() ? > > > Well, what we don't trust is that we actually get this value correctly > > > into > > > our page tables. > > > > > > > If not then i stress again that you have all the informations you need > > > > inside the amdgpu driver. You can take the same scheme i propose to > > > > dump ttm.dma_address[] and compare against content of GPU page table. > > > Yes, exactly. But then again we have the mapping page to dma-address > > > (because that is what drivers usually need), but what we need for > > > debugging > > > is a map with the info dma-address to page. > > Why would you need the reverse ? You have a GPU virtual address do the > > following: > > GPU vaddr -> GPU page table entrie -> bus address > > GPU vaddr -> bo_va_mapping -> bo_va -> bo -> page -> dma/bus address > > First of all the VM housekeeping structures keep the state as it is supposed > to be on the next command submission and so the top of the pipeline, but the > state of the page tables represent to bottom of the pipeline. > > Second you can't access the BO from it's virtual address, the BO mapping is > protected by the BO reservation lock. So when I want to lockup the BO I > would need to lock the BO first - chicken and egg problem. That is of course > solvable, but not something I would really like to do for a debugging > feature.
Tom said that the GPU is stop and thus there is nothing happening to the vm nor any of the bo right ? So there is no need to protect anything. If you still allow thing to change vm (map/unmap bo ...) how do you expect to debug ? Jérôme _______________________________________________ iommu mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/iommu
