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

[Michael Ellerman]

Hi Will,

On Fri, 26 Aug 2005 23:53, will schmidt wrote:
> Hi Michael,
>       first question is inline, the other question..  when the
> KDUMP_CAPTURE_KERNEL is configured, is it only mapped into memory ahead
> of time, or would functions like this one (setup_kdump_trampoline) be
> run during normal system start?

I'm not sure what you mean there. The idea is that the first kernel will load 
the second kernel into memory at 32 MB, then when the first kernel crashes it 
passes control to the second kernel which begins running. In the process of 
starting up, the second kernel will backup the first 0x8000 bytes of the 
first kernel, and then call setup_kdump_trampoline().

> > + /* XXX this only works if PHYSICAL_START <= 32 MB */
> > +
> > + 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));
> > + }

Stephen is right, this code definitely needs a comment, I just hadn't got 
around to it yet.

> So here we're replacing the exception code in the first kernel, with
> pointers to the exception code in the second, right?  once this runs we
> end up with code something like...
>
> c0000000 00000100: 60 00 00 00   nop
> c0000000 00000108:      48 00 xx xx   b  (PHYSICAL_START -1)
> c0000000 00000110: 60 00 00 00   nop
> c0000000 00000118:      48 00 xx xx   b  (PHYSICAL_START -1)
> c0000000 00000120: 60 00 00 00   nop
> c0000000 00000128:      48 00 xx xx   b  (PHYSICAL_START -1)
> ...
>
> Is this the intent, or should there be a +i somewhere in the branch
> instruction too?

Almost. 0x48000000 is a "b" instruction, not "ba". So the disassembly looks 
like this:

c000000000000100  60000000      nop
c000000000000104  49fffffc      b       c000000002000100
c000000000000108  60000000      nop
c00000000000010c  49fffffc      b       c000000002000108
c000000000000110  60000000      nop
c000000000000114  49fffffc      b       c000000002000110
c000000000000118  60000000      nop
c00000000000011c  49fffffc      b       c000000002000118

That is we're branching to (32 MB - 4) + current address. [it's - 4 because of 
the mask (0x03ffffffc)]

We'd like to just branch to current address + 32 MB, but we don't have enough 
bits in the branch instruction for that, hence we need a nop at 0x100, then 
at 0x104 we jump to 0x104 + 32 MB - 4 = 0x100 + 32 MB.

Hope that makes sense.

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/20050829/1ac705a3/attachment.pgp