[CRIU] [PATCH 7/9] cpuinfo: x86 -- Add dump and validation of cpuinfo image

[Pavel Emelyanov]

On 09/30/2014 02:50 PM, Cyrill Gorcunov wrote:
> On Tue, Sep 30, 2014 at 02:08:21PM +0400, Pavel Emelyanov wrote:
>>
>>>  #endif /* __CR_CPU_H__ */
>>> diff --git a/cr-dump.c b/cr-dump.c
>>> index d00c158d205e..1df1ba06aeab 100644
>>> --- a/cr-dump.c
>>> +++ b/cr-dump.c
>>> @@ -1787,6 +1787,11 @@ int cr_dump_tasks(pid_t pid)
>>>  	if (write_img_inventory())
>>>  		goto err;
>>>  
>>> +	if (opts.cpu_cap & CPU_CAP_CPUINFO) {
>>
>> What if the "fpu" mode is requested. Shouldn't we produce
>> the cpuinfo image?
> 
> Actually, I don't know. It looks more logical to dump cpuinfo
> here but lets refresh our memory
> 
> 1) Initially we meet problem when been trying to c/r FPU state
>    (fxsave/xsave frames) so we decided to check it this way
> 
>   - on criu start fetch fxsave/xsave compatibility
>   - if xsave frame is present in "core" image but
>     runtime cpu doesn't support xsave we required --cpu-cap ^fpu
>     parameter to be passed so criu proceed restore regardless anything
> 
> 2) Now we have cpuinfo bits, cpuinfo is rather a superset over fpu
>    capability because it tracks all caps bits not fpu only

Ah, I see. OK then.

> and because of this we have a slightly mess in our code, xsave frames
> are carried in "core" images and tested regardless the "cpuinfo" image
> presence. That said -- I don't know, maybe indeed write cpuinfo if
> --cpu-cap fpu is passed does make sense. Up to you -- should we?
> 
>>>  
>>> +	if (cpu_validate_image_cpuinfo())
>>
>> Add the verb "try" in the name.
> 
> ok.
> .
>