On Friday 23 September 2016 10:14 AM, Aneesh Kumar K.V wrote:
Hari Bathini <hbath...@linux.vnet.ibm.com> writes:

Hi Aneesh,

On Thursday 22 September 2016 09:54 PM, Aneesh Kumar K.V wrote:
Hari Bathini <hbath...@linux.vnet.ibm.com> writes:

The kernel now supports both radix and hash MMU modes. Tools like crash
and makedumpfile need to know the current MMU mode the kernel is using,
to debug/analyze it.  The current MMU mode depends on hardware support
and also whether disable_radix cmdline parameter is passed to the kernel.
The mmu_features member of cpu_spec structure holds the current MMU mode
a cpu is using. But the above mentioned tools need to know the MMU mode
early in their init process, when they may not have access to offset info
of structure members. A hard-coded offset may help but it won't be robust.
IIUC, you walk the linux page table and that should be more or less same
Taking the case of crash tool, vmemmap start value is currently
hard-coded to 0xf000000000000000UL but it changed to
0xc00a000000000000UL in case of radix.
All of that is already defined as variables in the kernel. You can look at

between radix/hash right except few bits. Now what crash will be
interested in will be the RPN part of the table which should be same
between hash/radix.
Though the walk is pretty much the same, the tool still needs to know
the right index values and vmemmap start to use, as they are different
for radix and hash..

This patch introduces a new global variable, which holds the current MMU
mode the kernel is running in and can be accessed by tools early in thier
init process,
Init process of what ? kernel or crash tool ?
tool initialization - crash or makedumpfile..

helping tools to initialize accurately for each MMU mode.
This patch also optimizes the radix_enabled() function call.

how do you differentiate between the hold linux page table format and
the new ? Can you also summarize what crash tool look for in the page
table ?
It needs the index sizes, masked bit values and page flag info to
do the page table walk. Since they can be different for hash and

Can you look at radix__early_init_mmu/hash__early_init_mmu and see you
can work with the variables defined there ?

Did consider that but didn't opt for it for a few reasons:

1. Will still need to know the MMU mode as huge page address translation
   is not the same for radix & hash.

2. Will have to get all these values from a crashed kernel when I can set them
   based on MMU mode. Less dependence on the failed kernel, the better..

3. Stash more variables in vmcoreinfo (for makedumpfile) when one is sufficient
   to serve the purpose.


Reply via email to