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

[Haren Myneni]

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?
>
>  
>
>>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.
>
>  
>
Milton,

At present, the capture kernel base will be fixed at 32MB. Hence, 'mem=' 
option can be used. However, once we have fully relocatable kernel (PIC) 
support later, new options 'memmap=X at Y/exactmap' are needed or able to 
detect memory values from the device tree (crash_kernel_start and 
crash_kernel_end) as Michael pointed out.  Now, kexec-tools passes 
'memmap='  option to the second kernel since already supported on i386. 
I think, it will be better to have same interfaces even though only 
kdump is using them now.

Thanks
Haren


>>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
>
>  
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Linuxppc64-dev mailing list
>Linuxppc64-dev at ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc64-dev
>  
>