[PATCH 0/8] powerpc: Kexec fixups and support for booting at 32MB

[Milton Miller]

On Nov 16, 2005, at 6:07 PM, Michael Ellerman wrote:

> On Tue, 15 Nov 2005 05:23, Milton Miller wrote:
>> PS: Please copy me on kexec/kdump ppc patches so I can reply with
>> references.  I read the lists from the web.

>> [PATCH 1/8] powerpc: Turn cpu_irq_down into kexec_cpu_down
>
> Paul has already merged this so you can fix it up later if you want. 
> It fixes
> bugs so we need it now rather than later.

Ok so one for the list (along with ppc32 kexec comments)

> [PATCH 5/8] powerpc: Add CONFIG_CRASH_DUMP
>> [PATCH 6/8] powerpc: Reroute interrupts from 0 + offset to
>> PHYSICAL_START + offset
>>
>> The following should be in user space / device tree:
>> +#ifdef CONFIG_CRASH_DUMP
>> +       lmb_reserve(0, KDUMP_BACKUP_LIMIT);
>> +#endif
>
> I disagree. It's a PPC64 implementation detail that we have to fiddle 
> with
> stuff at 0, as far as userspace is concerned the kdump kernel is at 32 
> MB and
> up. If we require kexec-tools to do this, we'll have to keep the shape 
> of
> head.S in sync with kexec-tools.

It's a PowerPC thing that we fiddle with the first 3 pages and that is
well defined.  It is a kdump thing that the kernel is at 32M, so it
should reserve 0-32M if it wants that reserved.  The kernel can touch
reserved memory.   This is based on a discussion I had with Haren
that the memory given to the kernel would be 0-crash_kernel_end but
the 0-32M would be reserved.  I guess there is a correctness issue
if the first 3 pages (4, since we need fwnmi) are not reserved, but 
reserving beyond that to KDUMP_BACKUP_LIMIT is arbitrary.

In other words, in a pure first-boot high-kernel case, these pages
couuld be used as normal pages.  The hands-off part is because it
is dumping the previous kernel.



> [PATCH 7/8] powerpc: Create a trampoline for the fwnmi vectors
>> I totally disagree with this one, espically reregitering with
>> the low address in the trampoline.  The registration should be at
>> the new address.  And a1, a2 are very generic names.
>
> I'm not sure which bit you disagree with? We have to use a trampoline, 
> the
> addresses we pass to firmware must be < 32MB (see PAPR).
> I've changed the names.

I missed the requirement, and thought this was "register at the
same place as last time" patch.   I'll withdraw the objection,
although a comment to this requirement would be nice.

>> (2) The secondary hold code could be done as a 64 bit load in the
>> first 0x100 bytes vs LOADADDR
>
> Hmmm, not sure what you mean?

Alternative implementation option: vs LOAD_ADDR(label) do
t:	.llong <label>
and

	ld	4,t at l(0)

Again, just an option to consider, current code is ok, although it
takes more space and instructions.  (This technique requires t to
be in the first 2 cache lines so it will be copied down).

milton