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