[PATCH 10/12] ppc64: Reroute interrupts from zero + offset to KERNELBASE + offset

[Milton Miller]

[Again, sorry for broken threading]

Michael Ellerman wrote:
> On Tue, 30 Aug 2005 15:41, Milton D. Miller II wrote:
> > > From michael at ellerman.id.au  Fri Aug 26 12:53:31 2005
> > > We also need to reserve the low pages of memory in prom.c, as well 
> as
> > > __pa(KERNELBASE) to __pa(klimit).
> > >
> > > FIXME, 0x8000 should be a #define.
> >
> > Actually we should reserve 0 to __pa(KERNELBASE) for testing kdump
> > environment...
>
> Why's that?

because kdump won't let us use those pages?  (I did say kdump, not
just !0 KERNELBASE).  And it hides the problem of 0x8000 :)

>
> > Do we work if the reserve of low memory is not part of the mem= ?
> > In kdump, this memory will not be part of the "mem=" line passed to
> > the capture kernel.
>
> Not quite sure what you mean here? I was thinking the second kernel 
> would
> detect it's memory constraints via the device tree (crashk_start etc). 
> rather
> than by using mem=. Although I guess either could work, and perhaps 
> mem= is
> better - less custom KDUMP code.

Actually I like this idea, although I'm not quite sure of the best
approach to do this.   Some of the things to watch for:

1) We probably want to create the linear mapping in the hash
table for all physically present memory, so that a read() on
/dev/mem works.

2) However, we want the total low memory etc in the node to reflect
the memory that the kdump kernel is allowed to manage so we get
various dynamically sized structures right (inode hash, tcp hashes,
etc).

I think this will be key in getting a working dump of a large
memory machine.

>
> > Why is it 0x8000 for the reserve and 0x3000 for the trampoline?
> > Do we know what we expect the trampoline will save?
>
> The trampoline is only for vectors, so up to 0x3000. The reserve 
> includes the
> fwnmi data area and basically everything in head.S


Yes, but this needs to be less magic.

>
> > page 9  is the initial stab (for RS64 and POWER3), or are you using
> > the new rearranged low memory patch?
>
> Yeah I'm using David's patches, so 0x8000 is the top of the important 
> bits in
> head.S

I didn't see that listed as a prereq :)

>
> > > +#ifdef CONFIG_KDUMP_CAPTURE_KERNEL
> > > +static void setup_kdump_trampoline(void)
> > > +{
> > > + unsigned long i;
> > > + unsigned int *addr;
> > > +
> > > + /* XXX this only works if PHYSICAL_START <= 32 MB */
> >
> > how about an #error ?
>
> Yep, just hadn't got to it yet. I think I saw some "BUILD_BUG" macro
> somewhere, or am I mad.

I thought so too but couldn't locate it quickly, so wasn't sure if
it was still just proposed or actually merged.

>
> > > +
> > > + for (i = 0x100; i < 0x3000; i += 8) {
> > > +  addr  = (unsigned int *)i;
> > > +  *addr++ = 0x60000000; /* nop */
> > > +  *addr = 0x48000000 | ((PHYSICAL_START - 1) & 0x03fffffc);
> > > +
> > > +  asm ("dcbst 0,%0; sync; icbi 0,%0; isync" : : "r" (addr));
> >
> > every 8 bytes is a bit overkill, but ok.   The -1 should be -4, its 
> the
> > instruction target..
>
> Well yeah, it could probably be 0x100, but this way any new vectors 
> that get
> added at weird places will also be caught. It is - 4 because of the 
> mask, but
> I guess actually having "- 4" would be clearer.

Yea, well, it used to be 0x100, then 0x80, and altivec has 0x20, and
another has one at 0x50 so every 10 vs every 8 ...

The other option is zero fill and put in the ones we actually support.
That way anything else will go to 0x700.

>
> > Others have commented on the comments for the patching.   The
> > trick of doing a nop to extend the range to 32k should be
> > explicitly stated.
>
> Yep it's ugly. I think I'll make a macro for it, we synthesise 
> branches in a
> few places.
>
> > Another approach is to copy pages 0-3 down to pages 0-3 and execute 
> the
> > copy there.  It does mean that we can't use relative branchs from 
> there
> > to the "main" kernel.
>
> Yeah I thought about that. But we'd have to link head.S differently, 
> somehow,
> and given that most of the code in head.S is happy to be at 32 MB I 
> decided
> the trampoline was an easier option.

Since head.S is assembly, we couuld just be careful about what
we put in there, making sure it is relocatable code. ...

Maybe a comment that this is an option, maybe just this discussion.
I was still debating which way to go when you took over.

Any reason you are choosing 32M instead of 16M ?   Other than it
is the limit, of course.  I don't know what size others have, my
kernel with its drivers is somewhere around 9M.  I guess 16 could
be tight for some.

milton