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.
