[CRIU] [PATCH 6/6] cpuinfo: x86 -- Add dump and validation

[Pavel Emelyanov]

On 09/02/2014 04:42 PM, Cyrill Gorcunov wrote:
> On Tue, Sep 02, 2014 at 04:22:13PM +0400, Pavel Emelyanov wrote:
>> On 09/01/2014 01:06 PM, Cyrill Gorcunov wrote:
>>
>>> diff --git a/cr-dump.c b/cr-dump.c
>>> index cec579ead5be..ef16432dc2d4 100644
>>> --- a/cr-dump.c
>>> +++ b/cr-dump.c
>>> @@ -1816,6 +1816,9 @@ int cr_dump_tasks(pid_t pid)
>>>  	if (write_img_inventory())
>>>  		goto err;
>>>  
>>> +	if (cpu_dump_cpuinfo())
>>> +		goto err;
>>> +
>>
>> I really doubt CRIU should do it this way. When we live-migrate
>> container we first may do long FS sync, then we start iterations
>> which might take time. If at the time of dump we find out, that
>> we have CPU mismatch in source-vs-destination it will be ...
>> disappointing.
> 
> Look, we have to dump cpuinfo into an image, because it's better
> to find out on restore that you can't proceed working than getting
> #gp or something during program work after restore.
> 
>>
>> I would suggest implementing it in the way OpenVZ migration does.
>> Before we start live migration we should check whether the migration
>> is possible at all and only then start messing with CRIU. I don't
>> mind CRIU helping it though.
> 
> I think such functionality should be moved into criu daemon via rpc
> request, so that migration tool would ask criud to provide cpuinfo
> of destination machine or something like that.
> 
> But still dump/test/restore of cpuinfo is needed regradless the
> live migration I think. The helpers functions can be built on
> top of this patches.
> .
> 

There are cases when you don't want to mess with cpu checks at
all, e.g. when you don't plan to move from one node to another.
Thus cpuinfo dumping should at least be optional.

Thanks,
Pavel