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.
Christian.
Compage the 2 values if they are the same then the GPU is looking where
you wanted it to look. If they are different then you know you have a bug
knowing the physical page addres do not give you any more informations
here ?
Jérôme
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
