Re: [PATCH 0/3 -mm] kexec jump -v8
On Sun, 2008-01-06 at 15:49 -0500, Vivek Goyal wrote: > > > Why should we exchange backup page map information between two kernels? > > > What data has been swapped and how to restore it back should be known > > > to the kernel who did it. I think the memory info and address of ELF > > > headers we can still pass to second kernel the same way we do for > > > /proc/vmcore. The only difference is that purgatory shall have to modify > > > the command line to reflect the new address of ELF headers just before > > > jumping to new kernel (because of swapping). > > > > > > We can also modify the actual ELF headers in purgatory to reflect the > > > right data (because of swapping) and new kernel will not have to know > > > anything about swapping. > > > [...] > > > In addition to revising the ELF headers in purgatory, the /proc/kimgcore > > interface can also be used to revise the ELF headers in kernel A. But > > this needs to export backup pages map information to user space (another > > sysfs/procfs file?). > > This is kind of two step load process. Load image, then export backup > page info to user space and then readjust the headers through > /proc/kimgcore. I think purgatory doing it is cleaner. [...] > > I think there may be no difference between two kinds of files. Nothing > > prevents hibernated image produced through /proc/vmcore loaded with > > normal kexec -l. I have just tested it. This means we need not use > > krestore to resume the hibernated kernel after enhancing /sbin/kexec > > (because it uses too much anonymous memory). And, the resuming process > > will be more smooth. > > > > Ok. So in a nutshell, any resumable image (be it is generated through > /proc/vmcore or /proc/kimgcore) can be launched in the same way (I think > kexec --load-preserve-context). ? > > In fact, if we are modifying the ELF headers in purgatory to reflect the > swapped page action, then we don't require /proc/kimgcore interface > at all? But, how can purgatory get the "backup pages map" information? Which is not available when purgatory is loaded. I think there are two methods: Method1: - A setup page is setup by original kernel, and the address of setup page is passed to purgatory using a pre-defined protocol (such as in a register). The "backup pages map" is in setup page. - Purgatory uses the information in setup page to modify ELF headers - kexeced kernel use ELF headers to build /proc/vmcore Method2: - A setup page is setup by /sbin/kexec - The "backup pages map" information is written to purgatory via /proc/kimgcore. - Purgatory uses the information to modify ELF headers - kexeced kernel use ELF headers to build /proc/vmcore But, why not just exchanging the "backup pages map" information between two kernels via the "setup page"? It is as follow: - A setup page is setup by original kernel, and the address of setup page is passed to kexeced kernel using a pre-defined protocol (such as in a register). The "backup pages map" is in setup page. - kexec kernel use "backup pages map" to build /proc/vmcore. To keep it simple, another choice is not passing this "backup pages map" information between two kernels now. The biggest issue is makedumpfile can not exclude free pages without it, resulting in big hibernated image. Another issue is that the information in /proc/vmcore is not accurate, but that does not affect the hibernation implementation. > In fact, if we are modifying the ELF headers in purgatory to reflect the > swapped page action, then we don't require /proc/kimgcore interface > at all? /proc/kimgcore is mainly used to save the memory image of the kexeced kernel. If this is not to be supported, /proc/kimgcore is not needed. But, I think this is useful to accelerate the hibernating (no another boot is needed for each hibernating). > > For completion (although may be not a big issue now): > > > > Whether using "krestore" or normal "kexec -l" depends on the memory used > > by current kernel (/proc/iomem) and memory in image file (PT_LOAD > > headers). If all memory in image file is outside memory used by current > > kernel, "krestore" should be used. If all memory in image file is inside > > memory used by current kernel, normal "kexec -l" should be used. If > > there is intersection set between memory in image file and memory of > > current kernel, the image file can not be loaded. > > > > I think kexec should mask that difference. A user should be able to load > a resumable image either by using "kexec -l" or "kexec > --load-preserve-context" depending on whether user wants to come back to > orignal kernel in future or not. Kexec-tools should recognize the image > as resumable. Any page outside the current kernel can be written to > final location through /dev/oldmem. And any pages which overlap with the > current kernel, should be moved to destination when actual kexec > happens (existing functionality). > > This will require merging krestore and kexec user space functionality > so
Re: [PATCH 0/3 -mm] kexec jump -v8
On Sun, 2008-01-06 at 15:49 -0500, Vivek Goyal wrote: Why should we exchange backup page map information between two kernels? What data has been swapped and how to restore it back should be known to the kernel who did it. I think the memory info and address of ELF headers we can still pass to second kernel the same way we do for /proc/vmcore. The only difference is that purgatory shall have to modify the command line to reflect the new address of ELF headers just before jumping to new kernel (because of swapping). We can also modify the actual ELF headers in purgatory to reflect the right data (because of swapping) and new kernel will not have to know anything about swapping. [...] In addition to revising the ELF headers in purgatory, the /proc/kimgcore interface can also be used to revise the ELF headers in kernel A. But this needs to export backup pages map information to user space (another sysfs/procfs file?). This is kind of two step load process. Load image, then export backup page info to user space and then readjust the headers through /proc/kimgcore. I think purgatory doing it is cleaner. [...] I think there may be no difference between two kinds of files. Nothing prevents hibernated image produced through /proc/vmcore loaded with normal kexec -l. I have just tested it. This means we need not use krestore to resume the hibernated kernel after enhancing /sbin/kexec (because it uses too much anonymous memory). And, the resuming process will be more smooth. Ok. So in a nutshell, any resumable image (be it is generated through /proc/vmcore or /proc/kimgcore) can be launched in the same way (I think kexec --load-preserve-context). ? In fact, if we are modifying the ELF headers in purgatory to reflect the swapped page action, then we don't require /proc/kimgcore interface at all? But, how can purgatory get the backup pages map information? Which is not available when purgatory is loaded. I think there are two methods: Method1: - A setup page is setup by original kernel, and the address of setup page is passed to purgatory using a pre-defined protocol (such as in a register). The backup pages map is in setup page. - Purgatory uses the information in setup page to modify ELF headers - kexeced kernel use ELF headers to build /proc/vmcore Method2: - A setup page is setup by /sbin/kexec - The backup pages map information is written to purgatory via /proc/kimgcore. - Purgatory uses the information to modify ELF headers - kexeced kernel use ELF headers to build /proc/vmcore But, why not just exchanging the backup pages map information between two kernels via the setup page? It is as follow: - A setup page is setup by original kernel, and the address of setup page is passed to kexeced kernel using a pre-defined protocol (such as in a register). The backup pages map is in setup page. - kexec kernel use backup pages map to build /proc/vmcore. To keep it simple, another choice is not passing this backup pages map information between two kernels now. The biggest issue is makedumpfile can not exclude free pages without it, resulting in big hibernated image. Another issue is that the information in /proc/vmcore is not accurate, but that does not affect the hibernation implementation. In fact, if we are modifying the ELF headers in purgatory to reflect the swapped page action, then we don't require /proc/kimgcore interface at all? /proc/kimgcore is mainly used to save the memory image of the kexeced kernel. If this is not to be supported, /proc/kimgcore is not needed. But, I think this is useful to accelerate the hibernating (no another boot is needed for each hibernating). For completion (although may be not a big issue now): Whether using krestore or normal kexec -l depends on the memory used by current kernel (/proc/iomem) and memory in image file (PT_LOAD headers). If all memory in image file is outside memory used by current kernel, krestore should be used. If all memory in image file is inside memory used by current kernel, normal kexec -l should be used. If there is intersection set between memory in image file and memory of current kernel, the image file can not be loaded. I think kexec should mask that difference. A user should be able to load a resumable image either by using kexec -l or kexec --load-preserve-context depending on whether user wants to come back to orignal kernel in future or not. Kexec-tools should recognize the image as resumable. Any page outside the current kernel can be written to final location through /dev/oldmem. And any pages which overlap with the current kernel, should be moved to destination when actual kexec happens (existing functionality). This will require merging krestore and kexec user space functionality so that resuming a hibernated image is effectively a Kexec -l operation. So a user will not worry about whether he is kexecing a fresh
Re: [PATCH 0/3 -mm] kexec jump -v8
On Thu, Jan 03, 2008 at 04:42:26PM +0800, Huang, Ying wrote: > On Mon, 2007-12-31 at 14:26 -0500, Vivek Goyal wrote: > [...] > > Ok. But If I copy the /proc/vmcore to disk. Then I reboot the system > > and boot back into a kernel which is supposed to resume the hibernated > > image. This kernel will not have any command line option jump_back_entry. > > I need to resume using krestore tool. How will a krestore tool decide that > > image one wants to restore is a core file or a hibernated image? > > > > In this context I thought an PT_NOTE might be useful. > > In current implementation, when saving the memory image of hibernated > kernel in hibernating kernel, the jump back entry from kernel command > line should be saved at the same time, or the jump back entry from > kernel command line can be saved as entry point of ELF hibernated image > file by a modified makedumpfile. That is, > > - method 1: > > jbe=`cat /proc/cmdline | tr -d ' ' '\n' | grep kexec_jump_back_entry | cut -d > '=' -f 2` > cp /proc/vmcore . > echo $jbe > kexec_jump_back_entry > > - method 2: > > jbe=`cat /proc/cmdline | tr -d ' ' '\n' | grep kexec_jump_back_entry | cut -d > '=' -f 2` > makedumpfile -j $jbe /proc/vmcore > > > Method 2 is better, because "jump back entry" is the very entry point of > the hibernated image. The vmcore implementation can be changed to set > entry point of /proc/vmcore if "kexec_jump_back_entry" kernel command > line option is present. I did not add this to kernel because it can be > done by user space tool "makedumpfile", and one of the guideline is to > keep kernel part as simple as possible. > I think storing the jump back entry in ELF header should be better. > With method 2, the ordinary "core file" and "hibernated image" can be > distinguished by the "entry point". > Hmm... That's one possible way of differentiating between two kind of files. > > The "jump back entry" can be saved with PT_NOTE too. And more > information can be saved with PT_NOTE. I have ever defined another > mechanism to pass information between two kernels too. I will describe > it later in this mail. > Actually I meant to store a string in PT_NOTE, something like "RESUMABLE" or "HIBERNATED" etc to differentiate between a normal core file and a core file which can be resumed. Entry point should be stored in ELF header only. > > > As for ELF NOTE, in fact, the ELF NOTE does not work for resumable > > > kernel. Because the contents of source page and destination page is > > > swapped during kexec, and the kernel access the destination page > > > directly during parsing ELF NOTE. All memory that is swapped need to be > > > accessed via the backup pages map (image->head). I think these > > > information can be exchanged between two kernels via kernel command line > > > or /proc/kimgcore. > > > > > > > Why should we exchange backup page map information between two kernels? > > What data has been swapped and how to restore it back should be known > > to the kernel who did it. I think the memory info and address of ELF > > headers we can still pass to second kernel the same way we do for > > /proc/vmcore. The only difference is that purgatory shall have to modify > > the command line to reflect the new address of ELF headers just before > > jumping to new kernel (because of swapping). > > > > We can also modify the actual ELF headers in purgatory to reflect the > > right data (because of swapping) and new kernel will not have to know > > anything about swapping. > > > > So I thought of following sequence. > > > > Lets say there is production kernel A and there is helper kernel B (B > > will save the hibernated image of A). > > > > - Boot into A. > > - Load kernel B using --load-preserve-context. > > - This load operation can also create the Elf headers. > > - Kexec -e will start hibernation of A. Pages shall be swapped. Control > > will be transferred to purgatory. > > - Purgatory will readjust the ELF headers and command line based on > > the swapping done and jump to new kernel. > > - New kernel will retrieve the elf headers and export the memory of > > hibernated kernel through /proc/vmcore. > > > > Hence there is no need to communicate swapped pages map between two > > kernels. > > One original page will map to one backup page (the contents of original > page and backup page will be swapped). It is possible that the entries > number of map equals the number of backup pages. > > If the helper kernel B uses 16M memory, there will be 4096 backup pages. > One PT_LOAD header is needed for each backup page to record the map > between the original page to the backup page. So, the memory needed for > PT_LOAD headers will be 32 * 4k = 128k. > > If the size of PT_LOAD headers and the "readability" of headers > information of /proc/vmcore is not a big issue, I think this is a good > idea. > Ok. So if backup page allocation is not contiguous then we will end up with one PT_LOAD header per backup page,
Re: [PATCH 0/3 -mm] kexec jump -v8
On Thu, Jan 03, 2008 at 04:42:26PM +0800, Huang, Ying wrote: On Mon, 2007-12-31 at 14:26 -0500, Vivek Goyal wrote: [...] Ok. But If I copy the /proc/vmcore to disk. Then I reboot the system and boot back into a kernel which is supposed to resume the hibernated image. This kernel will not have any command line option jump_back_entry. I need to resume using krestore tool. How will a krestore tool decide that image one wants to restore is a core file or a hibernated image? In this context I thought an PT_NOTE might be useful. In current implementation, when saving the memory image of hibernated kernel in hibernating kernel, the jump back entry from kernel command line should be saved at the same time, or the jump back entry from kernel command line can be saved as entry point of ELF hibernated image file by a modified makedumpfile. That is, - method 1: jbe=`cat /proc/cmdline | tr -d ' ' '\n' | grep kexec_jump_back_entry | cut -d '=' -f 2` cp /proc/vmcore . echo $jbe kexec_jump_back_entry - method 2: jbe=`cat /proc/cmdline | tr -d ' ' '\n' | grep kexec_jump_back_entry | cut -d '=' -f 2` makedumpfile other options -j $jbe /proc/vmcore image file Method 2 is better, because jump back entry is the very entry point of the hibernated image. The vmcore implementation can be changed to set entry point of /proc/vmcore if kexec_jump_back_entry kernel command line option is present. I did not add this to kernel because it can be done by user space tool makedumpfile, and one of the guideline is to keep kernel part as simple as possible. I think storing the jump back entry in ELF header should be better. With method 2, the ordinary core file and hibernated image can be distinguished by the entry point. Hmm... That's one possible way of differentiating between two kind of files. The jump back entry can be saved with PT_NOTE too. And more information can be saved with PT_NOTE. I have ever defined another mechanism to pass information between two kernels too. I will describe it later in this mail. Actually I meant to store a string in PT_NOTE, something like RESUMABLE or HIBERNATED etc to differentiate between a normal core file and a core file which can be resumed. Entry point should be stored in ELF header only. As for ELF NOTE, in fact, the ELF NOTE does not work for resumable kernel. Because the contents of source page and destination page is swapped during kexec, and the kernel access the destination page directly during parsing ELF NOTE. All memory that is swapped need to be accessed via the backup pages map (image-head). I think these information can be exchanged between two kernels via kernel command line or /proc/kimgcore. Why should we exchange backup page map information between two kernels? What data has been swapped and how to restore it back should be known to the kernel who did it. I think the memory info and address of ELF headers we can still pass to second kernel the same way we do for /proc/vmcore. The only difference is that purgatory shall have to modify the command line to reflect the new address of ELF headers just before jumping to new kernel (because of swapping). We can also modify the actual ELF headers in purgatory to reflect the right data (because of swapping) and new kernel will not have to know anything about swapping. So I thought of following sequence. Lets say there is production kernel A and there is helper kernel B (B will save the hibernated image of A). - Boot into A. - Load kernel B using --load-preserve-context. - This load operation can also create the Elf headers. - Kexec -e will start hibernation of A. Pages shall be swapped. Control will be transferred to purgatory. - Purgatory will readjust the ELF headers and command line based on the swapping done and jump to new kernel. - New kernel will retrieve the elf headers and export the memory of hibernated kernel through /proc/vmcore. Hence there is no need to communicate swapped pages map between two kernels. One original page will map to one backup page (the contents of original page and backup page will be swapped). It is possible that the entries number of map equals the number of backup pages. If the helper kernel B uses 16M memory, there will be 4096 backup pages. One PT_LOAD header is needed for each backup page to record the map between the original page to the backup page. So, the memory needed for PT_LOAD headers will be 32 * 4k = 128k. If the size of PT_LOAD headers and the readability of headers information of /proc/vmcore is not a big issue, I think this is a good idea. Ok. So if backup page allocation is not contiguous then we will end up with one PT_LOAD header per backup page, hence large number of PT_LOAD headers. I know it is little ugly, but still think that it is a better way. In addition to revising the ELF
Re: [PATCH 0/3 -mm] kexec jump -v8
On Mon, 2007-12-31 at 14:26 -0500, Vivek Goyal wrote: [...] > Ok. But If I copy the /proc/vmcore to disk. Then I reboot the system > and boot back into a kernel which is supposed to resume the hibernated > image. This kernel will not have any command line option jump_back_entry. > I need to resume using krestore tool. How will a krestore tool decide that > image one wants to restore is a core file or a hibernated image? > > In this context I thought an PT_NOTE might be useful. In current implementation, when saving the memory image of hibernated kernel in hibernating kernel, the jump back entry from kernel command line should be saved at the same time, or the jump back entry from kernel command line can be saved as entry point of ELF hibernated image file by a modified makedumpfile. That is, - method 1: jbe=`cat /proc/cmdline | tr -d ' ' '\n' | grep kexec_jump_back_entry | cut -d '=' -f 2` cp /proc/vmcore . echo $jbe > kexec_jump_back_entry - method 2: jbe=`cat /proc/cmdline | tr -d ' ' '\n' | grep kexec_jump_back_entry | cut -d '=' -f 2` makedumpfile -j $jbe /proc/vmcore Method 2 is better, because "jump back entry" is the very entry point of the hibernated image. The vmcore implementation can be changed to set entry point of /proc/vmcore if "kexec_jump_back_entry" kernel command line option is present. I did not add this to kernel because it can be done by user space tool "makedumpfile", and one of the guideline is to keep kernel part as simple as possible. With method 2, the ordinary "core file" and "hibernated image" can be distinguished by the "entry point". The "jump back entry" can be saved with PT_NOTE too. And more information can be saved with PT_NOTE. I have ever defined another mechanism to pass information between two kernels too. I will describe it later in this mail. > > As for ELF NOTE, in fact, the ELF NOTE does not work for resumable > > kernel. Because the contents of source page and destination page is > > swapped during kexec, and the kernel access the destination page > > directly during parsing ELF NOTE. All memory that is swapped need to be > > accessed via the backup pages map (image->head). I think these > > information can be exchanged between two kernels via kernel command line > > or /proc/kimgcore. > > > > Why should we exchange backup page map information between two kernels? > What data has been swapped and how to restore it back should be known > to the kernel who did it. I think the memory info and address of ELF > headers we can still pass to second kernel the same way we do for > /proc/vmcore. The only difference is that purgatory shall have to modify > the command line to reflect the new address of ELF headers just before > jumping to new kernel (because of swapping). > > We can also modify the actual ELF headers in purgatory to reflect the > right data (because of swapping) and new kernel will not have to know > anything about swapping. > > So I thought of following sequence. > > Lets say there is production kernel A and there is helper kernel B (B > will save the hibernated image of A). > > - Boot into A. > - Load kernel B using --load-preserve-context. > - This load operation can also create the Elf headers. > - Kexec -e will start hibernation of A. Pages shall be swapped. Control > will be transferred to purgatory. > - Purgatory will readjust the ELF headers and command line based on > the swapping done and jump to new kernel. > - New kernel will retrieve the elf headers and export the memory of > hibernated kernel through /proc/vmcore. > > Hence there is no need to communicate swapped pages map between two > kernels. One original page will map to one backup page (the contents of original page and backup page will be swapped). It is possible that the entries number of map equals the number of backup pages. If the helper kernel B uses 16M memory, there will be 4096 backup pages. One PT_LOAD header is needed for each backup page to record the map between the original page to the backup page. So, the memory needed for PT_LOAD headers will be 32 * 4k = 128k. If the size of PT_LOAD headers and the "readability" of headers information of /proc/vmcore is not a big issue, I think this is a good idea. In addition to revising the ELF headers in purgatory, the /proc/kimgcore interface can also be used to revise the ELF headers in kernel A. But this needs to export backup pages map information to user space (another sysfs/procfs file?). [...] > > The image of B is made as you said. And it can be restored as > follow: > > > > /sbin/kexec -l --args-none --flags=0x2 > > /sbin/kexec -e > > > > That is, the image of B is loaded as a ordinary ELF file. A option > > to /sbin/kexec named --flags are added to specify the > > KEXEC_PRESERVE_CONTEXT flags for sys_kexec_load. This has been tested. > > Shouldn't we be able to load this image using --load-preseve-context? Why > to create another otion --flags. Yes. This seems better. I will
Re: [PATCH 0/3 -mm] kexec jump -v8
On Mon, 2007-12-31 at 14:26 -0500, Vivek Goyal wrote: [...] Ok. But If I copy the /proc/vmcore to disk. Then I reboot the system and boot back into a kernel which is supposed to resume the hibernated image. This kernel will not have any command line option jump_back_entry. I need to resume using krestore tool. How will a krestore tool decide that image one wants to restore is a core file or a hibernated image? In this context I thought an PT_NOTE might be useful. In current implementation, when saving the memory image of hibernated kernel in hibernating kernel, the jump back entry from kernel command line should be saved at the same time, or the jump back entry from kernel command line can be saved as entry point of ELF hibernated image file by a modified makedumpfile. That is, - method 1: jbe=`cat /proc/cmdline | tr -d ' ' '\n' | grep kexec_jump_back_entry | cut -d '=' -f 2` cp /proc/vmcore . echo $jbe kexec_jump_back_entry - method 2: jbe=`cat /proc/cmdline | tr -d ' ' '\n' | grep kexec_jump_back_entry | cut -d '=' -f 2` makedumpfile other options -j $jbe /proc/vmcore image file Method 2 is better, because jump back entry is the very entry point of the hibernated image. The vmcore implementation can be changed to set entry point of /proc/vmcore if kexec_jump_back_entry kernel command line option is present. I did not add this to kernel because it can be done by user space tool makedumpfile, and one of the guideline is to keep kernel part as simple as possible. With method 2, the ordinary core file and hibernated image can be distinguished by the entry point. The jump back entry can be saved with PT_NOTE too. And more information can be saved with PT_NOTE. I have ever defined another mechanism to pass information between two kernels too. I will describe it later in this mail. As for ELF NOTE, in fact, the ELF NOTE does not work for resumable kernel. Because the contents of source page and destination page is swapped during kexec, and the kernel access the destination page directly during parsing ELF NOTE. All memory that is swapped need to be accessed via the backup pages map (image-head). I think these information can be exchanged between two kernels via kernel command line or /proc/kimgcore. Why should we exchange backup page map information between two kernels? What data has been swapped and how to restore it back should be known to the kernel who did it. I think the memory info and address of ELF headers we can still pass to second kernel the same way we do for /proc/vmcore. The only difference is that purgatory shall have to modify the command line to reflect the new address of ELF headers just before jumping to new kernel (because of swapping). We can also modify the actual ELF headers in purgatory to reflect the right data (because of swapping) and new kernel will not have to know anything about swapping. So I thought of following sequence. Lets say there is production kernel A and there is helper kernel B (B will save the hibernated image of A). - Boot into A. - Load kernel B using --load-preserve-context. - This load operation can also create the Elf headers. - Kexec -e will start hibernation of A. Pages shall be swapped. Control will be transferred to purgatory. - Purgatory will readjust the ELF headers and command line based on the swapping done and jump to new kernel. - New kernel will retrieve the elf headers and export the memory of hibernated kernel through /proc/vmcore. Hence there is no need to communicate swapped pages map between two kernels. One original page will map to one backup page (the contents of original page and backup page will be swapped). It is possible that the entries number of map equals the number of backup pages. If the helper kernel B uses 16M memory, there will be 4096 backup pages. One PT_LOAD header is needed for each backup page to record the map between the original page to the backup page. So, the memory needed for PT_LOAD headers will be 32 * 4k = 128k. If the size of PT_LOAD headers and the readability of headers information of /proc/vmcore is not a big issue, I think this is a good idea. In addition to revising the ELF headers in purgatory, the /proc/kimgcore interface can also be used to revise the ELF headers in kernel A. But this needs to export backup pages map information to user space (another sysfs/procfs file?). [...] The image of B is made as you said. And it can be restored as follow: /sbin/kexec -l --args-none --flags=0x2 kimgecore /sbin/kexec -e That is, the image of B is loaded as a ordinary ELF file. A option to /sbin/kexec named --flags are added to specify the KEXEC_PRESERVE_CONTEXT flags for sys_kexec_load. This has been tested. Shouldn't we be able to load this image using --load-preseve-context? Why to create another otion --flags. Yes. This seems better. I will change it. So there seems to be two different kind of load
Re: [PATCH 0/3 -mm] kexec jump -v8
On Sat, Dec 29, 2007 at 10:00:44AM +0800, Huang, Ying wrote: > On Fri, 2007-12-28 at 16:33 -0500, Vivek Goyal wrote: > > On Fri, Dec 21, 2007 at 03:33:19PM +0800, Huang, Ying wrote: > > > This patchset provides an enhancement to kexec/kdump. It implements > > > the following features: > > > > > > - Backup/restore memory used both by the original kernel and the > > > kexeced kernel. > > > > > > - Jumping between the original kernel and the kexeced kernel. > > > > > > - Read/write memory image of the kexeced kernel in the original kernel > > > and write memory image of the original kernel in the kexeced > > > kernel. This can be used as a communication method between the > > > kexeced kernel and the original kernel. > > > > > > > > > The features of this patchset can be used as follow: > > > > > > - Kernel/system debug through making system snapshot. You can make > > > system snapshot, jump back, do some thing and make another system > > > snapshot. > > > > > > > How do you differentiate between whether a core is resumable or not. > > IOW, how do you know the generated /proc/vmcore has been generated after > > a real crash hence can't be resumed (using krestore) or it has been > > generated because of hibernation/debug purposes and can be resumed? > > > > I think you might have to add an extra ELF NOTE to vmcore which can help > > decide whether kernel memory snapshot is resumable or not. > > The current solution is as follow: > > 1. The original kernel will set %edi to jump back entry if resumable and > set %edi to 0 if not. > > 2. The purgatory of loaded kernel will check %edi, if it is not zero, > the string "jump_back_entry=" will be appended to > kernel command line parameter. > > 3. In kexeced kernel, if there is "jump_back_entry=" > in /proc/cmdline, the previous kernel is resumable, otherwise not. > Ok. But If I copy the /proc/vmcore to disk. Then I reboot the system and boot back into a kernel which is supposed to resume the hibernated image. This kernel will not have any command line option jump_back_entry. I need to resume using krestore tool. How will a krestore tool decide that image one wants to restore is a core file or a hibernated image? In this context I thought an PT_NOTE might be useful. > As for ELF NOTE, in fact, the ELF NOTE does not work for resumable > kernel. Because the contents of source page and destination page is > swapped during kexec, and the kernel access the destination page > directly during parsing ELF NOTE. All memory that is swapped need to be > accessed via the backup pages map (image->head). I think these > information can be exchanged between two kernels via kernel command line > or /proc/kimgcore. > Why should we exchange backup page map information between two kernels? What data has been swapped and how to restore it back should be known to the kernel who did it. I think the memory info and address of ELF headers we can still pass to second kernel the same way we do for /proc/vmcore. The only difference is that purgatory shall have to modify the command line to reflect the new address of ELF headers just before jumping to new kernel (because of swapping). We can also modify the actual ELF headers in purgatory to reflect the right data (because of swapping) and new kernel will not have to know anything about swapping. So I thought of following sequence. Lets say there is production kernel A and there is helper kernel B (B will save the hibernated image of A). - Boot into A. - Load kernel B using --load-preserve-context. - This load operation can also create the Elf headers. - Kexec -e will start hibernation of A. Pages shall be swapped. Control will be transferred to purgatory. - Purgatory will readjust the ELF headers and command line based on the swapping done and jump to new kernel. - New kernel will retrieve the elf headers and export the memory of hibernated kernel through /proc/vmcore. Hence there is no need to communicate swapped pages map between two kernels. > > [..] > > > 2. Build an initramfs image contains kexec-tool, or download the > > >pre-built initramfs image, called rootfs.gz in following text. > > > > > > 3. Boot kernel compiled in step 1. > > > > > > 4. Load kernel compiled in step 1 with /sbin/kexec. If You want to use > > >"krestore" tool, the --elf64-core-headers should be specified in > > >command line of /sbin/kexec. The shell command line can be as > > >follow: > > > > > >/sbin/kexec --load-jump-back /boot/bzImage --mem-min=0x10 > > > --mem-max=0xff --elf64-core-headers --initrd=rootfs.gz > > > > > > > How about a different name like "--load-preserve-context". This will > > just mean that kexec need to preserve the context while kexeing to > > image being loaded. Combination of --load-jump-back and > > --load-jump-back-helper is becoming little confusing. > > Yes, this is better. I will change it. > > > > 5. Boot the kexeced kernel with following
Re: [PATCH 0/3 -mm] kexec jump -v8
On Sat, Dec 29, 2007 at 10:00:44AM +0800, Huang, Ying wrote: On Fri, 2007-12-28 at 16:33 -0500, Vivek Goyal wrote: On Fri, Dec 21, 2007 at 03:33:19PM +0800, Huang, Ying wrote: This patchset provides an enhancement to kexec/kdump. It implements the following features: - Backup/restore memory used both by the original kernel and the kexeced kernel. - Jumping between the original kernel and the kexeced kernel. - Read/write memory image of the kexeced kernel in the original kernel and write memory image of the original kernel in the kexeced kernel. This can be used as a communication method between the kexeced kernel and the original kernel. The features of this patchset can be used as follow: - Kernel/system debug through making system snapshot. You can make system snapshot, jump back, do some thing and make another system snapshot. How do you differentiate between whether a core is resumable or not. IOW, how do you know the generated /proc/vmcore has been generated after a real crash hence can't be resumed (using krestore) or it has been generated because of hibernation/debug purposes and can be resumed? I think you might have to add an extra ELF NOTE to vmcore which can help decide whether kernel memory snapshot is resumable or not. The current solution is as follow: 1. The original kernel will set %edi to jump back entry if resumable and set %edi to 0 if not. 2. The purgatory of loaded kernel will check %edi, if it is not zero, the string jump_back_entry=jump_back_entry will be appended to kernel command line parameter. 3. In kexeced kernel, if there is jump_back_entry=jump_back_entry in /proc/cmdline, the previous kernel is resumable, otherwise not. Ok. But If I copy the /proc/vmcore to disk. Then I reboot the system and boot back into a kernel which is supposed to resume the hibernated image. This kernel will not have any command line option jump_back_entry. I need to resume using krestore tool. How will a krestore tool decide that image one wants to restore is a core file or a hibernated image? In this context I thought an PT_NOTE might be useful. As for ELF NOTE, in fact, the ELF NOTE does not work for resumable kernel. Because the contents of source page and destination page is swapped during kexec, and the kernel access the destination page directly during parsing ELF NOTE. All memory that is swapped need to be accessed via the backup pages map (image-head). I think these information can be exchanged between two kernels via kernel command line or /proc/kimgcore. Why should we exchange backup page map information between two kernels? What data has been swapped and how to restore it back should be known to the kernel who did it. I think the memory info and address of ELF headers we can still pass to second kernel the same way we do for /proc/vmcore. The only difference is that purgatory shall have to modify the command line to reflect the new address of ELF headers just before jumping to new kernel (because of swapping). We can also modify the actual ELF headers in purgatory to reflect the right data (because of swapping) and new kernel will not have to know anything about swapping. So I thought of following sequence. Lets say there is production kernel A and there is helper kernel B (B will save the hibernated image of A). - Boot into A. - Load kernel B using --load-preserve-context. - This load operation can also create the Elf headers. - Kexec -e will start hibernation of A. Pages shall be swapped. Control will be transferred to purgatory. - Purgatory will readjust the ELF headers and command line based on the swapping done and jump to new kernel. - New kernel will retrieve the elf headers and export the memory of hibernated kernel through /proc/vmcore. Hence there is no need to communicate swapped pages map between two kernels. [..] 2. Build an initramfs image contains kexec-tool, or download the pre-built initramfs image, called rootfs.gz in following text. 3. Boot kernel compiled in step 1. 4. Load kernel compiled in step 1 with /sbin/kexec. If You want to use krestore tool, the --elf64-core-headers should be specified in command line of /sbin/kexec. The shell command line can be as follow: /sbin/kexec --load-jump-back /boot/bzImage --mem-min=0x10 --mem-max=0xff --elf64-core-headers --initrd=rootfs.gz How about a different name like --load-preserve-context. This will just mean that kexec need to preserve the context while kexeing to image being loaded. Combination of --load-jump-back and --load-jump-back-helper is becoming little confusing. Yes, this is better. I will change it. 5. Boot the kexeced kernel with following shell command line: /sbin/kexec -e 6. The kexeced kernel will boot as normal kexec. In kexeced kernel the memory
Re: [PATCH 0/3 -mm] kexec jump -v8
On Fri, 2007-12-28 at 16:33 -0500, Vivek Goyal wrote: > On Fri, Dec 21, 2007 at 03:33:19PM +0800, Huang, Ying wrote: > > This patchset provides an enhancement to kexec/kdump. It implements > > the following features: > > > > - Backup/restore memory used both by the original kernel and the > > kexeced kernel. > > > > - Jumping between the original kernel and the kexeced kernel. > > > > - Read/write memory image of the kexeced kernel in the original kernel > > and write memory image of the original kernel in the kexeced > > kernel. This can be used as a communication method between the > > kexeced kernel and the original kernel. > > > > > > The features of this patchset can be used as follow: > > > > - Kernel/system debug through making system snapshot. You can make > > system snapshot, jump back, do some thing and make another system > > snapshot. > > > > How do you differentiate between whether a core is resumable or not. > IOW, how do you know the generated /proc/vmcore has been generated after > a real crash hence can't be resumed (using krestore) or it has been > generated because of hibernation/debug purposes and can be resumed? > > I think you might have to add an extra ELF NOTE to vmcore which can help > decide whether kernel memory snapshot is resumable or not. The current solution is as follow: 1. The original kernel will set %edi to jump back entry if resumable and set %edi to 0 if not. 2. The purgatory of loaded kernel will check %edi, if it is not zero, the string "jump_back_entry=" will be appended to kernel command line parameter. 3. In kexeced kernel, if there is "jump_back_entry=" in /proc/cmdline, the previous kernel is resumable, otherwise not. As for ELF NOTE, in fact, the ELF NOTE does not work for resumable kernel. Because the contents of source page and destination page is swapped during kexec, and the kernel access the destination page directly during parsing ELF NOTE. All memory that is swapped need to be accessed via the backup pages map (image->head). I think these information can be exchanged between two kernels via kernel command line or /proc/kimgcore. > [..] > > 2. Build an initramfs image contains kexec-tool, or download the > >pre-built initramfs image, called rootfs.gz in following text. > > > > 3. Boot kernel compiled in step 1. > > > > 4. Load kernel compiled in step 1 with /sbin/kexec. If You want to use > >"krestore" tool, the --elf64-core-headers should be specified in > >command line of /sbin/kexec. The shell command line can be as > >follow: > > > >/sbin/kexec --load-jump-back /boot/bzImage --mem-min=0x10 > > --mem-max=0xff --elf64-core-headers --initrd=rootfs.gz > > > > How about a different name like "--load-preserve-context". This will > just mean that kexec need to preserve the context while kexeing to > image being loaded. Combination of --load-jump-back and > --load-jump-back-helper is becoming little confusing. Yes, this is better. I will change it. > > 5. Boot the kexeced kernel with following shell command line: > > > >/sbin/kexec -e > > > > 6. The kexeced kernel will boot as normal kexec. In kexeced kernel the > >memory image of original kernel can read via /proc/vmcore or > >/dev/oldmem, and can be written via /dev/oldmem. You can > >save/restore/modify it as you want to. > > > > Restoring a hibernated image using /dev/oldmem should be easy and I > think one should be able to launch it back using --load-jump-back-helper. Yes. I think so too. The current implementation of krestore restoring the hibernated image using /dev/oldmem. And the hibernated image can be launched using --load-jump-back-helper. > How do you restore already kexeced kernel? For example if I got two > kernels A and B. A is the one which will hibernate and B will be used > to store the hibernated kernel. I think as per the procedure one needs > to first boot into kernel B and then jump back to kernel A. This will > make image of B available in /proc/kimgcore. If I save /proc/kimgcore > to disk and want to jump back to it, how do I do it? I guess I need > to kexec again using --load-jump-back and not restore using krestore? The image of B is made as you said. And it can be restored as follow: /sbin/kexec -l --args-none --flags=0x2 /sbin/kexec -e That is, the image of B is loaded as a ordinary ELF file. A option to /sbin/kexec named --flags are added to specify the KEXEC_PRESERVE_CONTEXT flags for sys_kexec_load. This has been tested. > > 7. Prepare jumping back from kexeced kernel with following shell > >command lines: > > > >jump_back_entry=`cat /proc/cmdline | tr ' ' '\n' | grep > > kexec_jump_back_entry | cut -d '='` > >/sbin/kexec --load-jump-back-helper=$jump_back_entry > > > > How about decoupling entry point from --load-jump-back-helper. We can > introduce a separate option for entry point. Something like. > > kexec --load-jump-back-helper --entry=$jump_back_entry > >
Re: [PATCH 0/3 -mm] kexec jump -v8
On Fri, Dec 21, 2007 at 03:33:19PM +0800, Huang, Ying wrote: > This patchset provides an enhancement to kexec/kdump. It implements > the following features: > > - Backup/restore memory used both by the original kernel and the > kexeced kernel. > > - Jumping between the original kernel and the kexeced kernel. > > - Read/write memory image of the kexeced kernel in the original kernel > and write memory image of the original kernel in the kexeced > kernel. This can be used as a communication method between the > kexeced kernel and the original kernel. > > > The features of this patchset can be used as follow: > > - Kernel/system debug through making system snapshot. You can make > system snapshot, jump back, do some thing and make another system > snapshot. > How do you differentiate between whether a core is resumable or not. IOW, how do you know the generated /proc/vmcore has been generated after a real crash hence can't be resumed (using krestore) or it has been generated because of hibernation/debug purposes and can be resumed? I think you might have to add an extra ELF NOTE to vmcore which can help decide whether kernel memory snapshot is resumable or not. [..] > 2. Build an initramfs image contains kexec-tool, or download the >pre-built initramfs image, called rootfs.gz in following text. > > 3. Boot kernel compiled in step 1. > > 4. Load kernel compiled in step 1 with /sbin/kexec. If You want to use >"krestore" tool, the --elf64-core-headers should be specified in >command line of /sbin/kexec. The shell command line can be as >follow: > >/sbin/kexec --load-jump-back /boot/bzImage --mem-min=0x10 > --mem-max=0xff --elf64-core-headers --initrd=rootfs.gz > How about a different name like "--load-preserve-context". This will just mean that kexec need to preserve the context while kexeing to image being loaded. Combination of --load-jump-back and --load-jump-back-helper is becoming little confusing. > 5. Boot the kexeced kernel with following shell command line: > >/sbin/kexec -e > > 6. The kexeced kernel will boot as normal kexec. In kexeced kernel the >memory image of original kernel can read via /proc/vmcore or >/dev/oldmem, and can be written via /dev/oldmem. You can >save/restore/modify it as you want to. > Restoring a hibernated image using /dev/oldmem should be easy and I think one should be able to launch it back using --load-jump-back-helper. How do you restore already kexeced kernel? For example if I got two kernels A and B. A is the one which will hibernate and B will be used to store the hibernated kernel. I think as per the procedure one needs to first boot into kernel B and then jump back to kernel A. This will make image of B available in /proc/kimgcore. If I save /proc/kimgcore to disk and want to jump back to it, how do I do it? I guess I need to kexec again using --load-jump-back and not restore using krestore? > 7. Prepare jumping back from kexeced kernel with following shell >command lines: > >jump_back_entry=`cat /proc/cmdline | tr ' ' '\n' | grep > kexec_jump_back_entry | cut -d '='` >/sbin/kexec --load-jump-back-helper=$jump_back_entry > How about decoupling entry point from --load-jump-back-helper. We can introduce a separate option for entry point. Something like. kexec --load-jump-back-helper --entry=$jump_back_entry May be we can generalize the --entry so that a user can override the entry point of the normal kexec image using above. > 8. Jump back to the original kernel with following shell command line: > >/sbin/kexec -e > > 9. Now, you are in the original kernel again. You can read/write the >memory image of kexeced kernel via /proc/kimgcore. > > 10. You can jump between the original kernel and kexeced kernel as you > want to via the following shell command line: > > /sbin/kexec -e > > > Known issues: > > - The suspend/resume callback of device drivers are used to put > devices into quiescent state. This will unnecessarily (possibly > harmfully) put devices into low power state. This is intended to be > solved by separating device quiesce/unquiesce callback from the > device suspend/resume callback. > > > ChangeLog: > > v8: > > - Split kexec jump patchset from kexec based hibernation patchset. > > - Add writing support to kimgcore. This can be used as a communication > method between kexeced kernel and original kernel. > What are we communicating between two kernels using kimgcore? I am setting up a system to test out the patches. More later... Thanks Vivek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3 -mm] kexec jump -v8
On Fri, Dec 21, 2007 at 03:33:19PM +0800, Huang, Ying wrote: This patchset provides an enhancement to kexec/kdump. It implements the following features: - Backup/restore memory used both by the original kernel and the kexeced kernel. - Jumping between the original kernel and the kexeced kernel. - Read/write memory image of the kexeced kernel in the original kernel and write memory image of the original kernel in the kexeced kernel. This can be used as a communication method between the kexeced kernel and the original kernel. The features of this patchset can be used as follow: - Kernel/system debug through making system snapshot. You can make system snapshot, jump back, do some thing and make another system snapshot. How do you differentiate between whether a core is resumable or not. IOW, how do you know the generated /proc/vmcore has been generated after a real crash hence can't be resumed (using krestore) or it has been generated because of hibernation/debug purposes and can be resumed? I think you might have to add an extra ELF NOTE to vmcore which can help decide whether kernel memory snapshot is resumable or not. [..] 2. Build an initramfs image contains kexec-tool, or download the pre-built initramfs image, called rootfs.gz in following text. 3. Boot kernel compiled in step 1. 4. Load kernel compiled in step 1 with /sbin/kexec. If You want to use krestore tool, the --elf64-core-headers should be specified in command line of /sbin/kexec. The shell command line can be as follow: /sbin/kexec --load-jump-back /boot/bzImage --mem-min=0x10 --mem-max=0xff --elf64-core-headers --initrd=rootfs.gz How about a different name like --load-preserve-context. This will just mean that kexec need to preserve the context while kexeing to image being loaded. Combination of --load-jump-back and --load-jump-back-helper is becoming little confusing. 5. Boot the kexeced kernel with following shell command line: /sbin/kexec -e 6. The kexeced kernel will boot as normal kexec. In kexeced kernel the memory image of original kernel can read via /proc/vmcore or /dev/oldmem, and can be written via /dev/oldmem. You can save/restore/modify it as you want to. Restoring a hibernated image using /dev/oldmem should be easy and I think one should be able to launch it back using --load-jump-back-helper. How do you restore already kexeced kernel? For example if I got two kernels A and B. A is the one which will hibernate and B will be used to store the hibernated kernel. I think as per the procedure one needs to first boot into kernel B and then jump back to kernel A. This will make image of B available in /proc/kimgcore. If I save /proc/kimgcore to disk and want to jump back to it, how do I do it? I guess I need to kexec again using --load-jump-back and not restore using krestore? 7. Prepare jumping back from kexeced kernel with following shell command lines: jump_back_entry=`cat /proc/cmdline | tr ' ' '\n' | grep kexec_jump_back_entry | cut -d '='` /sbin/kexec --load-jump-back-helper=$jump_back_entry How about decoupling entry point from --load-jump-back-helper. We can introduce a separate option for entry point. Something like. kexec --load-jump-back-helper --entry=$jump_back_entry May be we can generalize the --entry so that a user can override the entry point of the normal kexec image using above. 8. Jump back to the original kernel with following shell command line: /sbin/kexec -e 9. Now, you are in the original kernel again. You can read/write the memory image of kexeced kernel via /proc/kimgcore. 10. You can jump between the original kernel and kexeced kernel as you want to via the following shell command line: /sbin/kexec -e Known issues: - The suspend/resume callback of device drivers are used to put devices into quiescent state. This will unnecessarily (possibly harmfully) put devices into low power state. This is intended to be solved by separating device quiesce/unquiesce callback from the device suspend/resume callback. ChangeLog: v8: - Split kexec jump patchset from kexec based hibernation patchset. - Add writing support to kimgcore. This can be used as a communication method between kexeced kernel and original kernel. What are we communicating between two kernels using kimgcore? I am setting up a system to test out the patches. More later... Thanks Vivek -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3 -mm] kexec jump -v8
On Fri, 2007-12-28 at 16:33 -0500, Vivek Goyal wrote: On Fri, Dec 21, 2007 at 03:33:19PM +0800, Huang, Ying wrote: This patchset provides an enhancement to kexec/kdump. It implements the following features: - Backup/restore memory used both by the original kernel and the kexeced kernel. - Jumping between the original kernel and the kexeced kernel. - Read/write memory image of the kexeced kernel in the original kernel and write memory image of the original kernel in the kexeced kernel. This can be used as a communication method between the kexeced kernel and the original kernel. The features of this patchset can be used as follow: - Kernel/system debug through making system snapshot. You can make system snapshot, jump back, do some thing and make another system snapshot. How do you differentiate between whether a core is resumable or not. IOW, how do you know the generated /proc/vmcore has been generated after a real crash hence can't be resumed (using krestore) or it has been generated because of hibernation/debug purposes and can be resumed? I think you might have to add an extra ELF NOTE to vmcore which can help decide whether kernel memory snapshot is resumable or not. The current solution is as follow: 1. The original kernel will set %edi to jump back entry if resumable and set %edi to 0 if not. 2. The purgatory of loaded kernel will check %edi, if it is not zero, the string jump_back_entry=jump_back_entry will be appended to kernel command line parameter. 3. In kexeced kernel, if there is jump_back_entry=jump_back_entry in /proc/cmdline, the previous kernel is resumable, otherwise not. As for ELF NOTE, in fact, the ELF NOTE does not work for resumable kernel. Because the contents of source page and destination page is swapped during kexec, and the kernel access the destination page directly during parsing ELF NOTE. All memory that is swapped need to be accessed via the backup pages map (image-head). I think these information can be exchanged between two kernels via kernel command line or /proc/kimgcore. [..] 2. Build an initramfs image contains kexec-tool, or download the pre-built initramfs image, called rootfs.gz in following text. 3. Boot kernel compiled in step 1. 4. Load kernel compiled in step 1 with /sbin/kexec. If You want to use krestore tool, the --elf64-core-headers should be specified in command line of /sbin/kexec. The shell command line can be as follow: /sbin/kexec --load-jump-back /boot/bzImage --mem-min=0x10 --mem-max=0xff --elf64-core-headers --initrd=rootfs.gz How about a different name like --load-preserve-context. This will just mean that kexec need to preserve the context while kexeing to image being loaded. Combination of --load-jump-back and --load-jump-back-helper is becoming little confusing. Yes, this is better. I will change it. 5. Boot the kexeced kernel with following shell command line: /sbin/kexec -e 6. The kexeced kernel will boot as normal kexec. In kexeced kernel the memory image of original kernel can read via /proc/vmcore or /dev/oldmem, and can be written via /dev/oldmem. You can save/restore/modify it as you want to. Restoring a hibernated image using /dev/oldmem should be easy and I think one should be able to launch it back using --load-jump-back-helper. Yes. I think so too. The current implementation of krestore restoring the hibernated image using /dev/oldmem. And the hibernated image can be launched using --load-jump-back-helper. How do you restore already kexeced kernel? For example if I got two kernels A and B. A is the one which will hibernate and B will be used to store the hibernated kernel. I think as per the procedure one needs to first boot into kernel B and then jump back to kernel A. This will make image of B available in /proc/kimgcore. If I save /proc/kimgcore to disk and want to jump back to it, how do I do it? I guess I need to kexec again using --load-jump-back and not restore using krestore? The image of B is made as you said. And it can be restored as follow: /sbin/kexec -l --args-none --flags=0x2 kimgecore /sbin/kexec -e That is, the image of B is loaded as a ordinary ELF file. A option to /sbin/kexec named --flags are added to specify the KEXEC_PRESERVE_CONTEXT flags for sys_kexec_load. This has been tested. 7. Prepare jumping back from kexeced kernel with following shell command lines: jump_back_entry=`cat /proc/cmdline | tr ' ' '\n' | grep kexec_jump_back_entry | cut -d '='` /sbin/kexec --load-jump-back-helper=$jump_back_entry How about decoupling entry point from --load-jump-back-helper. We can introduce a separate option for entry point. Something like. kexec --load-jump-back-helper --entry=$jump_back_entry May be we can generalize the --entry so that a user can override the entry point of the normal
Re: [PATCH 0/3 -mm] kexec jump -v8
On Thu, 2007-12-27 at 13:12 -0500, Vivek Goyal wrote: > On Thu, Dec 27, 2007 at 10:33:13AM +0800, Huang, Ying wrote: > > On Wed, 2007-12-26 at 20:57 -0500, Vivek Goyal wrote: > > [...] > > > > 9. Now, you are in the original kernel again. You can read/write the > > > >memory image of kexeced kernel via /proc/kimgcore. > > > > > > > > > > Why do we need two interfaces, /proc/vmcore and /proc/kimgcore? Can't > > > we have just one say /proc/vmcore. Irrespective of what kernel you are > > > in /proc/vmcore gives you the access to the memory of kernel which was > > > previously booted. > > > > In theory we can kexec another kernel even in a kexeced kernel, that is, > > in kernel A kexec kernel B, and in kernel B kexec another kernel C. In > > this situation, both /proc/vmcore and /proc/kimgcore has valid contents. > > So I think, it may be better to keep two interfaces. > > > > In those situations I think only one interface is better. For example, > above will be broken if somebody kexec 4 kernels. > > A-->B--->C--->D I don't think the two interfaces will be broken if somebody kexec 4 kernels. For example, when kexec D from C, the /proc/vmcore is contents of B, /proc/kimgcore is contents of D. To jump back from C to B, the D is unloaded, and a jump back helper image is loaded. > I think better option might be if it is stack like situation. A kernel > shows you only the previous kernel's memory contents through /proc/vmcore > interface. So If I am in kernel D, I see only kernel C's memory image. > To see kernel B's memory image, one shall have to go back to kernel C. Maybe it is not sufficient to only show the previous kernel's memory contents. In kernel C, you maybe need to access the memory image of kernel B and memory image of kernel D. That is, /proc/vmcore is the memory image of the previous kernel, and /proc/kimgcore is the memory image of the next kernel. Best Regards, Huang Ying -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3 -mm] kexec jump -v8
On Thu, Dec 27, 2007 at 10:33:13AM +0800, Huang, Ying wrote: > On Wed, 2007-12-26 at 20:57 -0500, Vivek Goyal wrote: > [...] > > > 9. Now, you are in the original kernel again. You can read/write the > > >memory image of kexeced kernel via /proc/kimgcore. > > > > > > > Why do we need two interfaces, /proc/vmcore and /proc/kimgcore? Can't > > we have just one say /proc/vmcore. Irrespective of what kernel you are > > in /proc/vmcore gives you the access to the memory of kernel which was > > previously booted. > > In theory we can kexec another kernel even in a kexeced kernel, that is, > in kernel A kexec kernel B, and in kernel B kexec another kernel C. In > this situation, both /proc/vmcore and /proc/kimgcore has valid contents. > So I think, it may be better to keep two interfaces. > In those situations I think only one interface is better. For example, above will be broken if somebody kexec 4 kernels. A-->B--->C--->D I think better option might be if it is stack like situation. A kernel shows you only the previous kernel's memory contents through /proc/vmcore interface. So If I am in kernel D, I see only kernel C's memory image. To see kernel B's memory image, one shall have to go back to kernel C. Thanks Vivek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3 -mm] kexec jump -v8
On Thu, Dec 27, 2007 at 10:33:13AM +0800, Huang, Ying wrote: On Wed, 2007-12-26 at 20:57 -0500, Vivek Goyal wrote: [...] 9. Now, you are in the original kernel again. You can read/write the memory image of kexeced kernel via /proc/kimgcore. Why do we need two interfaces, /proc/vmcore and /proc/kimgcore? Can't we have just one say /proc/vmcore. Irrespective of what kernel you are in /proc/vmcore gives you the access to the memory of kernel which was previously booted. In theory we can kexec another kernel even in a kexeced kernel, that is, in kernel A kexec kernel B, and in kernel B kexec another kernel C. In this situation, both /proc/vmcore and /proc/kimgcore has valid contents. So I think, it may be better to keep two interfaces. In those situations I think only one interface is better. For example, above will be broken if somebody kexec 4 kernels. A--B---C---D I think better option might be if it is stack like situation. A kernel shows you only the previous kernel's memory contents through /proc/vmcore interface. So If I am in kernel D, I see only kernel C's memory image. To see kernel B's memory image, one shall have to go back to kernel C. Thanks Vivek -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3 -mm] kexec jump -v8
On Thu, 2007-12-27 at 13:12 -0500, Vivek Goyal wrote: On Thu, Dec 27, 2007 at 10:33:13AM +0800, Huang, Ying wrote: On Wed, 2007-12-26 at 20:57 -0500, Vivek Goyal wrote: [...] 9. Now, you are in the original kernel again. You can read/write the memory image of kexeced kernel via /proc/kimgcore. Why do we need two interfaces, /proc/vmcore and /proc/kimgcore? Can't we have just one say /proc/vmcore. Irrespective of what kernel you are in /proc/vmcore gives you the access to the memory of kernel which was previously booted. In theory we can kexec another kernel even in a kexeced kernel, that is, in kernel A kexec kernel B, and in kernel B kexec another kernel C. In this situation, both /proc/vmcore and /proc/kimgcore has valid contents. So I think, it may be better to keep two interfaces. In those situations I think only one interface is better. For example, above will be broken if somebody kexec 4 kernels. A--B---C---D I don't think the two interfaces will be broken if somebody kexec 4 kernels. For example, when kexec D from C, the /proc/vmcore is contents of B, /proc/kimgcore is contents of D. To jump back from C to B, the D is unloaded, and a jump back helper image is loaded. I think better option might be if it is stack like situation. A kernel shows you only the previous kernel's memory contents through /proc/vmcore interface. So If I am in kernel D, I see only kernel C's memory image. To see kernel B's memory image, one shall have to go back to kernel C. Maybe it is not sufficient to only show the previous kernel's memory contents. In kernel C, you maybe need to access the memory image of kernel B and memory image of kernel D. That is, /proc/vmcore is the memory image of the previous kernel, and /proc/kimgcore is the memory image of the next kernel. Best Regards, Huang Ying -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3 -mm] kexec jump -v8
On Wed, 2007-12-26 at 20:57 -0500, Vivek Goyal wrote: [...] > > 9. Now, you are in the original kernel again. You can read/write the > >memory image of kexeced kernel via /proc/kimgcore. > > > > Why do we need two interfaces, /proc/vmcore and /proc/kimgcore? Can't > we have just one say /proc/vmcore. Irrespective of what kernel you are > in /proc/vmcore gives you the access to the memory of kernel which was > previously booted. In theory we can kexec another kernel even in a kexeced kernel, that is, in kernel A kexec kernel B, and in kernel B kexec another kernel C. In this situation, both /proc/vmcore and /proc/kimgcore has valid contents. So I think, it may be better to keep two interfaces. In fact, current kexec jump implementation use a dummy "jump back helper image" in kexeced kernel to jump back to the original kernel. The "jump back helper image" has no PT_LOAD segment, it is used to provide a struct kimage (including control page, swap page) and entry point to jump back. Best Regards, Huang Ying -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3 -mm] kexec jump -v8
On Fri, Dec 21, 2007 at 03:33:19PM +0800, Huang, Ying wrote: [..] > The following user-space tools can be used with kexec jump. > > 1. kexec-tools needs to be patched to support kexec jump. The patches >and the precompiled kexec can be download from the following URL: >source: > http://khibernation.sourceforge.net/download/release_v8/kexec-tools/kexec-tools-src_git_kh8.tar.bz2 >patches: > http://khibernation.sourceforge.net/download/release_v8/kexec-tools/kexec-tools-patches_git_kh8.tar.bz2 >binary: > http://khibernation.sourceforge.net/download/release_v8/kexec-tools/kexec_git_kh8 > > 2. makedumpfile with patches are used as memory image saving tool, it >can exclude free pages from original kernel memory image file. The >patches and the precompiled makedumpfile can be download from the >following URL: >source: > http://khibernation.sourceforge.net/download/release_v8/makedumpfile/makedumpfile-src_cvs_kh8.tar.bz2 >patches: > http://khibernation.sourceforge.net/download/release_v8/makedumpfile/makedumpfile-patches_cvs_kh8.tar.bz2 >binary: > http://khibernation.sourceforge.net/download/release_v8/makedumpfile/makedumpfile_cvs_kh8 > > 3. A simplest memory image restoring tool named "krestore" is >implemented. It can be downloaded from the following URL: >source: > http://khibernation.sourceforge.net/download/release_v8/krestore/krestore-src_cvs_kh8.tar.bz2 >binary: > http://khibernation.sourceforge.net/download/release_v8/krestore/krestore_cvs_kh8 > > An initramfs image can be used as the root file system of kexeced > kernel. An initramfs image built with "BuildRoot" can be downloaded > from the following URL: > initramfs image: > http://khibernation.sourceforge.net/download/release_v8/initramfs/rootfs_cvs_kh8.gz > All user space tools above are included in the initramfs image. > > > Usage example of jumping between original and kexeced kernel: > > 1. Compile and install patched kernel with following options selected: > > CONFIG_X86_32=y > CONFIG_RELOCATABLE=y > CONFIG_KEXEC=y > CONFIG_CRASH_DUMP=y > CONFIG_PM=y > > 2. Build an initramfs image contains kexec-tool, or download the >pre-built initramfs image, called rootfs.gz in following text. > > 3. Boot kernel compiled in step 1. > > 4. Load kernel compiled in step 1 with /sbin/kexec. If You want to use >"krestore" tool, the --elf64-core-headers should be specified in >command line of /sbin/kexec. The shell command line can be as >follow: > >/sbin/kexec --load-jump-back /boot/bzImage --mem-min=0x10 > --mem-max=0xff --elf64-core-headers --initrd=rootfs.gz > > 5. Boot the kexeced kernel with following shell command line: > >/sbin/kexec -e > > 6. The kexeced kernel will boot as normal kexec. In kexeced kernel the >memory image of original kernel can read via /proc/vmcore or >/dev/oldmem, and can be written via /dev/oldmem. You can >save/restore/modify it as you want to. > > 7. Prepare jumping back from kexeced kernel with following shell >command lines: > >jump_back_entry=`cat /proc/cmdline | tr ' ' '\n' | grep > kexec_jump_back_entry | cut -d '='` >/sbin/kexec --load-jump-back-helper=$jump_back_entry > > 8. Jump back to the original kernel with following shell command line: > >/sbin/kexec -e > > 9. Now, you are in the original kernel again. You can read/write the >memory image of kexeced kernel via /proc/kimgcore. > Why do we need two interfaces, /proc/vmcore and /proc/kimgcore? Can't we have just one say /proc/vmcore. Irrespective of what kernel you are in /proc/vmcore gives you the access to the memory of kernel which was previously booted. Thanks Vivek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3 -mm] kexec jump -v8
On Fri, Dec 21, 2007 at 03:33:19PM +0800, Huang, Ying wrote: [..] The following user-space tools can be used with kexec jump. 1. kexec-tools needs to be patched to support kexec jump. The patches and the precompiled kexec can be download from the following URL: source: http://khibernation.sourceforge.net/download/release_v8/kexec-tools/kexec-tools-src_git_kh8.tar.bz2 patches: http://khibernation.sourceforge.net/download/release_v8/kexec-tools/kexec-tools-patches_git_kh8.tar.bz2 binary: http://khibernation.sourceforge.net/download/release_v8/kexec-tools/kexec_git_kh8 2. makedumpfile with patches are used as memory image saving tool, it can exclude free pages from original kernel memory image file. The patches and the precompiled makedumpfile can be download from the following URL: source: http://khibernation.sourceforge.net/download/release_v8/makedumpfile/makedumpfile-src_cvs_kh8.tar.bz2 patches: http://khibernation.sourceforge.net/download/release_v8/makedumpfile/makedumpfile-patches_cvs_kh8.tar.bz2 binary: http://khibernation.sourceforge.net/download/release_v8/makedumpfile/makedumpfile_cvs_kh8 3. A simplest memory image restoring tool named krestore is implemented. It can be downloaded from the following URL: source: http://khibernation.sourceforge.net/download/release_v8/krestore/krestore-src_cvs_kh8.tar.bz2 binary: http://khibernation.sourceforge.net/download/release_v8/krestore/krestore_cvs_kh8 An initramfs image can be used as the root file system of kexeced kernel. An initramfs image built with BuildRoot can be downloaded from the following URL: initramfs image: http://khibernation.sourceforge.net/download/release_v8/initramfs/rootfs_cvs_kh8.gz All user space tools above are included in the initramfs image. Usage example of jumping between original and kexeced kernel: 1. Compile and install patched kernel with following options selected: CONFIG_X86_32=y CONFIG_RELOCATABLE=y CONFIG_KEXEC=y CONFIG_CRASH_DUMP=y CONFIG_PM=y 2. Build an initramfs image contains kexec-tool, or download the pre-built initramfs image, called rootfs.gz in following text. 3. Boot kernel compiled in step 1. 4. Load kernel compiled in step 1 with /sbin/kexec. If You want to use krestore tool, the --elf64-core-headers should be specified in command line of /sbin/kexec. The shell command line can be as follow: /sbin/kexec --load-jump-back /boot/bzImage --mem-min=0x10 --mem-max=0xff --elf64-core-headers --initrd=rootfs.gz 5. Boot the kexeced kernel with following shell command line: /sbin/kexec -e 6. The kexeced kernel will boot as normal kexec. In kexeced kernel the memory image of original kernel can read via /proc/vmcore or /dev/oldmem, and can be written via /dev/oldmem. You can save/restore/modify it as you want to. 7. Prepare jumping back from kexeced kernel with following shell command lines: jump_back_entry=`cat /proc/cmdline | tr ' ' '\n' | grep kexec_jump_back_entry | cut -d '='` /sbin/kexec --load-jump-back-helper=$jump_back_entry 8. Jump back to the original kernel with following shell command line: /sbin/kexec -e 9. Now, you are in the original kernel again. You can read/write the memory image of kexeced kernel via /proc/kimgcore. Why do we need two interfaces, /proc/vmcore and /proc/kimgcore? Can't we have just one say /proc/vmcore. Irrespective of what kernel you are in /proc/vmcore gives you the access to the memory of kernel which was previously booted. Thanks Vivek -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3 -mm] kexec jump -v8
On Wed, 2007-12-26 at 20:57 -0500, Vivek Goyal wrote: [...] 9. Now, you are in the original kernel again. You can read/write the memory image of kexeced kernel via /proc/kimgcore. Why do we need two interfaces, /proc/vmcore and /proc/kimgcore? Can't we have just one say /proc/vmcore. Irrespective of what kernel you are in /proc/vmcore gives you the access to the memory of kernel which was previously booted. In theory we can kexec another kernel even in a kexeced kernel, that is, in kernel A kexec kernel B, and in kernel B kexec another kernel C. In this situation, both /proc/vmcore and /proc/kimgcore has valid contents. So I think, it may be better to keep two interfaces. In fact, current kexec jump implementation use a dummy jump back helper image in kexeced kernel to jump back to the original kernel. The jump back helper image has no PT_LOAD segment, it is used to provide a struct kimage (including control page, swap page) and entry point to jump back. Best Regards, Huang Ying -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3 -mm] kexec jump -v8
On Fri, 2007-12-21 at 19:35 +1100, Nigel Cunningham wrote: > Hi. > > Huang, Ying wrote: > > This patchset provides an enhancement to kexec/kdump. It implements > > the following features: > > > > - Backup/restore memory used both by the original kernel and the > > kexeced kernel. > > Why the kexeced kernel as well? The memory range used by kexeced kernel is also the usable memory range in original kernel. Maybe should be: backup/restore memory used by both the original kernel and the kexeced kernel. My English is poor. > [...] > > > The features of this patchset can be used as follow: > > > > - Kernel/system debug through making system snapshot. You can make > > system snapshot, jump back, do some thing and make another system > > snapshot. > > Are you somehow recording all the filesystem changes after the first > snapshot? If not, this is pointless (you'll end up with filesystem > corruption). This snapshot is not used for restore/resume. It is just used for debugging. You can check the system state with these snapshots. So I think it is useful even without recording filesystem changes. > [...] > > > - Cooperative multi-kernel/system. With kexec jump, you can switch > > between several kernels/systems quickly without boot process except > > the first time. This appears like swap a whole kernel/system out/in. > > How is this useful to the end user? I am not sure how useful is this. Maybe I can run a Redhat and a Debian on my machine and switch between them. Best Regards, Huang Ying -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3 -mm] kexec jump -v8
Hi. Huang, Ying wrote: > This patchset provides an enhancement to kexec/kdump. It implements > the following features: > > - Backup/restore memory used both by the original kernel and the > kexeced kernel. Why the kexeced kernel as well? [...] > The features of this patchset can be used as follow: > > - Kernel/system debug through making system snapshot. You can make > system snapshot, jump back, do some thing and make another system > snapshot. Are you somehow recording all the filesystem changes after the first snapshot? If not, this is pointless (you'll end up with filesystem corruption). [...] > - Cooperative multi-kernel/system. With kexec jump, you can switch > between several kernels/systems quickly without boot process except > the first time. This appears like swap a whole kernel/system out/in. How is this useful to the end user? Regards, Nigel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3 -mm] kexec jump -v8
Hi. Huang, Ying wrote: This patchset provides an enhancement to kexec/kdump. It implements the following features: - Backup/restore memory used both by the original kernel and the kexeced kernel. Why the kexeced kernel as well? [...] The features of this patchset can be used as follow: - Kernel/system debug through making system snapshot. You can make system snapshot, jump back, do some thing and make another system snapshot. Are you somehow recording all the filesystem changes after the first snapshot? If not, this is pointless (you'll end up with filesystem corruption). [...] - Cooperative multi-kernel/system. With kexec jump, you can switch between several kernels/systems quickly without boot process except the first time. This appears like swap a whole kernel/system out/in. How is this useful to the end user? Regards, Nigel -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3 -mm] kexec jump -v8
On Fri, 2007-12-21 at 19:35 +1100, Nigel Cunningham wrote: Hi. Huang, Ying wrote: This patchset provides an enhancement to kexec/kdump. It implements the following features: - Backup/restore memory used both by the original kernel and the kexeced kernel. Why the kexeced kernel as well? The memory range used by kexeced kernel is also the usable memory range in original kernel. Maybe should be: backup/restore memory used by both the original kernel and the kexeced kernel. My English is poor. [...] The features of this patchset can be used as follow: - Kernel/system debug through making system snapshot. You can make system snapshot, jump back, do some thing and make another system snapshot. Are you somehow recording all the filesystem changes after the first snapshot? If not, this is pointless (you'll end up with filesystem corruption). This snapshot is not used for restore/resume. It is just used for debugging. You can check the system state with these snapshots. So I think it is useful even without recording filesystem changes. [...] - Cooperative multi-kernel/system. With kexec jump, you can switch between several kernels/systems quickly without boot process except the first time. This appears like swap a whole kernel/system out/in. How is this useful to the end user? I am not sure how useful is this. Maybe I can run a Redhat and a Debian on my machine and switch between them. Best Regards, Huang Ying -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/3 -mm] kexec jump -v8
This patchset provides an enhancement to kexec/kdump. It implements the following features: - Backup/restore memory used both by the original kernel and the kexeced kernel. - Jumping between the original kernel and the kexeced kernel. - Read/write memory image of the kexeced kernel in the original kernel and write memory image of the original kernel in the kexeced kernel. This can be used as a communication method between the kexeced kernel and the original kernel. The features of this patchset can be used as follow: - Kernel/system debug through making system snapshot. You can make system snapshot, jump back, do some thing and make another system snapshot. - A simple hibernation implementation without ACPI support. You can kexec a hibernating kernel, save the memory image of original system and shutdown the system. When resuming, you boot a resuming kernel in memory range of kexeced kernel, restore the memory image of original system and jump back. - Cooperative multi-kernel/system. With kexec jump, you can switch between several kernels/systems quickly without boot process except the first time. This appears like swap a whole kernel/system out/in. - A general method to call program in physical mode. This can be used to invoke some BIOS code under Linux. - The basis of a full kexec based hibernation implementation with ACPI support. The full kexec based hibernation implementation is provided in another patchset named kexec based hibernation. Now, only the i386 architecture is supported. The patchset is based on Linux kernel 2.6.24-rc5-mm1, and has been tested on IBM T42 with ACPI on and off. The following user-space tools can be used with kexec jump. 1. kexec-tools needs to be patched to support kexec jump. The patches and the precompiled kexec can be download from the following URL: source: http://khibernation.sourceforge.net/download/release_v8/kexec-tools/kexec-tools-src_git_kh8.tar.bz2 patches: http://khibernation.sourceforge.net/download/release_v8/kexec-tools/kexec-tools-patches_git_kh8.tar.bz2 binary: http://khibernation.sourceforge.net/download/release_v8/kexec-tools/kexec_git_kh8 2. makedumpfile with patches are used as memory image saving tool, it can exclude free pages from original kernel memory image file. The patches and the precompiled makedumpfile can be download from the following URL: source: http://khibernation.sourceforge.net/download/release_v8/makedumpfile/makedumpfile-src_cvs_kh8.tar.bz2 patches: http://khibernation.sourceforge.net/download/release_v8/makedumpfile/makedumpfile-patches_cvs_kh8.tar.bz2 binary: http://khibernation.sourceforge.net/download/release_v8/makedumpfile/makedumpfile_cvs_kh8 3. A simplest memory image restoring tool named "krestore" is implemented. It can be downloaded from the following URL: source: http://khibernation.sourceforge.net/download/release_v8/krestore/krestore-src_cvs_kh8.tar.bz2 binary: http://khibernation.sourceforge.net/download/release_v8/krestore/krestore_cvs_kh8 An initramfs image can be used as the root file system of kexeced kernel. An initramfs image built with "BuildRoot" can be downloaded from the following URL: initramfs image: http://khibernation.sourceforge.net/download/release_v8/initramfs/rootfs_cvs_kh8.gz All user space tools above are included in the initramfs image. Usage example of jumping between original and kexeced kernel: 1. Compile and install patched kernel with following options selected: CONFIG_X86_32=y CONFIG_RELOCATABLE=y CONFIG_KEXEC=y CONFIG_CRASH_DUMP=y CONFIG_PM=y 2. Build an initramfs image contains kexec-tool, or download the pre-built initramfs image, called rootfs.gz in following text. 3. Boot kernel compiled in step 1. 4. Load kernel compiled in step 1 with /sbin/kexec. If You want to use "krestore" tool, the --elf64-core-headers should be specified in command line of /sbin/kexec. The shell command line can be as follow: /sbin/kexec --load-jump-back /boot/bzImage --mem-min=0x10 --mem-max=0xff --elf64-core-headers --initrd=rootfs.gz 5. Boot the kexeced kernel with following shell command line: /sbin/kexec -e 6. The kexeced kernel will boot as normal kexec. In kexeced kernel the memory image of original kernel can read via /proc/vmcore or /dev/oldmem, and can be written via /dev/oldmem. You can save/restore/modify it as you want to. 7. Prepare jumping back from kexeced kernel with following shell command lines: jump_back_entry=`cat /proc/cmdline | tr ' ' '\n' | grep kexec_jump_back_entry | cut -d '='` /sbin/kexec --load-jump-back-helper=$jump_back_entry 8. Jump back to the original kernel with following shell command line: /sbin/kexec -e 9. Now, you are in the original kernel again. You can read/write the memory image of kexeced kernel via /proc/kimgcore. 10. You can jump between the original kernel and
[PATCH 0/3 -mm] kexec jump -v8
This patchset provides an enhancement to kexec/kdump. It implements the following features: - Backup/restore memory used both by the original kernel and the kexeced kernel. - Jumping between the original kernel and the kexeced kernel. - Read/write memory image of the kexeced kernel in the original kernel and write memory image of the original kernel in the kexeced kernel. This can be used as a communication method between the kexeced kernel and the original kernel. The features of this patchset can be used as follow: - Kernel/system debug through making system snapshot. You can make system snapshot, jump back, do some thing and make another system snapshot. - A simple hibernation implementation without ACPI support. You can kexec a hibernating kernel, save the memory image of original system and shutdown the system. When resuming, you boot a resuming kernel in memory range of kexeced kernel, restore the memory image of original system and jump back. - Cooperative multi-kernel/system. With kexec jump, you can switch between several kernels/systems quickly without boot process except the first time. This appears like swap a whole kernel/system out/in. - A general method to call program in physical mode. This can be used to invoke some BIOS code under Linux. - The basis of a full kexec based hibernation implementation with ACPI support. The full kexec based hibernation implementation is provided in another patchset named kexec based hibernation. Now, only the i386 architecture is supported. The patchset is based on Linux kernel 2.6.24-rc5-mm1, and has been tested on IBM T42 with ACPI on and off. The following user-space tools can be used with kexec jump. 1. kexec-tools needs to be patched to support kexec jump. The patches and the precompiled kexec can be download from the following URL: source: http://khibernation.sourceforge.net/download/release_v8/kexec-tools/kexec-tools-src_git_kh8.tar.bz2 patches: http://khibernation.sourceforge.net/download/release_v8/kexec-tools/kexec-tools-patches_git_kh8.tar.bz2 binary: http://khibernation.sourceforge.net/download/release_v8/kexec-tools/kexec_git_kh8 2. makedumpfile with patches are used as memory image saving tool, it can exclude free pages from original kernel memory image file. The patches and the precompiled makedumpfile can be download from the following URL: source: http://khibernation.sourceforge.net/download/release_v8/makedumpfile/makedumpfile-src_cvs_kh8.tar.bz2 patches: http://khibernation.sourceforge.net/download/release_v8/makedumpfile/makedumpfile-patches_cvs_kh8.tar.bz2 binary: http://khibernation.sourceforge.net/download/release_v8/makedumpfile/makedumpfile_cvs_kh8 3. A simplest memory image restoring tool named krestore is implemented. It can be downloaded from the following URL: source: http://khibernation.sourceforge.net/download/release_v8/krestore/krestore-src_cvs_kh8.tar.bz2 binary: http://khibernation.sourceforge.net/download/release_v8/krestore/krestore_cvs_kh8 An initramfs image can be used as the root file system of kexeced kernel. An initramfs image built with BuildRoot can be downloaded from the following URL: initramfs image: http://khibernation.sourceforge.net/download/release_v8/initramfs/rootfs_cvs_kh8.gz All user space tools above are included in the initramfs image. Usage example of jumping between original and kexeced kernel: 1. Compile and install patched kernel with following options selected: CONFIG_X86_32=y CONFIG_RELOCATABLE=y CONFIG_KEXEC=y CONFIG_CRASH_DUMP=y CONFIG_PM=y 2. Build an initramfs image contains kexec-tool, or download the pre-built initramfs image, called rootfs.gz in following text. 3. Boot kernel compiled in step 1. 4. Load kernel compiled in step 1 with /sbin/kexec. If You want to use krestore tool, the --elf64-core-headers should be specified in command line of /sbin/kexec. The shell command line can be as follow: /sbin/kexec --load-jump-back /boot/bzImage --mem-min=0x10 --mem-max=0xff --elf64-core-headers --initrd=rootfs.gz 5. Boot the kexeced kernel with following shell command line: /sbin/kexec -e 6. The kexeced kernel will boot as normal kexec. In kexeced kernel the memory image of original kernel can read via /proc/vmcore or /dev/oldmem, and can be written via /dev/oldmem. You can save/restore/modify it as you want to. 7. Prepare jumping back from kexeced kernel with following shell command lines: jump_back_entry=`cat /proc/cmdline | tr ' ' '\n' | grep kexec_jump_back_entry | cut -d '='` /sbin/kexec --load-jump-back-helper=$jump_back_entry 8. Jump back to the original kernel with following shell command line: /sbin/kexec -e 9. Now, you are in the original kernel again. You can read/write the memory image of kexeced kernel via /proc/kimgcore. 10. You can jump between the original kernel and kexeced
