Re: [patch] [RFC] Kexec on MIPS

[Ralf Baechle <ralf@linux-mips.org>]

On Wed, Oct 18, 2006 at 03:14:55PM +0200, Nicolas Schichan wrote:

> I have implemented kexec support for the mips architecture, the code is 
> available in the attached patch (for 2.6.18 kernel). This code works fine on 
> the mips boards I use at work (one in big endian and one in little endian) and 
> on qemu.

Cool!

> However it has not been tested on 64 bit mips and it may not work on
> those architectures.

Aside of a nit in a 32-bit specific comment the code is looking good.  See
below.

> It may also not work on machines with more than 512 megabytes as the kexec 
> generic code may fill the page list with adresses over the 512 megabytes 
> limit (the mips boards I use only have 16mbytes and 32mbytes ram).

This is only an issue with 32-bit software anyway.  On these you can solve
the problem by manually setting up TLB mappings.  You may want to take a
look at kmap_coherent in arch/mips/mm/init.c for how to create such
temporary mappings.

> A tiny userland application loading the kernel and invoking kexec_load for 
> mips is available here:
> 
> http://chac.le-poulpe.net/~nico/kexec/kexec-2006-10-18.tar.gz
> 
> Do not hesitate to comment on this patch,

Without having tested this, this actually looks quite fine for the first
cut.  My nits are these:

+       /*
+        * The generic kexec code builds a page list with physical
+        * addresses. they are directly accessible through KSEG0,
+        * hence the pys_to_virt() call.
+        */

On a 64-bit system this could actually be either an XKPHY or CKSEG address,
depending on PAGE_OFFSET.

+       /*
+        * we do not want to be bothered.
+        */
+       local_irq_disable();
+
+       flush_icache_range(reboot_code_buffer,
+                          reboot_code_buffer + KEXEC_CONTROL_CODE_SIZE);
+
+       printk("Will call new kernel at %08x\n", image->start);
+       printk("Bye ...\n");
+       flush_cache_all();
+       ((void (*)(void))reboot_code_buffer)();

On SMP systems cache flushes may invoke smp_call_function which will barf
when called with interrupts disabled.  So you may want to move the
local_irq_disable further down to somewhere after the last flush.

Your code does not try to deal with SMP at all.  The strategy used by
Linux to get hold of processors 1 and up on bootup relies on the
firmware.  Generally firmware breaks because Linux tramples over it and
even if it would survive that, it does not regain control over non-boot
processors, so starting of those processors would fail.

The solution I have in mind would be something like:

 * The trampoline that transfers control between the old and new kernel
   needs to be modified to keep all additional processors in some sort of
   spinlock.
 * A kernel needs a way to know if it has been executed via kexec or a
   normal bootup.  It uses this knowledge to release one non-boot
   processor after another during SMP initialization.

  Ralf

PS: If you have to send patches as attachments, then please as text/plain.