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

[Dave Anderson]

Badari Pulavarty wrote:

> On Wed, 2005-11-09 at 08:45 -0500, Dave Anderson wrote:
> > Haren Myneni wrote:
> > >
> > >
> > > crash-utility-bounces at redhat.com wrote on 11/08/2005 02:54:33 PM:
> > >
> > > > On Tue, 2005-11-08 at 17:32 -0500, Dave Anderson wrote:
> > > > > Badari Pulavarty wrote:
> > > > >
> > > > > > On Tue, 2005-11-08 at 14:42 -0500, Dave Anderson wrote:
> > > > > > > Badari Pulavarty wrote:
> > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Yep. You are right, those pages are not mapped. Initially
> > > > > > > > I thought that was the case, but I wasn't really sure if
> > > it
> > > > > > > > can happen with segments from shared libraries. (since
> > > > > > > > the routine which is telling its not mapped involves
> > > > > > > > going through my code).
> > > > > > > >
> > > > > > > > Anyway, I verified this on x86-64 machine also - I do
> > > > > > > > get "read" error and those pages are not mapped.
> > > > > > > >
> > > > > > > > I guess, my changes are good :)
> > > > > > > >
> > > > > > > > Haren, can you review them ?
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > > Badari
> > > > > > > >
> > > > > > >
> > > > > > > The patch looks just fine to me -- the only minor things to
> > > > > > > add is a dump of the VM_ORIG/VM_4_LEVEL bits in
> > > > > > > the ppc64_dump_machdep_table() debug function, and
> > > > > > > although the "pud_clear_bad" is in all probability quite
> > > > > > > suitable as a qualifier, it's probably also worth adding
> > > > > > > an optional "--machdep vm=xxx" command line argument
> > > > > > > like I put in place for the x86_64 equivalent.  Just to
> > > cover
> > > > > > > our collective arse...
> > > > > > >
> > > > > > > Anyway, upon Haren's blessing, it's good to go.
> > > > > > >
> > > > > > > Again -- really nice work!
> > > > > >
> > > > > > Okay, made recommended changes.
> > > > > >
> > > > > > I still need to figure out a decent symbol to identify
> > > > > > 4-level pagetable layout. I am looking through "nm -Bn".
> > > > > > I still can't find a decent one. (has to be some symbol
> > > > > > added for 2.6.14).
> > > > > >
> > > > > > Any ideas ?
> > > > > >
> > > > >
> > > > > If you can google out the wholesale patch that introduced the
> > > > > 4-level pagetable support, you might find something added
> > > > > or removed?  That's what I did for the x86_64 qualifier.
> > > > >
> > > >
> > > > Okay. I found new structure "pgtable_cache" got added along
> > > > with 4-level pagetable changes. I am using that symbol now.
> > > >
> > > > Thanks,
> > > > Badari
> > > >
> > > Badari, Thanks a lot for helping us on PPC64.
> > >
> > > Dave, Is it a problem if we use Linux version to determine 4-level
> > > page table changes instead of looking for some symbol which might
> > > get changed later. We need to make some more changes for 64K page
> > > support added in 2.6.14-git11.
> > >
> > >
> > Maybe -- maybe not...
> >
> > 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.
>
> Yes. You are right. I verified that THIS_KERNEL_VERSION is not
> set at PRE_GDB time.
>
> What I am not sure is, how late we can push finding out
> if we have 4-level pagetables are not and still make
> crash function.
>

Ideally before the first readmem().  But like I mentioned above, with
ppc64, it looks like it would be possible to get away with unity-mapped
readmem()'s for quite a bit longer without having your VM patch to
ppc64_init(PRE_GDB) in place, because all you really need
is machdep->kvbase initialized.  You could run a little test by *not*
intializing machdep->ptrs_per_pgd at all, and just seeing how far
it goes.

Dave