----- 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.
Thanks,
Dave
--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility
