Re: [RFC][PATCH 1/2 -mm] kexec based hibernation -v3: kexec jump

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
From: Eric W. Biederman
Date: Thursday, September 20, 2007 - 7:55 pm

"Huang, Ying" <ying.huang@intel.com> writes:


Well this we have an implementation of (it's called shutdown) or does
that method not do enough to meet the requirements of hibernation.
If at all possible I would like to keep reboot, kexec and kexec+return
all using the same device driver methods.


Makes a reasonable amount of sense.  We do need to save whatever
state we cannot recover just be reprogramming the hardware.
As long as the drivers are built so this is a good place for a
hot remove to happen we should be in good shape.


At least for now that sounds like a reasonable work around.

I don't think we want to merge this code until we have agreed upon
how the new device_detach and device_reattach (or whatever we call the
device methods for hibernate) are to be implemented.


That does not sound correct.  The current implementation of kexec_load
does allocate a source page and give it a destination page and usually
those two pages are different.  But if our memory allocations happen
to return a destination page there we use it directly, making no
copy necessary.

I think we are talking about the same thing but I'm not certain
you have thought about the case where your shadow backup page happens
to be the same as current page.


Ok.  This sounds like the existing implementation.  Except it
depending on your destination it may force the address.


Yes.  Unless we happen to have everything allocated on the same page.
Does your code handle that case?  I know the generic kexec code will
pass lists like that in the proper circumstances.  Especially for
the kexec on panic case.


Yes.   That sounds right.


Bleh.  We do need to document the requirements but we don't need a
versioned monster.  And we don't need to be exposing implementation
details in that documentation.

In the kexec world /sbin/kexec or another user space caller is
responsible for passing information to our callers.

To be polite we need to document more but the jump back protocol
really should be as if the entry point kexec handed control to did
a subroutine return.


It shouldn't be needed.


Reasonable.


Why don't we have a problem with this in the normal kexec case?


More comments below.


Please remove the unnecessary and incorrect include.


It looks like we are doing swap_pages unconditionally so I don't
see why we need to versions of this function.

And it looks like the NORET_TYPE is no longer an accurate description.



This bit really looks wrong.  It is for /sbin/kexec to provide this
kind of interface.


Ok.  This looks reasonable.  So we can reorder the pages in a non-destructive
way.

We should not need this.

I'm still not quite convinced that we need a separate entry point for this.
But until we split out the hibernation methods, it seems reasonable.


Please no.

Why do we need to touch setup.c?


This is an implementation detail that we should not need to export.
I do think having a specification of the requirements for returning to
the kexec kernel makes sense.  I don't however believe that we need to
pass any information.  The map of the pages that matter is simply 
the memory the kernel is using from /proc/iomem  - the memory that
your image you are loading with kexec is using.

All of that information we can pass in /sbin/kexec and should not
need to do directly from the kernel.

The following piece of code should be always be a valid kexec on
jump user and test case.

test_kexec_jump_payload:
	ret

A standard subroutine call return on whichever architecture we are
working on should be sufficient.

For the registers and the segments we should define which ones
should be hard coded, and which ones should be saved.

Hard coded:
%ss, %cs, %ds (4G flat with 0 base)

Callee save:
%esp
%edi
(And whichever ones we care about)

It does make some sense to use the standard kernel argument passing sequence
for bootloaders and what not.  But the wrapper in /sbin/kexec should do that
not the kernel itself.



Eric
-
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
Re: [RFC][PATCH 1/2 -mm] kexec based hibernation -v3: kexe ..., Eric W. Biederman, (Thu Sep 20, 7:55 pm)
Re: [RFC][PATCH 1/2 -mm] kexec based hibernation -v3: kexe ..., Eric W. Biederman, (Thu Sep 20, 8:33 pm)
Re: [RFC][PATCH 1/2 -mm] kexec based hibernation -v3: kexe ..., Eric W. Biederman, (Thu Sep 20, 9:01 pm)
Re: [RFC][PATCH 1/2 -mm] kexec based hibernation -v3: kexe ..., Eric W. Biederman, (Thu Sep 20, 9:46 pm)
Re: [RFC][PATCH 1/2 -mm] kexec based hibernation -v3: kexe ..., Rafael J. Wysocki, (Fri Sep 21, 4:56 am)
Re: [linux-pm] Re: [RFC][PATCH 1/2 -mm] kexec based hibern ..., Rafael J. Wysocki, (Fri Sep 21, 5:09 am)
Re: [linux-pm] Re: [RFC][PATCH 1/2 -mm] kexec based hibern ..., Rafael J. Wysocki, (Fri Sep 21, 5:10 am)
Re: [RFC][PATCH 1/2 -mm] kexec based hibernation -v3: kexe ..., Rafael J. Wysocki, (Fri Sep 21, 5:18 am)
Re: [linux-pm] Re: [RFC][PATCH 1/2 -mm] kexec based hibern ..., Rafael J. Wysocki, (Fri Sep 21, 7:31 am)
Re: [linux-pm] Re: [RFC][PATCH 1/2 -mm] kexec based hibern ..., Rafael J. Wysocki, (Fri Sep 21, 8:50 am)
Re: [linux-pm] Re: [RFC][PATCH 1/2 -mm] kexec based hibern ..., Jeremy Maitin-Shepard, (Fri Sep 21, 11:11 am)
Re: [linux-pm] Re: [RFC][PATCH 1/2 -mm] kexec based hibern ..., Rafael J. Wysocki, (Fri Sep 21, 12:00 pm)
Re: [linux-pm] Re: [RFC][PATCH 1/2 -mm] kexec based hibern ..., Rafael J. Wysocki, (Fri Sep 21, 1:15 pm)
Re: [linux-pm] Re: [RFC][PATCH 1/2 -mm] kexec based hibern ..., Jeremy Maitin-Shepard, (Fri Sep 21, 1:26 pm)
Re: [linux-pm] Re: [RFC][PATCH 1/2 -mm] kexec based hibern ..., Rafael J. Wysocki, (Fri Sep 21, 1:53 pm)
Re: [linux-pm] Re: [RFC][PATCH 1/2 -mm] kexec based hibern ..., Jeremy Maitin-Shepard, (Fri Sep 21, 2:08 pm)
Re: [linux-pm] Re: [RFC][PATCH 1/2 -mm] kexec based hibern ..., Jeremy Maitin-Shepard, (Fri Sep 21, 2:16 pm)
Re: [linux-pm] Re: [RFC][PATCH 1/2 -mm] kexec based hibern ..., Rafael J. Wysocki, (Fri Sep 21, 2:25 pm)
Re: [linux-pm] Re: [RFC][PATCH 1/2 -mm] kexec based hibern ..., Rafael J. Wysocki, (Sat Sep 22, 3:34 am)
Re: [linux-pm] Re: [RFC][PATCH 1/2 -mm] kexec based hibern ..., Rafael J. Wysocki, (Sat Sep 22, 3:40 am)
Re: [linux-pm] Re: [RFC][PATCH 1/2 -mm] kexec based hibern ..., Rafael J. Wysocki, (Sat Sep 22, 2:51 pm)
Re: [RFC][PATCH 1/2 -mm] kexec based hibernation -v3: kexe ..., Nigel Cunningham, (Wed Sep 26, 11:35 pm)
Re: [linux-pm] Re: [RFC][PATCH 1/2 -mm] kexec based hibern ..., Rafael J. Wysocki, (Wed Oct 24, 1:38 pm)