An alternative: the task that created the container namely, is the parent
(outside the container) of the container init(1). In turn, init(1) creates
a special 'monitor' thread that monitors the restart, and the outside task
reaps the exit status of that thread (and only that thread).
[Hmmm... thi
> Again, how would 'cr' obtain exit status for these tasks, and how would
> it distinguish failure from normal operation?
Here's our solution to this issue.
mcr maintains in its kernel container object an exitcode attribute for
the mcr-restart process. This process is detached from the fork tree
Oren Laadan wrote:
>
> Nathan Lynch wrote:
> > Nathan Lynch wrote:
> >> Oren Laadan wrote:
> >>> Nathan Lynch wrote:
> What doesn't work:
> * restarting a 32-bit task from a 64-bit task and vice versa
> >>> Is there a test to bail if we attempt to checkpoint such tasks ?
> >> No, but I
> More specifically, I envision restart to work like this:
>
> 1) user invokes user-land utility (e.g. "cr --restart ..."
> 2) 'cr' will create a new container
> 3) 'cr' will start a child in that container
process 1 in its private namespaces.
> 4) child will create rest of tree (in kernel or i
Nathan Lynch wrote:
> Nathan Lynch wrote:
>> Oren Laadan wrote:
>>> Nathan Lynch wrote:
What doesn't work:
* restarting a 32-bit task from a 64-bit task and vice versa
>>> Is there a test to bail if we attempt to checkpoint such tasks ?
>> No, but I'll add one if it looks too hard to f
Nathan Lynch wrote:
> On Tue, 24 Feb 2009 13:58:26 -0600
> "Serge E. Hallyn" wrote:
>
>> Quoting Nathan Lynch (n...@pobox.com):
>>> Nathan Lynch wrote:
Oren Laadan wrote:
> Nathan Lynch wrote:
>> What doesn't work:
>> * restarting a 32-bit task from a 64-bit task and vice vers
On Tue, 24 Feb 2009 13:58:26 -0600
"Serge E. Hallyn" wrote:
> Quoting Nathan Lynch (n...@pobox.com):
> > Nathan Lynch wrote:
> > >
> > > Oren Laadan wrote:
> > > >
> > > > Nathan Lynch wrote:
> > > > >
> > > > > What doesn't work:
> > > > > * restarting a 32-bit task from a 64-bit task and vic
Quoting Nathan Lynch (n...@pobox.com):
> Nathan Lynch wrote:
> >
> > Oren Laadan wrote:
> > >
> > > Nathan Lynch wrote:
> > > >
> > > > What doesn't work:
> > > > * restarting a 32-bit task from a 64-bit task and vice versa
> > >
> > > Is there a test to bail if we attempt to checkpoint such ta
Nathan Lynch wrote:
>
> Oren Laadan wrote:
> >
> > Nathan Lynch wrote:
> > >
> > > What doesn't work:
> > > * restarting a 32-bit task from a 64-bit task and vice versa
> >
> > Is there a test to bail if we attempt to checkpoint such tasks ?
>
> No, but I'll add one if it looks too hard to fix
> Absolutely, but the accepted way to handle that so far is that if
> you want to run an "incompatible" checkpoint image on a new cpu,
> a userspace program will rewrite the image to be correct for the target
> cpu.
That doesn't sound nice and definitely not something we want to do on
PowerPC. Th
Quoting Benjamin Herrenschmidt (b...@kernel.crashing.org):
> On Wed, 2009-02-04 at 18:44 -0500, Oren Laadan wrote:
> > * Anything that is decided at compiled time should probably go to the arch-
> > dependent header.
> >
> > * Anything that can change at boot time (e.g., for x86 that would include
Benjamin Herrenschmidt wrote:
> On Wed, 2009-02-04 at 18:44 -0500, Oren Laadan wrote:
>> * Anything that is decided at compiled time should probably go to the arch-
>> dependent header.
>>
>> * Anything that can change at boot time (e.g., for x86 that would include
>> the capabilities of the FPU)
On Wed, 2009-02-04 at 18:44 -0500, Oren Laadan wrote:
> * Anything that is decided at compiled time should probably go to the arch-
> dependent header.
>
> * Anything that can change at boot time (e.g., for x86 that would include
> the capabilities of the FPU), or even run time (is there any ?) sh
Benjamin Herrenschmidt wrote:
> On Wed, 2009-02-04 at 09:54 -0600, Serge E. Hallyn wrote:
>> Quoting Benjamin Herrenschmidt (b...@kernel.crashing.org):
+struct cr_hdr_cpu {
+ struct pt_regs pt_regs;
+ /* relevant fields from thread_struct */
+ double fpr[32][TS_FPRWIDTH];
>
On Wed, 2009-02-04 at 09:54 -0600, Serge E. Hallyn wrote:
> Quoting Benjamin Herrenschmidt (b...@kernel.crashing.org):
> >
> > > +struct cr_hdr_cpu {
> > > + struct pt_regs pt_regs;
> > > + /* relevant fields from thread_struct */
> > > + double fpr[32][TS_FPRWIDTH];
> > > + unsigned int fpscr;
>
Quoting Benjamin Herrenschmidt (b...@kernel.crashing.org):
>
> > +struct cr_hdr_cpu {
> > + struct pt_regs pt_regs;
> > + /* relevant fields from thread_struct */
> > + double fpr[32][TS_FPRWIDTH];
> > + unsigned int fpscr;
> > + int fpexc_mode;
> > + /* unsigned int align_ctl; this is
> +struct cr_hdr_cpu {
> + struct pt_regs pt_regs;
> + /* relevant fields from thread_struct */
> + double fpr[32][TS_FPRWIDTH];
> + unsigned int fpscr;
> + int fpexc_mode;
> + /* unsigned int align_ctl; this is never updated? */
> + unsigned long dabr;
> +};
Is there
Oren Laadan wrote:
>
> Nathan Lynch wrote:
> >
> > Oren Laadan wrote:
> >> Nathan Lynch wrote:
> >>> + pr_debug("%s: unexpected thread_hdr contents: 0x%lx\n",
> >>> + __func__, (unsigned long)thread_hdr->unimplemented);
> >> Given the macro for 'pr_fmt' in include/linux/c
Quoting Oren Laadan (or...@cs.columbia.edu):
> > +static void cr_hdr_init(struct cr_hdr *hdr, __s16 type, __s16 len, __u32
> > parent)
> > +{
> > + hdr->type = type;
> > + hdr->len = len;
> > + hdr->parent = parent;
> > +}
> > +
>
> This function is rather generic and useful to non-arch-dep
Quoting Nathan Lynch (n...@pobox.com):
> The only thing of significance here is that the checkpointed task's
> pt_regs and fp state are saved and restored (see cr_write_cpu and
> cr_read_cpu); the rest of the code consists of dummy implementations
> of the APIs the arch needs to provide to the chec
Nathan Lynch wrote:
> Hey Oren, thanks for taking a look.
>
> Oren Laadan wrote:
>> Nathan Lynch wrote:
>>> What doesn't work:
>>> * restarting a 32-bit task from a 64-bit task and vice versa
>> Is there a test to bail if we attempt to checkpoint such tasks ?
>
> No, but I'll add one if it looks
Hey Oren, thanks for taking a look.
Oren Laadan wrote:
>
> Nathan Lynch wrote:
> >
> > What doesn't work:
> > * restarting a 32-bit task from a 64-bit task and vice versa
>
> Is there a test to bail if we attempt to checkpoint such tasks ?
No, but I'll add one if it looks too hard to fix for t
Nathan,
Thanks for the patch. Looks good, see some comments below.
(disclaimer: I'm not very familiar with ppc architecture)
Nathan Lynch wrote:
> The only thing of significance here is that the checkpointed task's
> pt_regs and fp state are saved and restored (see cr_write_cpu and
> cr_read_cpu)
The only thing of significance here is that the checkpointed task's
pt_regs and fp state are saved and restored (see cr_write_cpu and
cr_read_cpu); the rest of the code consists of dummy implementations
of the APIs the arch needs to provide to the checkpoint/restart core.
What works:
* self and ex
24 matches
Mail list logo
