[Crash-utility] crash-4.0-2.10 ppc64 4-level pagetable fixes

[Badari Pulavarty]

On Wed, 2005-11-09 at 14:16 -0500, Dave Anderson wrote:
> Badari Pulavarty wrote:
> 
> > >
> > > It's kind of a chicken-and-egg situation, where the first readmem()
> > > needs the virtual address range stuff to be in place, but we need
> > > something out of the kernel data space to determine the virtual
> > > address space range data.  That being said, it looks possible, at
> > > least in the case of ppc64, that perhaps we could get away with
> > > doing a readmem() of a unity-mapped address, since at the
> > > point where the VM-range decision is made, machdep->kvbase
> > > has just been set.  (Follow the readmem() path, and you'll see
> > > what I mean...)  But you'd have to read raw data and muck
> > > your way through it because the embedded gdb hasn't been
> > > invoked yet.  Badari had asked the same thing earlier, about
> > > using the THIS_KERNEL_VERSION macro, but again, the
> > > underlying crash data to satisfy the macro doesn't get initialized
> > > until after gdb is alive.
> >
> > Okay. It looks like we can delay deciding 4-level pagetable layout
> > till POST_GDB stage. Since THIS_KERNEL_VERSION is set by then, I was
> > able to use that instead :)
> 
> Ok -- sorry, I'm so far behind in my mail, I answered your last query before
> I got to this one.  So doing it this late should be OK -- as long as there never
> becomes a requirement to access a vmalloc address data prior to that point.
> 
> One question -- if the 64k page support is put in place for 2.6.14, are you
> going to run into the same kind of "qualification" issue?

64k page support is going to be tricky. Atleast 4 level pagetable stuff
is default from 2.6.14 onwards. But 64k page support is not default, its
a config option. So, we can't base it on kernel version - it should be
based on really reading *something* in the kernel to find out if it
really is 64k pages and then switch to yet another page table layout :(


Thanks,
Badari