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

[will schmidt]

Michael Ellerman wrote:
> 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().
> 

Ultimately, the question was _when_ does this code get invoked.   My 
concern was that we would always be running with the trampoline.  You've 
clarified this for me, so now I know. :-)

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

Yes, it does.   Thanks.

> 
> cheers
> 

-Will