Cool !
So what do we have working now for 64 bit kernel (for 32 bit kernel
we know it works...):
'restart' checkpointed
program program
----------------------------------------
64bit 64bit -> works
32bit 32bit -> works
64bit 32bit -> ?????
Does it make sense to allow the opposite transition: 'restart' starts
as a 32bit and becomes a 64bit after it restores the state from the
image ?
And what about if you checkpoint on a 32 bit kernel and try to
restart on a 64 bit kernel, and vice versa ? (in both cases, the
program of course is 32bit, and we can assume same physical host
for now).
Oren.
On Wed, 27 Jan 2010, Serge E. Hallyn wrote:
> arch_setup_additional_pages() on x86_64 fills in a 64-bit
> vdso page.
>
> With this patch, restart of 32-bit tasks (both self- and external
> checkpoints) on x86-64 succeeds.
>
> Signed-off-by: Serge E. Hallyn <[email protected]>
> ---
> mm/mmap.c | 4 ++++
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/mm/mmap.c b/mm/mmap.c
> index 1759a7f..e3d4178 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -2324,6 +2324,10 @@ int special_mapping_restore(struct ckpt_ctx *ctx,
> * Even that, is very basic - call arch_setup_additional_pages
> * requiring the same mapping (start address) as before.
> */
> +#ifdef CONFIG_X86_64 && CONFIG_COMPAT
> + if (test_thread_flag(TIF_IA32))
> + return syscall32_setup_pages(NULL, h->vm_start, 0);
> +#endif
> return arch_setup_additional_pages(NULL, h->vm_start, 0);
> }
> #else /* !CONFIG_CHECKPOINT */
>
_______________________________________________
Containers mailing list
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/containers
_______________________________________________
Devel mailing list
[email protected]
https://openvz.org/mailman/listinfo/devel
