[CRIU] [PATCH 2/2] x86: restore -- Allow to restore fpu even if image is incomatible with cpu state

[Cyrill Gorcunov]

On Wed, Jan 29, 2014 at 04:12:56PM +0400, Pavel Emelyanov wrote:
> > +	/* Backward compatible mode: no fpu -> fxsave -> xsave transition allowed */
> > +	FPU_MODE_COMPAT		= 0,
> > +
> > +	/* Any mode: process even breaking backward compatibility */
> > +	FPU_MODE_ANY		= 1,
> 
> Can you shed more light on this. Where do we have fpu/fxsave/xsave states
> in the code? And why do we have only two modes, when there are 4 potential
> conversions (1 of which is src_fpu == dst_fpu)? And why do we call it
> "backward compatibility"?

There are actually two aspects -- images and run-time features. Very old
images may have no FPU data at all, so in such cases once restored the
task will have zeroified fpu state.

Now to capabilities. The FPU state is fetched with ptrace help. If runtime
cpu has xsave feature the task may be using ymm registers (but we can't
figure out if they were really used or not, the only we know is that there
is that named xsave frame [memory area with predefined format where ymm
registers are sitting] so we fetch it and save to image file). fxsave
capability which we fetch from cpuinfo tells us that there is only xmm
registers present in memory frame fetched by ptrace.

So we might have machines with following configs -- no fpu (impossible since
we're targeting more-less new x86-64 machines with builting fpu, but no fpu case
may happen if someone manually modify image file) => fxsave (xmm regs) =>
xsave (xmm + ymm regs). We can _safely_ restore images with lower capability
on the machines with higher capabilities but not the reverse, becauase
hell knows what program may do once restored, maybe it test cpuinfo by
self, find that ymm registers are available and start using them.

Thus our strategy is the next:

 - find capabilities we're interested in on the criu startup procedure
 - when we dump FPU state -- fetch as much as we can: if the machine
   supports xsave capability -- we save the compelete xsave frame in
   image, otherwise we use fxsave frame
 - when we restore we find which capabilities the node we're restoring on
   are carries: fxsave/xsave, then
   - if xsave frame present in image but such feature is not supported
     by restoring cpu -- we refuse to continue
   - if xsave present in image and cpu has xsave cpapability -- we restore
     without problem
   - if fxsave present in image and cpu supports both fxsave and xsave --
     we restore without problem (ymm registers will be simply cleared after
     restore)
   - and finally if xsave pesent in image but cpu doesn't support it --
     we refuse to restore, because we don't know if program will use
     (or already used) ymm registers

Still, for migration test cases (where we know that we're not touching
ymm registers at all) we migh allow to restore images with xsave frame
on the machines where only fxsave frame supported.