Re: [RFC PATCH 0/2] cr: Introduce s390x checkpoint/restart code

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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.
_______________________________________________
Containers mailing list
Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/containers

[Index of Archives]     [Cgroups]     [Netdev]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux