All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vivek Goyal <vgoyal@redhat.com>
To: "Huang, Ying" <ying.huang@intel.com>
Cc: nigel@nigel.suspend2.net,
	Kexec Mailing List <kexec@lists.infradead.org>,
	linux-kernel@vger.kernel.org, "Rafael J. Wysocki" <rjw@sisk.pl>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	Pavel Machek <pavel@ucw.cz>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH] kexec based hibernation: a prototype of kexec multi-stage load
Date: Fri, 16 May 2008 09:36:58 -0400	[thread overview]
Message-ID: <20080516133658.GE6926@redhat.com> (raw)
In-Reply-To: <1210913568.23707.230.camel@caritas-dev.intel.com>

On Fri, May 16, 2008 at 12:52:48PM +0800, Huang, Ying wrote:
> On Thu, 2008-05-15 at 19:55 -0700, Eric W. Biederman wrote:
> > "Huang, Ying" <ying.huang@intel.com> writes:
> > 
> > > The disadvantage of this solution is that kernel B must know it is
> > > original kernel (A) or kexeced kernel (B). Different code should be used
> > > by kernel A and kernel B. And after jump from A to B, jump from B to A,
> > > when jump from A to B again, kernel A must use different code from the
> > > first time.
> > 
> > I don't know what the case is for keeping two kernels in memory and switching
> > between them.
> 
> This can be used to save the memory image of kernel B and accelerate the
> hibernation. The real boot of kernel B is only needed first time.
> 
> > I suspect a small piece of trampoline code between the two kernels could
> > handle the case. (i.e. purgatory pays attention).
> > 
> > That is a fundamental aspect of the design.  A general purpose infrastructure
> > with trampoline code to adapt it to whatever situation comes up.
> 
> It is possible to use purgatory to deal with this problem.
> 
> Jump from kernel A to kernel B
>     Jump to entry of purgatory (purgatory_entry)
>     purgatory save the return address (kexec_jump_back_entry_A)
>     Purgatory set kexec_jump_back_entry for kernel B to a code
>         segment in purgatory, say kexec_jump_back_entry_A_for_B
>     Purgatory jump to entry point of kernel B
> Jump from kernel B to kernel A
>     Jump to purgatory (kexec_jump_back_entry_A_for_B)
>     Purgatory save the return address (kexec_jump_back_entry_B)
>     Purgatory return to kernel A (kexec_jump_back_entry_A)
> Jump from kernel A to kernel B again
>     Jump to entry of purgatory (purgatory_entry)
>     Purgatory save the return address (kexec_jump_back_entry_A)
>     Purgatory jump to kexec_jump_back_entry_B
> 
> The disadvantage of this solution is that some information is saved in
> purgatory (kexec_jump_back_entry_A, kexec_jump_back_entry_B). So,
> purgatory must be saved too when save the memory image of kernel A or
> kernel B. Purgatory can be seen as a part of kernel B. But it is a
> little tricky to think it as a part of kernel A too.

That's a good point. Remembering the actual return points in purgatory
will require purgatory to be saved along with core file.

I think, purgatory is a good infrastructure for transitions between the
kernels but at the same time, here it is a matter of just making a "call"
and then inspecting the stack in kexec_jump_back_entry. IMHO, we can keep it
simple and not involving purgatory in later transitions.

Thanks
Vivek

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

WARNING: multiple messages have this Message-ID (diff)
From: Vivek Goyal <vgoyal@redhat.com>
To: "Huang, Ying" <ying.huang@intel.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>,
	Pavel Machek <pavel@ucw.cz>,
	nigel@nigel.suspend2.net, "Rafael J. Wysocki" <rjw@sisk.pl>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org,
	Kexec Mailing List <kexec@lists.infradead.org>
Subject: Re: [PATCH] kexec based hibernation: a prototype of kexec multi-stage load
Date: Fri, 16 May 2008 09:36:58 -0400	[thread overview]
Message-ID: <20080516133658.GE6926@redhat.com> (raw)
In-Reply-To: <1210913568.23707.230.camel@caritas-dev.intel.com>

On Fri, May 16, 2008 at 12:52:48PM +0800, Huang, Ying wrote:
> On Thu, 2008-05-15 at 19:55 -0700, Eric W. Biederman wrote:
> > "Huang, Ying" <ying.huang@intel.com> writes:
> > 
> > > The disadvantage of this solution is that kernel B must know it is
> > > original kernel (A) or kexeced kernel (B). Different code should be used
> > > by kernel A and kernel B. And after jump from A to B, jump from B to A,
> > > when jump from A to B again, kernel A must use different code from the
> > > first time.
> > 
> > I don't know what the case is for keeping two kernels in memory and switching
> > between them.
> 
> This can be used to save the memory image of kernel B and accelerate the
> hibernation. The real boot of kernel B is only needed first time.
> 
> > I suspect a small piece of trampoline code between the two kernels could
> > handle the case. (i.e. purgatory pays attention).
> > 
> > That is a fundamental aspect of the design.  A general purpose infrastructure
> > with trampoline code to adapt it to whatever situation comes up.
> 
> It is possible to use purgatory to deal with this problem.
> 
> Jump from kernel A to kernel B
>     Jump to entry of purgatory (purgatory_entry)
>     purgatory save the return address (kexec_jump_back_entry_A)
>     Purgatory set kexec_jump_back_entry for kernel B to a code
>         segment in purgatory, say kexec_jump_back_entry_A_for_B
>     Purgatory jump to entry point of kernel B
> Jump from kernel B to kernel A
>     Jump to purgatory (kexec_jump_back_entry_A_for_B)
>     Purgatory save the return address (kexec_jump_back_entry_B)
>     Purgatory return to kernel A (kexec_jump_back_entry_A)
> Jump from kernel A to kernel B again
>     Jump to entry of purgatory (purgatory_entry)
>     Purgatory save the return address (kexec_jump_back_entry_A)
>     Purgatory jump to kexec_jump_back_entry_B
> 
> The disadvantage of this solution is that some information is saved in
> purgatory (kexec_jump_back_entry_A, kexec_jump_back_entry_B). So,
> purgatory must be saved too when save the memory image of kernel A or
> kernel B. Purgatory can be seen as a part of kernel B. But it is a
> little tricky to think it as a part of kernel A too.

That's a good point. Remembering the actual return points in purgatory
will require purgatory to be saved along with core file.

I think, purgatory is a good infrastructure for transitions between the
kernels but at the same time, here it is a matter of just making a "call"
and then inspecting the stack in kexec_jump_back_entry. IMHO, we can keep it
simple and not involving purgatory in later transitions.

Thanks
Vivek

  reply	other threads:[~2008-05-16 13:37 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-12  6:40 [PATCH] kexec based hibernation: a prototype of kexec multi-stage load Huang, Ying
2008-05-12  6:40 ` Huang, Ying
2008-05-13  5:34 ` Vivek Goyal
2008-05-13  5:34   ` Vivek Goyal
2008-05-14  1:57   ` Huang, Ying
2008-05-14  1:57     ` Huang, Ying
2008-05-14  2:56     ` Vivek Goyal
2008-05-14  2:56       ` Vivek Goyal
2008-05-14  3:37       ` Huang, Ying
2008-05-14  3:37         ` Huang, Ying
2008-05-14 21:43         ` Eric W. Biederman
2008-05-14 21:43           ` Eric W. Biederman
2008-05-15  2:40           ` Huang, Ying
2008-05-15  2:40             ` Huang, Ying
2008-05-15  4:57           ` Huang, Ying
2008-05-15  4:57             ` Huang, Ying
2008-05-15 18:39             ` Eric W. Biederman
2008-05-15 18:39               ` Eric W. Biederman
2008-05-16  1:41               ` Huang, Ying
2008-05-16  1:41                 ` Huang, Ying
2008-05-16  2:25                 ` Eric W. Biederman
2008-05-16  2:25                   ` Eric W. Biederman
2008-05-16  2:56                   ` Huang, Ying
2008-05-16  2:56                     ` Huang, Ying
2008-05-16  3:27                     ` Vivek Goyal
2008-05-16  3:27                       ` Vivek Goyal
2008-05-16 13:40                       ` Vivek Goyal
2008-05-16 13:40                         ` Vivek Goyal
2008-05-18  1:59                       ` Eric W. Biederman
2008-05-18  1:59                         ` Eric W. Biederman
2008-05-16  3:33                     ` Eric W. Biederman
2008-05-16  3:33                       ` Eric W. Biederman
2008-05-16  2:00             ` Vivek Goyal
2008-05-16  2:00               ` Vivek Goyal
2008-05-16  2:19               ` Huang, Ying
2008-05-16  2:19                 ` Huang, Ying
2008-05-16  2:55                 ` Eric W. Biederman
2008-05-16  2:55                   ` Eric W. Biederman
2008-05-16  4:52                   ` Huang, Ying
2008-05-16  4:52                     ` Huang, Ying
2008-05-16 13:36                     ` Vivek Goyal [this message]
2008-05-16 13:36                       ` Vivek Goyal
2008-05-16 11:58   ` Pavel Machek
2008-05-16 11:58     ` Pavel Machek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080516133658.GE6926@redhat.com \
    --to=vgoyal@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=ebiederm@xmission.com \
    --cc=kexec@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nigel@nigel.suspend2.net \
    --cc=pavel@ucw.cz \
    --cc=rjw@sisk.pl \
    --cc=ying.huang@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.