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

Cyrill Gorcunov gorcunov at gmail.com
Tue Sep 30 03:50:13 PDT 2014


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

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.


More information about the CRIU mailing list