[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