On Fri, Sep 07, 2018 at 03:21:10PM -0700, Dengcheng Zhu wrote: > Hi Paul, > > > > The problem is that the "only CPU0 will use reboot_code_buffer" part > isn't true because CPU0 might not be the one that writes to it. > > [Dengcheng]: I didn't say CPU0 is always the one running machine_kexec(). > Actually, in my testing, I intentionally did something like: > > taskset -c 3 echo c > /proc/sysrq-trigger Well, if CPU 0 isn't running machine_kexec() then some other CPU is doing the write to reboot_code_buffer and therefore CPU 0 isn't the only one accessing/using it. As I walked through in an earlier email, the safe way for this to happen is for the machine_kexec() CPU to write back its dcache as far as needed for a remote CPU's icache to observe the stores. Having CPU 0 be the only one to do any cache maintenance will not achieve that. As I mentioned before, if you're testing on I6x00 then you probably got away with it because the icache fills from the dcache. You'd probably also get away with having CPU 0 be the only one to do cache maintenance since the CM globalizes hit cache ops. But not all MIPS CPUs would be so lucky. > And for "either halted or powered down", do you have any idea/plan for > Octeon, Loognson and bmips? Well like I said before if we add a callback to struct plat_smp_ops to stop other CPUs, at least in the crash case, then we can check that & refuse to kexec() on systems that haven't implemented it. Octeon right now has kexec, so any changes like this should bring Octeon along for the ride by implementing the new callback there. Loongson has a patch pending [1] so that should probably be taken into account too. bmips would just be left alone, and wouldn't support kexec until someone implements the new callback. [1] https://patchwork.linux-mips.org/patch/20432/ Thanks, Paul
