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

[Suzuki K. Poulose]

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>



Thanks

Suzuki