From: "Serge E. Hallyn" <serue-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
To: Christian Borntraeger
<borntraeger-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org>
Cc: linux-s390-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
schwidefsky-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org,
Linux Containers
<containers-qjLDD68F18O7TbgM5vRIOg@public.gmane.org>,
linux390-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org,
Thomas Gleixner <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>
Subject: Re: [PATCH 1/1] c/r: define s390-specific checkpoint-restart code (v3)
Date: Wed, 4 Feb 2009 12:27:13 -0600 [thread overview]
Message-ID: <20090204182713.GA8722@us.ibm.com> (raw)
In-Reply-To: <200902041019.53683.borntraeger-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org>
Quoting Christian Borntraeger (borntraeger-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org):
> Am Tuesday 03 February 2009 17:12:23 schrieb Serge E. Hallyn:
> [...]
> > +/* Nothing to do for mm context state */
> > +int cr_write_mm_context(struct cr_ctx *ctx, struct mm_struct *mm, int
> > parent) +{
> > + struct cr_hdr h;
> > + struct cr_hdr_mm_context *hh = cr_hbuf_get(ctx, sizeof(*hh));
> > + int ret;
> > +
> > + h.type = CR_HDR_MM_CONTEXT;
> > + h.len = sizeof(*hh);
> > + h.parent = parent;
> > +
> > +#if 0
> > + /* Oren's v13 is on an older kernel which has no vdso_base */
> > + /* on newer kernel, we'll have to enable this */
> > + hh->vdso_base = mm->context.vdso_base;
> > + printk(KERN_NOTICE "checkpointing vdso_base %lx\n", hh->vdso_base);
> > +#else
> > + hh->vdso_base = 0;
> > +#endif
> > +
> > + ret = cr_write_obj(ctx, &h, hh);
> > + cr_hbuf_put(ctx, sizeof(*hh));
> > +
> > + return ret;
> > +}
Hi, thanks for taking a look. (I can definately use some help)
> Hmm, maybe you should also save/restore other elements of mm_context_t.
Oren pointed out (on Jan 15, see
https://lists.linux-foundation.org/pipermail/containers/2009-January/015304.html)
that the arch-independent restart code will re-create the checkpointed
memory mappings using do_mmap_pgoff(). So the other mm_context_t
contents should be automatically handled, right?
> At least noexec, has_pgste and alloc_pgste have an impact on the page table
> layout and special features like no execute or the ability to run kvm guests.
I went ahead and added those three - but they're always all 0 on my
testcases so far, and restoring them doesn't fix my restart segfault :(
How and why are they supposed to be set though? Looking through the
s390 arch code, I don't really see anything justifying hand-tweaking
them.
> > +int cr_read_mm_context(struct cr_ctx *ctx, struct mm_struct *mm, int
> > rparent) +{
> > + struct cr_hdr_mm_context *hh = cr_hbuf_get(ctx, sizeof(*hh));
> > + int parent, ret = -EINVAL;
> > +
> > + s390_enable_sie();
>
> Hmm, why do you call s390_enable_sie()? It will fail on multi-threaded apps
> and will create enhanced page tables for running kvm guest otherwise. It is
> not needed for non-kvm processes. See the has_pgste/alloc_pgste topic above.
Short answer: bc martin told me to :) But I take it I misunderstood,
and should only do that if running in kvm?
(That email at
https://lists.linux-foundation.org/pipermail/containers/2009-January/015305.html)
But thinking through this: if some task 798 is running inside kvm,
it will have already done s390_enable_sie(), right? So if it now
does sys_restart(), we shouldn't run that again, right?
So I've removed it again. (Which still doesn't solve my segfault on
restart. At the moment I'm busily learning about the VM debugger :)
thanks,
-serge
WARNING: multiple messages have this Message-ID (diff)
From: "Serge E. Hallyn" <serue@us.ibm.com>
To: linux-s390@vger.kernel.org
Subject: Re: [PATCH 1/1] c/r: define s390-specific checkpoint-restart code
Date: Wed, 04 Feb 2009 18:27:13 +0000 [thread overview]
Message-ID: <20090204182713.GA8722@us.ibm.com> (raw)
In-Reply-To: <200902041019.53683.borntraeger@de.ibm.com>
Quoting Christian Borntraeger (borntraeger@de.ibm.com):
> Am Tuesday 03 February 2009 17:12:23 schrieb Serge E. Hallyn:
> [...]
> > +/* Nothing to do for mm context state */
> > +int cr_write_mm_context(struct cr_ctx *ctx, struct mm_struct *mm, int
> > parent) +{
> > + struct cr_hdr h;
> > + struct cr_hdr_mm_context *hh = cr_hbuf_get(ctx, sizeof(*hh));
> > + int ret;
> > +
> > + h.type = CR_HDR_MM_CONTEXT;
> > + h.len = sizeof(*hh);
> > + h.parent = parent;
> > +
> > +#if 0
> > + /* Oren's v13 is on an older kernel which has no vdso_base */
> > + /* on newer kernel, we'll have to enable this */
> > + hh->vdso_base = mm->context.vdso_base;
> > + printk(KERN_NOTICE "checkpointing vdso_base %lx\n", hh->vdso_base);
> > +#else
> > + hh->vdso_base = 0;
> > +#endif
> > +
> > + ret = cr_write_obj(ctx, &h, hh);
> > + cr_hbuf_put(ctx, sizeof(*hh));
> > +
> > + return ret;
> > +}
Hi, thanks for taking a look. (I can definately use some help)
> Hmm, maybe you should also save/restore other elements of mm_context_t.
Oren pointed out (on Jan 15, see
https://lists.linux-foundation.org/pipermail/containers/2009-January/015304.html)
that the arch-independent restart code will re-create the checkpointed
memory mappings using do_mmap_pgoff(). So the other mm_context_t
contents should be automatically handled, right?
> At least noexec, has_pgste and alloc_pgste have an impact on the page table
> layout and special features like no execute or the ability to run kvm guests.
I went ahead and added those three - but they're always all 0 on my
testcases so far, and restoring them doesn't fix my restart segfault :(
How and why are they supposed to be set though? Looking through the
s390 arch code, I don't really see anything justifying hand-tweaking
them.
> > +int cr_read_mm_context(struct cr_ctx *ctx, struct mm_struct *mm, int
> > rparent) +{
> > + struct cr_hdr_mm_context *hh = cr_hbuf_get(ctx, sizeof(*hh));
> > + int parent, ret = -EINVAL;
> > +
> > + s390_enable_sie();
>
> Hmm, why do you call s390_enable_sie()? It will fail on multi-threaded apps
> and will create enhanced page tables for running kvm guest otherwise. It is
> not needed for non-kvm processes. See the has_pgste/alloc_pgste topic above.
Short answer: bc martin told me to :) But I take it I misunderstood,
and should only do that if running in kvm?
(That email at
https://lists.linux-foundation.org/pipermail/containers/2009-January/015305.html)
But thinking through this: if some task 798 is running inside kvm,
it will have already done s390_enable_sie(), right? So if it now
does sys_restart(), we shouldn't run that again, right?
So I've removed it again. (Which still doesn't solve my segfault on
restart. At the moment I'm busily learning about the VM debugger :)
thanks,
-serge
next prev parent reply other threads:[~2009-02-04 18:27 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-03 16:12 [PATCH 1/1] c/r: define s390-specific checkpoint-restart code (v3) Serge E. Hallyn
[not found] ` <20090203161223.GA17998-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2009-02-03 19:08 ` Oren Laadan
[not found] ` <4988961A.2080101-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>
2009-02-03 19:42 ` Serge E. Hallyn
2009-02-04 9:19 ` Christian Borntraeger
[not found] ` <200902041019.53683.borntraeger-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org>
2009-02-04 18:27 ` Serge E. Hallyn [this message]
2009-02-04 18:27 ` [PATCH 1/1] c/r: define s390-specific checkpoint-restart code Serge E. Hallyn
2009-02-03 19:35 ` [PATCH 1/1] c/r: define s390-specific checkpoint-restart code (v3) Dan Smith
[not found] ` <87k58748kn.fsf-FLMGYpZoEPULwtHQx/6qkW3U47Q5hpJU@public.gmane.org>
2009-02-03 19:41 ` Serge E. Hallyn
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=20090204182713.GA8722@us.ibm.com \
--to=serue-r/jw6+rmf7hqt0dzr+alfa@public.gmane.org \
--cc=borntraeger-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org \
--cc=containers-qjLDD68F18O7TbgM5vRIOg@public.gmane.org \
--cc=linux-s390-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux390-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org \
--cc=schwidefsky-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org \
--cc=tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org \
/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.