[Devel] Re: [PATCH 1/1] fill vdso with syscall32_setup_pages if TIF_IA32 on x86_64

[Oren Laadan]

Serge E. Hallyn wrote:
> Quoting Oren Laadan (orenl at cs.columbia.edu):
>>
>> Serge E. Hallyn wrote:
>>> Quoting Oren Laadan (orenl at cs.columbia.edu):
>>>> Serge E. Hallyn wrote:
>>>>> Quoting Oren Laadan (orenl at cs.columbia.edu):
>>>>>> Serge E. Hallyn wrote:
>>>>>>> Quoting Oren Laadan (orenl at cs.columbia.edu):
>>>>>>>> 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		-> ?????
>>> s/?????/Rejected/
>>>
>>> CKPT_ARCH_ID is of course different for X86_32 than X86_64, so
>>> we refuse restart in restore_read_header().
>>>
>>> -serge
>>>
>> lol ... that's actually funny !
>>
>> Anyway, in light of the IRC discussions, here are the cases again:
>>
>>
>> original	original	restart		target
>> program		kernel		program		kernel
>> --------	---------	--------	--------
>> 64 bit		64 bit		64 bit		64 bit	  [0] works
>>
>> 32 bit		32 bit		32 bit		32 bit	  [0] works
>> 32 bit		64 bit		32 bit		64 bit	  [0] works
>>
>> 32 bit		32 bit		32 bit		64 bit	  [1]
>> 32 bit		64 bit		32 bit		32 bit	  [1]
>>
>> 32 bit		any		64 bit		64 bit	  [2]
>> 64 bit		64 bit		32 bit		64 bit	  [2]
>>
>> [0] The first 3 cases are "homogeneous", with conditions equal at
>> checkpoint and restart. AFAIK, they work.
>>
>> [1] The next two cases consider 32 bit program, and vary only the
>> environment - the kernel may change from 32 to 64 or back. We want
>> them to work.
>>
>> IIUC, your comment above means that they don't work because the
>> CKPT_ARCH_ID is a mismatch. The fix should be trivial - either
>> make 'restart' modify it, or make the kernel tolerate it.
> 
> Well, you'd think so, but we also check for uts->machine, and want
> to eventually check for kernel config, both of which are obviously
> different.

Then we'll have to take that in account when we get to also
check those other fields.

> 
> After I comment out the obvious offending checks, it still fails to
> restart from x8632->x86-64.  I can spend some time next week figuring
> out what we're not quite doing right as there shouldn't be a
> problem really.  But do we definately want to go out of our way to try
>  and mask out the differences in this case, while trying to detect
> cpu differences between two x86-32's for instance?

I agree, there shouldn't be a problem really, and I expect this to
be a very useful feature for migration/fault-tolerance.

Checking for differences between CPU's is a separate issue, and is
orthogonal to migration (of 32bit programs) between 32 and 64 bit
kernels.

I tend to answer "yes" - we should eventually refuse restart if we
detect that the "configuration" at restart time differs from that at
checkpoint time "sufficiently".

Now "configuration" is very basic - the architecture. I would like
that to also include cpu features, kernel features, fpu capabilities...
Also "sufficiently" is vaguely defined, because I don't know enough
to describe it more precisely.

Ideally there will be some clever user-space logic that will detect
and make a decision. And, yes, it will take a lot of details...

Oren.

_______________________________________________
Containers mailing list
Containers at lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers