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

[Dave Anderson]

----- 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.

Secondly, that "Using ppc440gp board definitions:" statement
stuck in the midst of the "vtop" output is not the place for it, 
except perhaps if it's enclosed with a CRASHDEBUG() qualifier.

That being said, it certainly is a useful piece of information,
and should be made available somewhere.

What I suggest is that you create a PPC "machine_specific" data
structure like the other architectures have, and which the global
machdep_table structure points to.  Then have it either contain,
or at least point to, your new base_platform structure, and
enhance ppc_dump_machdep_table() to dump its contents for the
"help -m" output.  

Furthermore, the board's name string seems worthy of display in
ppc_cmd_mach() for the "mach" command, don't you?

Thanks,
  Dave