Re: [Crash-utility] crash-4.0.2.12 PPC64 changes to make it understand64k pagesize
On Thu, 2005-11-17 at 13:18 -0800, Haren Myneni wrote:
crash-utility-bounces(a)redhat.com wrote on 11/17/2005 12:56:01 PM:
> Badari Pulavarty wrote:
>
> > Hi Dave & Haren,
> >
> > Here are the changes I made to "crash" to function with PPC64
> > 64k pagesize. Instead of adding whole set of indexs, shifts,
> > masks, macros and new vtop() routines - I generalized 4-level
> > pagetable support and set & compute indexes, shift and masks
> > correctly for 4K and 64K.
> >
> > Tested with 4K pagesize and 64K pagesize kernels on PPC64.
> > Please review.
>
> The proof is in the pudding, so I trust that it all works and is
> backwards-compatible -- but to cover my own ass, I need you
> to positively confirm that it still works on RHEL3 and RHEL4
kernels.
Let me run crash tool on RHEL4 vmcore (I believe, I saved vmlinux and
vmcore created on RHEL4 kernel). Yes, it should support backward
compatible since we did not change the previous code patch even though
we should be having one vtop with the new approach. But, we will check
on previous vmcore or on live RHEL4 kernel.
No. We still we have 2 vtop() functions. One for old kernels (pre-4level
changes - which also works on 2.4 kernels). Other for kernels with
4-level pagetables, 64K page support.
I guess, make a single vtop() which works on all kernels: 2.4 kernels,
2.6 pre-level4 changes, 4-level pagetables changes, 64k pagesupport etc.
But I really don't have bandwidth to understand all the shifts and
masks, make changes to incorporate all of differences & back and test
every single one of them (I have no interest or time testing 2.4
kernels).
>
> One minor thing I can suggest, but I'll leave it up to you
> whether you want to add it. On all of the other architectures,
> their xxx_dump_machdep_table() functions will display the
> contents of the generic machdep_table structure followed
> by the contents of their attached machine_specific structure.
> The ppc64_dump_machdep_table() function just has the
> machspec pointer. When everything "just works", it's usually
> never needed, but I've found it invaluable when debugging new
> machine-specific stuff that comes along.
>
Yes, we will make changes.
> But it's your call... so when you and Haren are happy, just let
> me know.
Badari, Thanks a lot for doing this. This approach is useful to
support easily even for future changes. One minor comment, instead of
hardcoding in ppc64.c source file for 'm->l1_index_size = 9', can we
define INDEX macros in the header file and use them here. For
example, PTE_INDEX_SIZE_L4. I am thinking we can map/understand easily
to see what is l1 or l2. What do you think?
Yes. We can add INDEX macros if you like - but we will end up with 3
different sets of them: 2.4 kernels, 4-level pgtables, 64K pagesize.
Thanks,
Badari