[Crash-utility] crash-4.0.2.12 PPC64 changes to make it understand64k pagesize

[Badari Pulavarty]

On Thu, 2005-11-17 at 13:18 -0800, Haren Myneni wrote:
> 
> 
> crash-utility-bounces at 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