On Thu, 2008-11-13 at 07:44 +1100, Benjamin Herrenschmidt wrote: > > Again, why can't we just stick something in the kernel code that > reserves the last page ? It could be in prom.c or it could be called by > affected 4xx platforms by the platform code, whatever, but the reserve > map isn't really meant for that and will not be passed over from kernel > to kernel by kexec.
Reserving a page is overkill; only the last 256 bytes are affected. We need to intercept at the LMB level, because allocations are already done there, so by the time we hit bootmem it's way too late. I simply don't see a good place to do this in the kernel. It would have to be before the first lmb_alloc() call, which for safety would put it inside early_init_devtree() -- along with the other lmb_reserve() calls.[1] However, ppc_md.probe() hasn't even been called yet, so there's no way of knowing if we're on an affected system, unless you want to add a special of_scan_flat_dt() call here. I'm open to suggestions, but I don't see a better way than what I already sent. I think the important part is to call lmb_add() for all memory, but lmb_reserve() the last 256 bytes before lmb_alloc() happens. It sounds like kexec must have some knowledge of the platform and device tree already, so is this really a big deal? At any rate, this conversation is somewhat academic, since there is no kexec on 44x... so maybe this can be re-addressed when that becomes a real issue. [1] This is exactly where flat device tree reservations are done, and that's why the patch I submitted works. -- Hollis Blanchard IBM Linux Technology Center _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev