[Crash-utility] [PATCH 0/5] [ppc32] update vtop

[Dave Anderson]

----- Original Message -----
> This patch update ppc32 vtop.
>  - Translate kvaddr for fsl-booke by using TLBCAM setting
>  - Remove PMD from display because virtual address bit is not assigned
>  - Fixup displayed PHYSICAL values of fsl-booke PTE format
>  - Fixup bug for page flags setup which I made previous patch
> 
> Updated command images are below.
> 
> - kvaddr can be translated by using TLBCAM
> 
> crash> sym powerpc_base_platform
> c0913024 (S) powerpc_base_platform
> crash> vtop c0913024
> VIRTUAL   PHYSICAL
> c0913024  913024
> 
> PAGE DIRECTORY: c08d1000
>   PGD: c08d2810 => 0
> 
>   TLBCAM[0]: MAS0     MAS1     MAS2     MAS3     MAS7
>              10000001 c0000900 c0000004 15       0
>              VIRTUAL RANGE : c0000000 - cfffffff
>              PHYSICAL RANGE: 0 - fffffff
>   => VIRTUAL  PHYSICAL TLBCAM-OFFSET
>      c0913024 913024   9515044
> 
>   PAGE     PHYSICAL   MAPPING    INDEX CNT FLAGS
> d0012260     913000         0         0  1 400
> 
> Next,
> - vtop won't display PMD
> - physical address is not equal to PTE
> - FLAGS can be handled well
> 
> crash> vtop -c 4145 10000000
> VIRTUAL   PHYSICAL
> 10000000  ef448000
> 
> PAGE DIRECTORY: e85c4000
>   PGD: e85c4200 => e873c000
>   PTE: e873c000 => ef44824020d
>  PAGE: ef448000
> 
>     PTE      PHYSICAL  FLAGS
> ef44824020d  ef448000  (PRESENT|USER|COHERENT|ACCESSED)
> 
>   VMA       START      END    FLAGS  FILE
> ea1d3960  10000000  10af9000 8001875  /tmp/toshi/crash
> 
> However, ... could not read vtop'd physical address data from /dev/mem now.
> 
> crash> rd -p ef448000
> rd: read error: physical address: ef448000  type: "32-bit PHYSADDR"
> 
> Although my environment tends to set higher PTE value,
> PFN is valid physical scope number, my maximum is 4GB.
> 
> crash> log | grep totalpages
> On node 0 totalpages: 1048576
> crash> eval 1048576
> hexadecimal: 100000  (1MB)
>     decimal: 1048576
>       octal: 4000000
>      binary: 00000000000100000000000000000000
> 
> Is there any constraint in "rd" or is my "/dev/mem" something wrong?
 
Yeah, it sounds like the /dev/mem "high_memory" constraint for 32-bit
architectures.  At the top of the kernel's read_mem() function, it calls
valid_phys_addr_range():

  static ssize_t read_mem(struct file *file, char __user *buf,
                          size_t count, loff_t *ppos)
  {
          unsigned long p = *ppos;
          ssize_t read, sz;
          char *ptr;

          if (!valid_phys_addr_range(p, count))
                  return -EFAULT;
  ...

which restricts physical memory access above "high_memory":

  static inline int valid_phys_addr_range(unsigned long addr, size_t count)
  {
          return addr + count <= __pa(high_memory);
  }

On a 32-bit machine (at least on x86), high_memory is going to be no higher
than (1GB-128MB) or 896MB, because it needs the upper 128MB of kernel
virtual address space for vmalloc() and FIXMAP-type addresses.

You might try using /proc/kcore instead of /dev/mem, although I can't 
recall if there would be other issues using it on a 32-bit architecture.
Enter "crash /proc/kcore" and see what happens...

Or try building the crash utility's "memory driver" kernel module that
comes with the crash sources:

  $ tar xvzmf crash-6.0.4.tar.gz
  ...
  $ cd crash-6.0.4/memory_driver
  $ make
  ...
  $ insmod crash.ko

Then, when invoking the crash utility on the live system, it will check
for the existence of the crash.ko module and use it instead of /dev/mem.
It does not have the high_memory restriction.

Dave