All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oren Laadan <orenl-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>
To: schwidefsky-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org
Cc: Linux Containers
	<containers-qjLDD68F18O7TbgM5vRIOg@public.gmane.org>,
	Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
Subject: Re: [RFC PATCH 0/2] cr: Introduce s390x checkpoint/restart code
Date: Thu, 15 Jan 2009 04:55:56 -0500	[thread overview]
Message-ID: <496F082C.3020008@cs.columbia.edu> (raw)
In-Reply-To: <1232012395.30152.13.camel@localhost>



Martin Schwidefsky wrote:
> On Wed, 2009-01-14 at 23:05 -0600, Serge E. Hallyn wrote:
>> Hi,
>>
>> here is a first stab at extending Oren's application c/r patchset
>> (http://lkml.org/lkml/2008/12/29/38) to s390.  I pretty much spent a day
>> or two looking through the s390 include and .S files and then took a
>> stab, so I won't be surprised to find these patches (and myself) the
>> subject of ridicule.  For instance, I'm really not *sure* whether I
>> should be backing up the acrs registers (some s390 docs suggested
>> userspace could use them), the ksp, or the vdso_base.  But one thing
>> I've got going for me at least...  it works!
> 
> The access registers need to be saved, a0/a1 contain the TLS pointer and
> the user can store anything to a2-a15. The ksp does not have to be
> stored as it cannot contain an important value. If it would then we'd
> have kernel state which would break checkpoint/restart. The restart code
> needs to come up with a sensible initial value for ksp though. The
> vdso_base code needs to be stored as well. 
> 
> This hunk from patch #2 worries me a bit:
> 
>  struct cr_hdr_mm_context {
> -       __s16 unimplemented;
> +#if 0
> +       unsigned long asce_bits;
> +       unsigned long asce_limit;
> +       int noexec;
> +       int has_pgste;
> +       int alloc_pgste;
> +#endif
> +       unsigned long vdso_base;
>  };
> 
> The page table can have 2, 3, or 4 levels and if KVM is used the page
> tables have a the pgste table attached to them. If that is ignored then
> the creation of the process address space on restart is definitly
> broken.

Disclaimer: I have zero knowledge about s390 specifics, so take
this with a grain of salt...

That said, I wonder why would we care about the page table choice ?
Does user-level have any notion of this low-level detail ?

We save the VMAs in checkpoint, and reconstruct them in restart by
calling do_mmap_pgoff(). The nearest we get to that level is in
calling follow_page() in cr_consider_private_page(), at checkpoint.

I'd expect everything below to be entirely transparent to us.

> 
>> Please take a look, point and laugh, and maybe even explain
>> what's so funny and how to improve them.
> 
> It doesn't look THAT bad ;-)
> 

Thanks, Serge. It looks perfect to me ... see disclaimer above :p

Oren.

  reply	other threads:[~2009-01-15  9:55 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-15  5:05 [RFC PATCH 0/2] cr: Introduce s390x checkpoint/restart code Serge E. Hallyn
     [not found] ` <20090115050523.GA10415-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2009-01-15  5:06   ` [RFC PATCH 1/2] c/r: hook checkpoint and restart for s390 Serge E. Hallyn
2009-01-15  5:06   ` [RFC PATCH 2/2] cr: s390: fill in the read/write routines Serge E. Hallyn
2009-01-15  9:39   ` [RFC PATCH 0/2] cr: Introduce s390x checkpoint/restart code Martin Schwidefsky
2009-01-15  9:55     ` Oren Laadan [this message]
     [not found]       ` <496F082C.3020008-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>
2009-01-15 10:10         ` Martin Schwidefsky
2009-01-15 22:25           ` Serge E. Hallyn
2009-01-15 16:29     ` 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=496F082C.3020008@cs.columbia.edu \
    --to=orenl-eqauephvms7envbuuze7ea@public.gmane.org \
    --cc=arnd-r2nGTMty4D4@public.gmane.org \
    --cc=containers-qjLDD68F18O7TbgM5vRIOg@public.gmane.org \
    --cc=schwidefsky-tA70FqPdS9bQT0dZR+AlfA@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.