* Kumar Gala | 2010-01-15 11:53:13 [-0600]: >On Jan 15, 2010, at 10:41 AM, Sebastian Andrzej Siewior wrote: > >> This is take two :) >> SMP support did not work in the first one and due to the lack of a working >> SMP machine it is still absent. I took the e500v1 problem into account and >> the result is that I now use multiple 256MiB mappings. >> The final mapping covers the first 2GiB so the part of the highmem should >> be also covered and not just kernel memory. >> >> The first three patches prepare the entry code to work outside of the >> first page. Patch 4 simply moves code and finally patch 5 implements the >> kexec functionality. > >What do you think we need for SMP support? I'm happy to test out on SMP HW >(8572) Depends on how we want to do it :) X86 for instance disables all "other" CPUs in machine_shutdown(). Therefore during machine_kexec() they are off and are bootstraped again during system boot. PPC64 doesn't do this that way. They call smp_call_function() witch puts the CPU into real mode and let them spin in a "save" state until they get released them from this state.
If we are able to disable the CPU and bootstrap it from scratch than I guess we could do the way x86 does it. If the CPU keeps the TLB/MMU data after reactivated (what I assume) than we have to do the same thing that ppc64 does: - let the other CPU have the also the identical mapping - spin in a save state in kernel, then purgatory. I guess I should revisit ppc64 code for details :) - update the device tree so kernel can kick the other CPU during boot. > >- k Sebastian _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
