Message-Id: <1206429910.29518.32.camel@caritas-dev.intel.com>
Date:	Tue, 25 Mar 2008 15:25:10 +0800
From:	"Huang, Ying" <ying.huang@...el.com>
To:	Vivek Goyal <vgoyal@...hat.com>
Cc:	nigel@...el.suspend2.net,
	Kexec Mailing List <kexec@...ts.infradead.org>,
	linux-kernel@...r.kernel.org, "Rafael J. Wysocki" <rjw@...k.pl>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Pavel Machek <pavel@....cz>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-pm@...ts.linux-foundation.org
Subject: Re: [PATCH -mm] kexec jump -v9

On Fri, 2008-03-21 at 15:12 -0400, Vivek Goyal wrote:
[...]
> Hi Huang,
> 
> I am kind of ok with both the methods.
> 
> - Communicate information between two kernels using an ELF NOTE
>   prepared by kernel.
> 
> - Communicate information between user space tools using initrd.

I think the ELF_NOTES mechanism is sufficient for communication between
two kernel. Because it can be written from user space tool in the kernel
A (/sbin/kexec via sys_kexec_load), and read from user space tool in the
kernel B (via /proc/vmcore). It can be used as user space communication
mechanism. So I think it may be not necessary to communicate with
initrd.

If we want to load the hibernated image with sys_kexec_load (/sbin/kexec
-l), we must add "multiple stages loading" feature to sys_kexec_load.
Because the segments in the hibernated image can exceed
KEXEC_SEGMENT_MAX (16) easily, considering there will be many memory
holes when free pages are excluded. Multiple sys_kexec_load must be used
to load a normal hibernated image. If multiple stage loading is
unavoidable, I think the better method to communicate information like
"jump back entry" and "backup pages map" is "multiple stage loading"
like you said in previous mail. And they can be encapsulated as
ELF_NOTES. So the only information need to be passed on stack is address
of ELF core header.

> But which method to use will depend on what information we want to 
> exchange between two kernels. 
> 
> For example, re-entry points can be on stack or in ELF NOTE.
> 
> Backup page map probably can be communicated using initrd as only user
> space need to access that (ELF Core headers can be put in a memory area
> which is not swapped during transition from kernel A to B. This way
> kernel B never needs to know that kernel A had done some swapping of
> pages?). 

ELF core headers are in destination memory range of kernel B, so they
can be accessed by kernel B directly without knowing pages swapping in
kernel A.

> So far I have understood only following.
> 
> 1. We need to pass around entry/re-entry points between kernels.
> 
> 2. We need to pass backup pages map from kernel A to kernel B, so that user
>   space tool can do filtering.
> 
> 3. We need to pass address of ELF core headers from kernel A to kernel B so
>   that a valid vmcore of kernel A can be exported.
> 
> 	- For first time boot of kernel B, address of ELF core header is
> 	  passed through command line.
> 
> 	- For re-entry into B, ELF core header address can be passed
>  	  using some register, or on stack or using kernel ELF NOTE.
> 
> What else? What information do we need to communicate from kernel B to 
> kernel A or from kernel C to kernel A?
> 
> I am sure that you have told it in the past. Just that I don't recollect
> it.

For now, there is no information need to be passed from kernel B/C to
kernel A. But I think in the future, there should be some ACPI related
information need to be passed in this way, such as from kernel C to
kernel A: whether system is restored from ACPI S4 or ACPI S5. So I think
it is necessary to make it possible to pass some information from kernel
B/C to kernel A. But I think an ELF core header and some memory is
sufficient to do this.

Best Regards,
Huang Ying

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists