Re: [Crash-utility] [PATCH v3 0/3] vmalloc translation support for PPC

----- Original Message ----- > On 02/15/2012 10:56 AM, Suzuki K. Poulose wrote: >> On 02/13/2012 10:17 PM, Dave Anderson wrote: >>> >>> ----- Original Message ----- >>>> The following series implements : >>>> >>>> * An infrastructure for platform based vmalloc translation for >>>> PPC32 >>>> * vmalloc translation support for PPC44x >>>> >>>> Changes since V2: >>>> >>>> * Rebased to crash-6.0.3 >>>> * Maintains a list of probe functions, rather than platform >>>> definitions. >>>> >>>> >>>> Each platform can define their own probe_function which would get >>>> the name of the >>>> ppc platform (read from kernel) and the probe can check if the >>>> platform is one of its >>>> variant. The probe function can then update the 'platform' >>>> defintions for the virtual >>>> address translation. >>>> >>>> If none of the defined platforms match, falls back to using the >>>> default PPC32 >>>> definitions. >>>> >>>> --- >>>> >>>> Suzuki K. Poulose (3): >>>> [ppc] virtual address translation bits for PPC44x >>>> [ppc] Support for platform based Virtual address translation >>>> [ppc] Non-linear address translation routine >>> >>> Hi Suzuki, >>> >>> I'll defer the technical ACK to Toshi, but I do have a couple of >>> other suggestions. >>> >>> Here's a sample vmalloc translation: >>> >>> crash> vtop d1180000 >>> VIRTUAL PHYSICAL >>> d1180000 ff800000 >>> >>> Using ppc440gp board definitions: >>> PAGE DIRECTORY: c056f000 >>> PGD: c0570a20 => c784b000 >>> PMD: c784b000 => c784bc00 >>> PTE: c784bc00 => 1ff80051b >>> PAGE: ff800000 >>> >>> PTE PHYSICAL FLAGS >>> ff80051b ff800000 (PRESENT|USER|GUARDED|COHERENT|ACCESSED) >>> >>> PAGE PHYSICAL MAPPING INDEX CNT FLAGS >>> crash> >>> >>> This may have been a pre-existing issue, but for vmalloc >>> addresses, the >>> page struct translation at the end of the display (under PAGE >>> PHYSICAL MAPPING...) >>> is missing for vmalloc addresses. For user-space and unity-mapped >>> addresses the translation is done as intended: >>> >>> User-space: >>> >>> crash> vtop ff8f000 >>> VIRTUAL PHYSICAL >>> ff8f000 6b90000 >>> >>> Using ppc440gp board definitions: >>> PAGE DIRECTORY: c7a3a000 >>> PGD: c7a3a1fc => c7bfc000 >>> PMD: c7bfc000 => c7bfcc78 >>> PTE: c7bfcc78 => 6b9005b >>> PAGE: 6b90000 >>> >>> PTE PHYSICAL FLAGS >>> 6b9005b 6b90000 (PRESENT|USER|GUARDED|COHERENT|WRITETHRU) >>> >>> VMA START END FLAGS FILE >>> c7b09898 ff8f000 ff92000 100073 >>> >>> PAGE PHYSICAL MAPPING INDEX CNT FLAGS >>> c06b5200 6b90000 c7a9fc61 ff8f 1 80068 >>> crash> >>> >>> Kernel unity-mapped: >>> >>> crash> vtop c7b14000 >>> VIRTUAL PHYSICAL >>> c7b14000 7b14000 >>> >>> Using ppc440gp board definitions: >>> PAGE DIRECTORY: c056f000 >>> PGD: c05708f4 => 0 >>> >>> PAGE PHYSICAL MAPPING INDEX CNT FLAGS >>> c06d4280 7b14000 0 0 1 0 >>> crash> >>> >>> That should be a trivial fix. >> >> I took a look at the above issue of vtop report and here is what >> I find : >> >> crash> p *vmlist >> $17 = { >> next = 0xc784e880, >> addr = 0xd1002000, >> size = 8192, >> flags = 1, >> pages = 0x0, >> nr_pages = 0, >> phys_addr = 8837398528, >> caller = 0xc042bf40 >> } >> crash> vtop 0xd1002000 >> VIRTUAL PHYSICAL >> d1002000 ec00000 >> >> PAGE DIRECTORY: c0578000 >> PGD: c0579a20 => c784b000 >> PMD: c784b000 => c784b010 >> PTE: c784b010 => 20ec0051b >> PAGE: ec00000 >> >> PTE PHYSICAL FLAGS >> ec0051b ec00000 (PRESENT|USER|GUARDED|COHERENT|ACCESSED) >> >> PAGE PHYSICAL MAPPING INDEX CNT FLAGS >> >> crash> x /i vmlist->caller >> 0xc042bf40<setup_indirect_pci+84>: blr >> >> Here, the total amount for RAM on the machine is 128M and looks like >> the above address is memory mapped PCI bus, which lies above the 128M. >> Also note that the number of pages is '0'. Since the page lies above the >> 128M and the number of pages is 0, the dump_mem_map fails to find the page struct >> for the corresponding phsyical address. >> >> If we go further in the vmlist to find the vmalloc address pages that have pages, >> we get : >> >> crash> p *(vmlist->next->next->next) >> $16 = { >> next = 0xc78e51c0, >> addr = 0xd1008000, >> size = 8192, >> flags = 2, >> pages = 0xc7891680, >> nr_pages = 1, >> phys_addr = 0, >> caller = 0xc006a1d0 >> } >> crash> vtop 0xd1008000 >> VIRTUAL PHYSICAL >> d1008000 7896000 >> >> PAGE DIRECTORY: c0578000 >> PGD: c0579a20 => c784b000 >> PMD: c784b000 => c784b040 >> PTE: c784b040 => 789601f >> PAGE: 7896000 >> >> PTE PHYSICAL FLAGS >> 789601f 7896000 (PRESENT|USER|RW|GUARDED|COHERENT) >> >> PAGE PHYSICAL MAPPING INDEX CNT FLAGS >> c06d72c0 7896000 0 0 1 0 >> >> So, may be we could add a check in the vmalloc translation to see if there is really >> a page allocated for the block and then do the translation of the pages. > > I have a patch which could do something like: > > crash> vtop d1002000 > VIRTUAL PHYSICAL > d1002000 20ec00000 > > PAGE DIRECTORY: c0578000 > PGD: c0579a20 => c784b000 > PMD: c784b000 => c784b010 > PTE: c784b010 => 20ec0051b > PAGE: 20ec00000 > > PTE PHYSICAL FLAGS > 20ec0051b 20ec00000 (PRESENT|USER|GUARDED|COHERENT|ACCESSED) > > The memory 0x20ec00000 doesn't have a PFN associated with it. > It could be an MMIO region above the RAM(128 MB). > crash> Ah yes, I'm sorry Suzuike -- I forgot that can be seen on any architecture. Taking x86_64 as an example, it's seen by just looking at the first two entries on the vmlist: crash> kmem -v VM_STRUCT ADDRESS RANGE SIZE ffff88003f824f00 ffffc90000000000 - ffffc90000002000 8192 ffff88003f824a00 ffffc90000003000 - ffffc90000104000 1052672 ... [ cut ] ... The second vm_struct in the vmlist at ffff88003f824a00 shows that there are 256 pages associated with it: crash> vm_struct ffff88003f824a00 struct vm_struct { next = 0xffff88003f824980, addr = 0xffffc90000003000, size = 1052672, flags = 2, pages = 0xffff88003fae7000, nr_pages = 256, phys_addr = 0, caller = 0xffffffff818e426c } crash> and so for any vmalloc address within it, the page translation is displayed by vtop: crash> vtop ffffc90000003000 VIRTUAL PHYSICAL ffffc90000003000 3faed000 PML4 DIRECTORY: ffffffff81001000 PAGE DIRECTORY: 3faa5067 PUD: 3faa5000 => 3faa6067 PMD: 3faa6000 => 3faa7067 PTE: 3faa7018 => 800000003faed163 PAGE: 3faed000 PTE PHYSICAL FLAGS 800000003faed163 3faed000 (PRESENT|RW|ACCESSED|DIRTY|GLOBAL|NX) PAGE PHYSICAL MAPPING INDEX CNT FLAGS ffffea0000dee3d8 3faed000 0 0 1 20000000000000 crash> But the first entry in the vmlist at ffff88003f824f00 does not have any pages: crash> kmem -v VM_STRUCT ADDRESS RANGE SIZE ffff88003f824f00 ffffc90000000000 - ffffc90000002000 8192 ffff88003f824a00 ffffc90000003000 - ffffc90000104000 1052672 ... [ cut ] ... crash> vm_struct ffff88003f824f00 struct vm_struct { next = 0xffff88003f824a00, addr = 0xffffc90000000000, size = 8192, flags = 1, pages = 0x0, nr_pages = 0, phys_addr = 4275044352, caller = 0xffffffff818d5a66 } and so no page translation is shown: crash> vtop ffffc90000000000 VIRTUAL PHYSICAL ffffc90000000000 fed00000 PML4 DIRECTORY: ffffffff81001000 PAGE DIRECTORY: 3faa5067 PUD: 3faa5000 => 3faa6067 PMD: 3faa6000 => 3faa7067 PTE: 3faa7000 => 80000000fed00173 PAGE: fed00000 PTE PHYSICAL FLAGS 80000000fed00173 fed00000 (PRESENT|RW|PCD|ACCESSED|DIRTY|GLOBAL|NX) crash> So just do the same thing -- no verbose expanation is required.