Re: [PATCH 1/2] kexec: Add quick kexec support for kernel
Hi!
> +config QUICK_KEXEC
> + bool "Support for quick kexec"
> + depends on KEXEC_CORE
> + help
> + Say y here to enable this feature.
?
> + It use reserved memory to accelerate kexec, just like crash
uses
> + kexec, load new kernel and initrd to reserved memory, and
> + boot new kernel on that memory. It will save the time of
> + relocating kernel.
loads a new boots new...
> IORES_DESC_DEVICE_PRIVATE_MEMORY= 6,
> IORES_DESC_RESERVED = 7,
> IORES_DESC_SOFT_RESERVED= 8,
> +#ifdef CONFIG_QUICK_KEXEC
> + IORES_DESC_QUICK_KEXEC = 9,
> +#endif
> };
Remove ifdef.
> /*
> diff --git a/include/linux/kexec.h b/include/linux/kexec.h
> index 9e93bef52968..976bf9631070 100644
> --- a/include/linux/kexec.h
> +++ b/include/linux/kexec.h
> @@ -269,9 +269,12 @@ struct kimage {
> unsigned long control_page;
>
> /* Flags to indicate special processing */
> - unsigned int type : 1;
> + unsigned int type : 2;
> #define KEXEC_TYPE_DEFAULT 0
> #define KEXEC_TYPE_CRASH 1
> +#ifdef CONFIG_QUICK_KEXEC
> +#define KEXEC_TYPE_QUICK 2
> +#endif
> unsigned int preserve_context : 1;
Here, too.
> +++ b/include/uapi/linux/kexec.h
> @@ -12,6 +12,9 @@
> /* kexec flags for different usage scenarios */
> #define KEXEC_ON_CRASH 0x0001
> #define KEXEC_PRESERVE_CONTEXT 0x0002
> +#ifdef CONFIG_QUICK_KEXEC
> +#define KEXEC_QUICK 0x0004
> +#endif
> #define KEXEC_ARCH_MASK 0x
And here.
Pavel
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH 4.19 159/219] x86/crash: Add a forward declaration of struct kimage
On Sun 2019-12-29 18:19:21, Greg Kroah-Hartman wrote: > From: Lianbo Jiang > > [ Upstream commit 112eee5d06007dae561f14458bde7f2a4879ef4e ] > > Add a forward declaration of struct kimage to the crash.h header because > future changes will invoke a crash-specific function from the realmode > init path and the compiler will complain otherwise like this: > > In file included from arch/x86/realmode/init.c:11: > ./arch/x86/include/asm/crash.h:5:32: warning: ‘struct kimage’ declared > inside\ This is not needed in 4.19-stable, as 6f599d84231fd27e42f4ca2a786a6641e8cddf00 is not being backported there. (But is simple enough not to do harm). Best regards, Pavel > @@ -2,6 +2,8 @@ > #ifndef _ASM_X86_CRASH_H > #define _ASM_X86_CRASH_H > > +struct kimage; > + > int crash_load_segments(struct kimage *image); > int crash_copy_backup_region(struct kimage *image); > int crash_setup_memmap_entries(struct kimage *image, -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v1 7/8] PM / Hibernate: use pfn_to_online_page()
On Mon 2018-11-19 11:16:15, David Hildenbrand wrote: > Let's use pfn_to_online_page() instead of pfn_to_page() when checking > for saveable pages to not save/restore offline memory sections. > > Cc: "Rafael J. Wysocki" Acked-by: Pavel Machek -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH] kdump: update kexec-tools URL and Vivek's email
On Thu 2010-11-25 10:30:12, Simon Horman wrote: Signed-off-by: Simon Horman ho...@verge.net.au Thanks! --- Documentation/kdump/kdump.txt | 15 +-- 1 files changed, 9 insertions(+), 6 deletions(-) diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt index cab61d8..7a9e0b4 100644 --- a/Documentation/kdump/kdump.txt +++ b/Documentation/kdump/kdump.txt @@ -65,18 +65,21 @@ Install kexec-tools 2) Download the kexec-tools user-space package from the following URL: -http://www.kernel.org/pub/linux/kernel/people/horms/kexec-tools/kexec-tools.tar.gz +http://kernel.org/pub/linux/utils/kernel/kexec/kexec-tools.tar.gz This is a symlink to the latest version. The latest kexec-tools git tree is available at: -git://git.kernel.org/pub/scm/linux/kernel/git/horms/kexec-tools.git -or -http://www.kernel.org/git/?p=linux/kernel/git/horms/kexec-tools.git +git://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git +and +http://www.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git + +There is also a gitweb interface available at +http://www.kernel.org/git/?p=utils/kernel/kexec/kexec-tools.git More information about kexec-tools can be found at -http://www.kernel.org/pub/linux/kernel/people/horms/kexec-tools/README.html +http://www.kernel.org/pub/linux/utils/kernel/kexec/README.html 3) Unpack the tarball with the tar command, as follows: @@ -439,6 +442,6 @@ To Do Contact === -Vivek Goyal (vgo...@in.ibm.com) +Vivek Goyal (vgo...@redhat.com) Maneesh Soni (mane...@in.ibm.com) ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH 09/15] x86: Emergency virtualization disable function
Hi! --- /dev/null +++ b/arch/x86/kernel/virtext.c @@ -0,0 +1,89 @@ +/* Core CPU virtualization extensions handling + * + * This should carry the code for handling CPU virtualization extensions + * that needs to live in the kernel core. + * + * Author: Eduardo Habkost [EMAIL PROTECTED] + * + * Copyright (C) 2008, Red Hat Inc. + */ GPL? Yes, of course. As IANAL, I used a similar .c file as reference for the author/copyright info header, and used arch/x86/kernel/crash.c, that doesn't refer to the GPL also. I think I chose a bad example as reference. arch/x86/kernel/crash.c even has All rights reserved. Ouch. Yep, that should be fixed. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH 09/15] x86: Emergency virtualization disable function
On Wed 2008-11-05 17:56:52, Eduardo Habkost wrote: This patch adds an interface to set a function that can be used to disable virtualization extensions on the CPU on emergency cases, such as on kdump or emergency reboot. The function will be set by code that enables virtualization extensions on the CPUs (i.e. KVM), and should do the very least to disable virt extensions on the CPU where it is being called. The functions that set the function pointer uses RCU synchronization, just in case the crash NMI is triggered while KVM is unloading. We can't just use the same notifiers used at reboot time (that are used by non-crash-dump kexec), because at crash time some CPUs may have IRQs disabled, so we can't use IPIs. The crash shutdown code use NMIs to tell the other CPUs to be halted, so the notifier call will be hooked into the CPU halting code that is on the crash shutdown NMI handler. [v2: drop 'unsigned int cpu' arg from function] [v3: make emergency_virt_disable() non-static] [v4: add a config option for it: CPU_VIRT_EXTENSIONS] [v5: add has_virt_extensions() function] [v6: don't define the registering functions if CPU_VIRT_EXTENSIONS is not enabled] [v7: use EXPORT_SYMBOL_GPL] --- /dev/null +++ b/arch/x86/kernel/virtext.c @@ -0,0 +1,89 @@ +/* Core CPU virtualization extensions handling + * + * This should carry the code for handling CPU virtualization extensions + * that needs to live in the kernel core. + * + * Author: Eduardo Habkost [EMAIL PROTECTED] + * + * Copyright (C) 2008, Red Hat Inc. + */ GPL? -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH -v3 5/7] kexec jump: in sync with hibernation implementation
On Tue 2008-08-12 11:14:33, Huang Ying wrote: Add device_pm_lock() and device_pm_unlock() in kernel_kexec() in sync with current hibernation implementation. Signed-off-by: Huang Ying [EMAIL PROTECTED] Acked-by: Pavel Machek [EMAIL PROTECTED] -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH 1/6] kexec jump: clean up #ifdef and comments
Hi! CONFIG_KEXEC_JUMP to make code looks cleaner. Fix no longer correct comments of kernel_kexec(). Signed-off-by: Huang Ying [EMAIL PROTECTED] --- kernel/kexec.c | 11 +-- 1 file changed, 5 insertions(+), 6 deletions(-) --- a/kernel/kexec.c +++ b/kernel/kexec.c @@ -1427,8 +1427,6 @@ static int __init crash_save_vmcoreinfo_ module_init(crash_save_vmcoreinfo_init) /** - * kernel_kexec - reboot the system - * * Move into place and start executing a preloaded standalone * executable. If nothing was preloaded return an error. */ If it is not kerneldoc, it should not be /** . Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH 2/6] kexec jump: check code size in control page
Kexec/Kexec-jump requires code size in control page is less than PAGE_SIZE/2. This patch adds runtime checking for this. Signed-off-by: Huang Ying [EMAIL PROTECTED] ACK. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH 3/6] kexec jump: remove duplication of kexec_restart_prepare()
Call kernel_restart_prepare() in kernel_kexec() instead of duplicating the code. Signed-off-by: Huang Ying [EMAIL PROTECTED] ACK. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH 4/6] kexec jump: in sync with hibernation implementation
Add device_pm_lock() and device_pm_unlock() in kernel_kexec() to be in sync with current hibernation implementation. Signed-off-by: Huang Ying [EMAIL PROTECTED] --- kernel/kexec.c |2 ++ 1 file changed, 2 insertions(+) --- a/kernel/kexec.c +++ b/kernel/kexec.c @@ -1457,6 +1457,7 @@ int kernel_kexec(void) error = disable_nonboot_cpus(); if (error) goto Resume_devices; + device_pm_lock(); local_irq_disable(); /* At this point, device_suspend() has been called, * but *not* device_power_down(). We *must* @@ -1485,6 +1486,7 @@ int kernel_kexec(void) device_power_up(PMSG_RESTORE); Enable_irqs: local_irq_enable(); + device_pm_unlock(); enable_nonboot_cpus(); Resume_devices: device_resume(PMSG_RESTORE); Would it be possible to create common function for hibernation and kexec? Keeping complex stuff like this in sync is ugly. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH 6/6] kexec jump: fix for ftrace
Restore ftrace after jumping back from kexeced kernel.
Signed-off-by: Huang Ying [EMAIL PROTECTED]
---
arch/x86/kernel/machine_kexec_32.c | 19 +++
kernel/kexec.c |2 --
2 files changed, 19 insertions(+), 2 deletions(-)
@@ -124,7 +126,15 @@ void machine_kexec(struct kimage *image)
unsigned int has_pae,
unsigned int preserve_context);
+#ifdef CONFIG_KEXEC_JUMP
+ if (kexec_image-preserve_context)
+ save_processor_state();
+#endif
+
+#ifdef CONFIG_FTRACE
+ save_ftrace_enabled = ftrace_enabled;
tracer_disable();
+#endif
/* Interrupts aren't acceptable while we reboot */
raw_local_irq_disable();
The patch does way more than its changelog says...
Pavel
@@ -182,6 +192,15 @@ void machine_kexec(struct kimage *image)
(unsigned long)page_list,
image-start, cpu_has_pae,
image-preserve_context);
+
+#ifdef CONFIG_KEXEC_JUMP
+ if (kexec_image-preserve_context)
+ restore_processor_state();
+#endif
+
+#ifdef CONFIG_FTRACE
+ ftrace_enabled = save_ftrace_enabled;
+#endif
}
void arch_crash_save_vmcoreinfo(void)
--- a/kernel/kexec.c
+++ b/kernel/kexec.c
@@ -1469,7 +1469,6 @@ int kernel_kexec(void)
error = device_power_down(PMSG_FREEZE);
if (error)
goto Enable_irqs;
- save_processor_state();
} else
#endif
{
@@ -1482,7 +1481,6 @@ int kernel_kexec(void)
#ifdef CONFIG_KEXEC_JUMP
if (kexec_image-preserve_context) {
- restore_processor_state();
device_power_up(PMSG_RESTORE);
Enable_irqs:
local_irq_enable();
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH 2/6] kexec jump: check code size in control page
Hi!
PAGE_SIZE/2. This patch adds runtime checking for this.
Signed-off-by: Huang Ying [EMAIL PROTECTED]
...
{
if (nx_enabled)
set_pages_x(image-control_code_page, 1);
+
+ BUG_ON((unsigned long)kexec_control_page_code_end - \
+ (unsigned long)relocate_kernel = PAGE_SIZE/2);
+
Run time check is better than nothing but I think in this case it would
be better if we can catch it at compile time.
One of the methods will be to write a small program of your own and
put in script/ and at build time check for the size and flag error. May
be there are other better ways to do this.
BUILD_BUG_ON()?
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH -mm 1/2] kexec jump -v12: kexec jump
On Mon, Jul 14, 2008 at 07:46:44AM +0200, Pavel Machek wrote: On Sat 2008-07-12 11:02:17, Nigel Cunningham wrote: Hi. On Fri, 2008-07-11 at 16:11 -0400, Vivek Goyal wrote: Hi Andrew, We can use this patchset for hibernation, but can it be a better way of doing things than what we already have, I don't know. Last time I had raised this question and power people had various views. In the end, Pavel wanted this patchset to be in. Pavel, can tell more here... To me this patchset looks interesting for couple of reasons. - Looks like an interesting feature where one can have a separate kernel in memory and one can switch between the kernels on the fly. It can be modified to have more than one kernel in memory at a time. I'm not sure how useful that would be, though. I already have functionality in TuxOnIce which allows you to resume a different image instead of powering off (roughly the same thing when combined with not removing the image after resuming). It was neat when testing to be able Beaty of kjump is that it is supposed to used on half-broken system, so it is useful for debugging. What do you mean by supposed to be used on half-broken system? Maybe some network driver went wrong (but rest of machine keeps working), so you want to do kdump but do not want to kill the machine (as the remaining network drivers make the server useful). Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH -mm 1/2] kexec jump -v12: kexec jump
On Sat 2008-07-12 11:02:17, Nigel Cunningham wrote: Hi. On Fri, 2008-07-11 at 16:11 -0400, Vivek Goyal wrote: Hi Andrew, We can use this patchset for hibernation, but can it be a better way of doing things than what we already have, I don't know. Last time I had raised this question and power people had various views. In the end, Pavel wanted this patchset to be in. Pavel, can tell more here... To me this patchset looks interesting for couple of reasons. - Looks like an interesting feature where one can have a separate kernel in memory and one can switch between the kernels on the fly. It can be modified to have more than one kernel in memory at a time. I'm not sure how useful that would be, though. I already have functionality in TuxOnIce which allows you to resume a different image instead of powering off (roughly the same thing when combined with not removing the image after resuming). It was neat when testing to be able Beaty of kjump is that it is supposed to used on half-broken system, so it is useful for debugging. - So far kexec was one directional. One can only kexec to new kernel and old kernel was gone. Now this patchset makes kexec functionality kind of bidirectional and this looks like logical extension and can lead to intersting use cases in future. Ah. You mean keeping both kernels in memory at the same time? In the above, I was replacing one image with another. Yep, kjump keeps both kernels loaded at the same time. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH -mm 1/2] kexec jump -v12: kexec jump
On Fri 2008-07-11 12:21:31, Andrew Morton wrote: On Tue, 8 Jul 2008 10:50:51 -0400 Vivek Goyal [EMAIL PROTECTED] wrote: On Mon, Jul 07, 2008 at 11:25:22AM +0800, Huang Ying wrote: This patch provides an enhancement to kexec/kdump. It implements the following features: - Backup/restore memory used by the original kernel before/after kexec. - Save/restore CPU state before/after kexec. Hi Huang, In general this patch set looks good enough to live in -mm and get some testing going. To me, adding capability to return back to original kernel looks like a logical extension to kexec functionality. Exciting ;) It's much less code than I expected. I don't think I understand the feature any more. Once upon a time we thought that this might become a new and better (or at least better-code-sharing) way of doing suspend-to-disk. How far are we from that? Well, it will be tricky to get kjump-hibernation right with respect to ACPI, but we should be fairly close to basic hibernation working with this. It has major advantage of not needing refrigerator (and few disadvantages -- like doing aditional boot during suspend). But main reason I'd like kjump to be in is different -- it should be useful to stuff like dump but continue running, etc... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH] kexec based hibernation: a prototype of kexec multi-stage load
Hi! During loading, a hash table mapped from destination page to source page is used instead of original linear mapping implementation. Because the hibernated image may be very large (up to near the size of physical memory), it is very time-consuming to search a source page given the destination page, which is used to check whether an newly allocated page is in the range of allocated destination pages. This seems to be an optimization of kexec so that it becomes efficient in loading large images (containing large number of segments). Probably this can be a separate patch. IMHO, we can just first write a minimal patch where one can just switch between kernels. Once that patch is upstream, we can enhance Yes, please. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH -mm] kexec jump -v9
On Fri 2008-05-16 09:48:34, Huang, Ying wrote: On Thu, 2008-05-15 at 16:09 -0400, Vivek Goyal wrote: [...] Ok, You want to make BIOS calls. We already do that using vm86 mode and use bios real mode interrupts. So why do we need this interface? Or, IOW, how is this interface better? It can call code in 32-bit physical mode in addition to real mode. So It can be used to call EFI runtime service, especially call EFI 64 runtime service under 32-bit kernel or vice versa. The main purpose of kexec jump is for hibernation. But I think if the effort is small, why not support general 32-bit physical mode code call at same time. I believe we should focus on kexecing kernels, first. Only way to prove the effort is small is by having small followup patch, and that needs the two patches separated... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [linux-pm] [PATCH -mm] kexec jump -v9
On Tue 2008-03-18 21:25:27, Eric W. Biederman wrote: Alan Stern [EMAIL PROTECTED] writes: On Wed, 19 Mar 2008, Rafael J. Wysocki wrote: Well, I've been saying that for I-don't-remember-how-long: on my box, if you use S5 instead of entering S4, the fan doesn't work correctly after the resume. Plain and simple. Perhaps there's a problem with our ACPI drivers that causes this to happen, but I have no idea what that can be at the moment. IMO it would be worthwhile to track this down. It's a clear indication that something is wrong somewhere. Could it be connected with the way the boot kernel hands control over to the image kernel? Presumably ACPI isn't prepared to deal with that sort of thing during a boot from S5. It would have to be fooled into thinking the two kernels were one and the same. It should be easy to test if it is a hand over problem, by turning off the laptop by placing it in S5 (shutdown -h now) and then booting same kernel again. Feel free to help with testing. I believe ACPI is simply getting confused by us overwriting memory with that from old image. I don't see how you can emulate it with shutdown. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html pomozte zachranit klanovicky les: http://www.ujezdskystrom.info/ ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH -mm] kexec jump -v9
Hi! The features of this patch can be used for as follow: - 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 restore the memory image of original system via ordinary kexec load then jump back. The main usage of this functionality is for hibernation. I am not sure what has been the conclusion of previous discussions. Rafael/Pavel, does the approach of doing hibernation using a separate kernel holds promise? Its certainly more traditional method of doing hibernation than tricks swsusp currently plays. What exactly are you referring to? Well, traditionaly it is 'A saves B to disk' (like bootloader saves kerneluserspace). In swsusp we have 'kernel saves itself'... which works, too, but is pretty different design. Now, I guess they are some difficulties, like ACPI integration, and some basic drawbacks, like few seconds needed to boot second kernel during suspend. ...OTOH this is probably only chance to eliminate freezer from swsusp... Some facts: * There's no reason to think that we can't use this same mechanism for hibernation (the only difficulty seems to be the handling of devices used for saving the image). Ok, at least kexec makes handling of suspend device easier. Moreover, if this had been the _only_ argument for the $subject functionality, I'd have been against it. Fortunately its not the only one :-). -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH 2/3 -mm] kexec jump -v8 : add write support to oldmem device
Hi!
This patch adds writing support for /dev/oldmem. This can be used to
- Communicate between original kernel and kexeced kernel through write
to some pages in original kernel.
- Restore the memory contents of hibernated system in kexec based
hibernation.
Signed-off-by: Huang Ying [EMAIL PROTECTED]
--- a/arch/x86/kernel/crash_dump_32.c
+++ b/arch/x86/kernel/crash_dump_32.c
+ssize_t write_oldmem_page(unsigned long pfn, const char *buf,
+ size_t csize, unsigned long offset, int
userbuf)
--- a/drivers/char/mem.c
+++ b/drivers/char/mem.c
@@ -348,6 +348,37 @@ static ssize_t read_oldmem(struct file *
}
return read;
}
+
+/*
+ * Write memory corresponding to the old kernel.
+ */
+static ssize_t write_oldmem(struct file *file, const char __user *buf,
+ size_t count, loff_t *ppos)
+{
...
+ rc = write_oldmem_page(pfn, buf, csize, offset, 1);
I believe this is going to break compilation on non-32bit
machines. Or is crashdump only supported on i386?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [linux-pm] Re: [RFC][PATCH 1/2 -mm] kexec based hibernation -v3: kexec jump
Hi! That's certainly possible. We already pass a very small amount of data between the boot and resuming kernels at the moment, and it's done quite simply - by putting the variables we want to 'transfer' in a nosave page/section. Well, if the boot and image kernels are different, which is now possible on x86_64 with some recent patches (currently in -mm), the nosave trick won't work. I guess we should remove the nosave at least from x86-64. If someone tries to use it, he'll get a nasty surprise. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [RFC][PATCH 1/2 -mm] kexec based hibernation -v3: kexec jump
Hi! Sounds doable, as long as you can cope with long command lines (which shouldn't be a biggie). (If you've got a swapfile or parts of a swap partition already in use, it can be quite fragmented). Hmm. This is an interesting problem. Sharing a swap file or a swap partition with the actual swap of user space pages does seem to be a limitation of this approach. Although the fact that it is simple to write to a separate file may be a reasonable compensation. I'm not sure how you'd write it to a separate file. Notice that kjump kernel may not mount journalling filesystems, not even read-only. (Ext3 replays journal in that case). You could pass block numbers from the original kernel... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [RFC][PATCH 2/2 -mm] kexec based hibernation -v3: kexec restore
This patch adds writing support for /dev/oldmem. This is used to restore the memory contents of hibernated system. Signed-off-by: Huang Ying [EMAIL PROTECTED] ACK. (And this can even go in before the patch #1, right?) Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [RFC][PATCH 1/2 -mm] kexec based hibernation: kexec jump
Hi! @@ -94,6 +94,10 @@ unsigned long start_address, unsigned int has_pae) ATTRIB_NORET; +#ifdef CONFIG_KEXEC_JUMP +extern asmlinkage int machine_kexec_real_jump(void *buf); +#endif Is it really neccessery to have ifdef here? It is not necessary. I will fix it in the next version. Looking forward to next version :-). +#define CR3 0x18 +#define CR4 0x1c +#define FLAG 0x20 +#define RET 0x24 Hmm, is this enough? Should it use struct ptregs for normal registers? What about segment registers -- they could change between kernel version. Should some kind of 'version of kjump protocol' be introduced? All preserve registers defined in ABI are saved, I think that is sufficient. The swsusp_arch_suspend saves only these registers too. An extensible inter-kernel kjump protocol and corresponding version number seems sensible. I will work on this. Ok, perhaps that can wait after initial merge. What about CX/DX/fpu state? GDT pointer? Actually I think that you _do_ need to save FPU. You should probably use relevant swsusp parts here. Before and after machine_kexec_jump is called, the save_processor_state() and restore_processor_state() are called, where the MTRR/FPU/GDT/IDT/TR/segments/cr are saved and restored. These two functions come from swsusp. Thanks swsusp guys. :) So I'm blind. Sorry for the noise. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [RFC][PATCH 2/2 -mm] kexec based hibernation: kexec restore
On Mon, 2007-08-27 at 23:31 +0200, Pavel Machek wrote: Hi! This patch adds writing support for /dev/oldmem. This is used to restore the memory contents of hibernated system. Signed-off-by: Huang Ying [EMAIL PROTECTED] +ssize_t write_oldmem_page(unsigned long pfn, const char *buf, + size_t csize, unsigned long offset, int userbuf) Hmm, int userbuf is only ever set to one... Does it make sense to have write_oldmem_page in the separate file? The onl user is mem.c, perhaps it should go there? write_oldmem_page is kept to be consistent with copy_oldmem_page as much as possible. The userbuf is used by copy_oldmem_page too, and write_oldmem_page is in the same file as copy_oldmem_page. I think the consistence between them is reasonable. And the copy_oldmem_page/write_oldmem_page is considered to be architecture dependent. Now, there are different implementations for copy_oldmem_page on different architectures. So I think the copy_oldmem_page/write_oldmem_page should be kept in separate file instead of go mem.c. I thought it may have something to do with consistency. ACK on that one. Perhaps it should be pushed to akpm? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [RFC][PATCH 0/2 -mm] kexec based hibernation
Hi! Does this make sense? Yes, this is a sensible optimization. But I think it may be better to make bootloader load kernel D directly into a specified memory location. For example, we can add a option to kernel command of grub. And, I think we can do more in bootloader. Such as we can prepare two Yes, that would be nice. It will mean quite a bit of work, but I guess it should be the long term goal. Loading restore kernel directly from bootloader means: 1) it is fast -- no need to boot another kernel 2) it is classical way of doing things On the other hand, we loose flexibility that way: 1) it locks you onto one bootloader 2) you no longer have userland there to do uncompression, decryption, etc.. True although for the uncompression and decryption those aren't exactly foreign requirements for bootloaders. Well, uncompression yes, but crypto? What is that, some kind of trusted computing thingie? We do RSA for uswsusp, that may be a bit of problem for a bootloader, but I'm glad bootloaders are bloated already :-). -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [linux-pm] Re: [PATH 1/1] Kexec jump - v2 - kexec jump
Hi! On Thu, 2007-08-16 at 12:26 +0200, Pavel Machek wrote: Ping... is there some next version? I'm stuck at the tools side currently. kexec-1.101 just won't load the kernel properly, and kexec-testing from git does not know -j option. I tried hand-patching it, but got lots of scary rejects. Is there chance for a patch against kexec-testing? I have some other work to do recently. So the next version will delay for some while. :( Ok, I got it to work -- thanks a lot. Yes, acpi=off is mandatory. Unfortunately, thinkpad x60 does not boot with acpi=off (should we add another test to linux firmware kit? Machines should still boot in acpi=off mode...). acpi=off noapic nolapic nosmp makes it boot, and that in turn makes kjump work. Screen is not refreshed on kjump back to original kernel, but I guess that's to be expected. I did not play with framebuffer, yet. Maybe it is time to move kjump functionality into -mm and kexec-testing? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [linux-pm] Re: [PATH 1/1] Kexec jump - v2 - kexec jump
Hi!
+int kexec_flags;
+
+static unsigned long kexec_jump_buf_pfn;
+
+static int __init parse_kexec_jump_buf_pfn(char *arg)
+{
+ if (!arg)
+ return -EINVAL;
+
+ kexec_jump_buf_pfn = memparse(arg, arg);
+ kexec_flags |= KEXEC_FLAGS_IS_KEXECED_KERNEL;
+ return 0;
+}
+early_param(kexec_jump_buf_pfn, parse_kexec_jump_buf_pfn);
This one should be documented, too, I'd guess. (Is that internal,
kernel-to-kernel communication?)
Document will be added in next version too.
Ping... is there some next version?
I'm stuck at the tools side currently. kexec-1.101 just won't load the
kernel properly, and kexec-testing from git does not know -j option. I
tried hand-patching it, but got lots of scary rejects.
Is there chance for a patch against kexec-testing?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
