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

[Cyrill Gorcunov]

On Tue, Sep 23, 2014 at 11:22:25PM +0400, Pavel Emelyanov wrote:
> On 09/23/2014 11:20 PM, Cyrill Gorcunov wrote:
> > On Tue, Sep 23, 2014 at 11:07:01PM +0400, Pavel Emelyanov wrote:
> >>
> >> OK. Let's imagine the cpu has 
> >>
> >>    X86_FEATURE_XMM4_1 | X86_FEATURE_XMM4_2 | A
> >>
> >> and we ask it to check the image which contains 
> >>
> >>    X86_FEATURE_XMM4_1 | B
> >>
> >> and let's assume that A == B. Will the checker fail? Should it? Why?
> > 
> > Sure it fails, and sure more precise feature deps inspection is needed
> > but as first iteration I think it's fine having plain memcmp here.
> 
> I still don't understand why "cpu.mask >= image.mask -> validation OK"
> receipt doesn't work. If I'm not mistaken, we've been using this logic
> in OpenVZ's and PCS vzmigrate for many years.

In openvz cpucaps are taken from cpuid and ordered manually, moreover
the set of features is incomplete there: where mpx, avx512f and etc
see my list of features. So in my implementation the set of bits should
be considered as unordered (which is close to kernel's representation).

Btw, just realised. openvz representation is unordered actually

#define CPT_CPU_X86_SSE2   3
#define CPT_CPU_X86_MMX    4

which presumes that MMX is backward compatible with SSE2, but it;s
not, sse2 is more later instruction extension. So even in openvz
you must not compare the length of bitmask but inspect bits more
carefully explicitly defining who is more feature-rich (I really
doubt you tried to migrate container on cpu without sse2 'case
they are pretty old ones :-)

> > As to should it -- I don't know, technically the cpu itself is
> > backward compatible (at least it should be) but if someone migrate
> > to feature rich cpu , the dump it here and migrate back -- he will
> > have unpleasant surprise
> 
> Why?

Because programs may choose instruction flow depending on runtime cpu
capability, cpuid is ring3 intruction thus I can write myself a program
which would work fine on some featureless cpu in kvm and then migrate
it to hardware haswell cpu and switch to new avx2 instructions, then
dump it here and migrate back to kvm where attempt to use this instruction
set will lead to ugly results.