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

[Michael Ellerman]

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?

> 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.

> 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

> 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

> > +#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.

> > +
> > + 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.

> 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.

cheers

-- 
Michael Ellerman
IBM OzLabs

email: michael:ellerman.id.au
inmsg: mpe:jabber.org
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)

We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://ozlabs.org/pipermail/linuxppc64-dev/attachments/20050830/24f7572a/attachment.pgp