On Thu, 12 Jul 2007, Eric W. Biederman wrote: >> 2. Do not reserve memory for kexec kernel. That is, backup needed memory >> before kexec and restore them after kexec. >> 3. Support the in-place kexec? The relocatable kernel is not necessary >> if this can be implemented. > > It sounds like what you really want is the normal kexec path enhanced > so that you can return to the kernel you started with. > > The normal kexec path already knows how to do the memory shuffle so > it can do on demand memory allocation. That code just needs to > enhanced slightly so that you allocate an extra page, setup an inverse > scatter gather list for restoring the pages, and teach relocate_kernel.S > to preserve it's destination pages by using the inverse scatter gather > list. > > The normal kexec path already calls device_shutdown and the like to > stop devices from running. Although again that code path is not > prepared to restore the devices. we shouldn't need a restore code path if the new kernel re-detects everything. if kexec already shuts down all the devices we may not need to implement anything new here (although there may be room for future performance optimization) > ... > > For prototyping I would: > - reserve a chunk of memory (possibly with the crashkernel= option) > and run a relocatable kernel out of it. > > By using the normal kexec you can boot a relocatable restore kernel > in that reserved region. It is an extra step but it makes things > work today. > > - I would use the normal sys_kexec_load. > > - I would debug/tweak the user space and the code to reenter the > old kernel. I.e. the device driver stop/start code. > > Once it was basically working I would the update normal kexec > memory copy code in relocate.S to preserve the destination pages. for prototyping there's no need to use the same kernel. >> 4. Image writing/reading. (Only user space application is needed). > > And possibly a few fixes to /dev/mem. This is pretty much the same > process as generating a core dump so there should be some synergy with that. what fixes are you thinking of? you are makeing this sound very simple ;-) David Lang
