On Oct 22, 2008, at 10:43 PM, Paul Mackerras wrote: > Paul Mackerras writes: >> Milton Miller writes: >>> Move the flag to 0x5c, 1 word before the secondary cpu entry point at >>> 0x60. Use the copy at address 0 not the one in the base kernel >>> image to >>> make it easier on kexec-tools. >> >> Why is it easier on kexec-tools? Doesn't kexec-tools know where it >> put the kernel? The archictecture code calls cross-platform code to identify what is loaded. It isn't specified if this is a shared mmap or a read into a buffer. >> >> I'd much rather keep the flag inside the kdump kernel image, rather >> than having kexec/kdump start using random fixed locations outside the >> new kernel image. > > In fact the cliching argument is that when the kernel is loaded by OF > or yaboot, we have no way to tell what will be at location 0x5c, > whereas we know that the word at offset 0x5c in the kernel image will > have been initialized to 0. So we had better put the flag inside the > kernel image. Well, prom_init will copy the 256 bytes to 0 before the code checks that location. However, there is an arguement for using the same code from an epapr or book-e relocatable, and that would need it at 0. And today the kexec tool does not do a shared mmap. Since the change has been made, I will make a new patch for kexec-tools. milton
