[CRIU] [PATCH 2/2] cpu: Add 'ins' mode to --cpu-cap option

[Cyrill Gorcunov]

On Thu, Dec 25, 2014 at 09:16:00PM +0300, Pavel Emelyanov wrote:
> 
> I've tried to compare all the possible --cpu-cap options we might
> have an failed.
> 
> Let's summarize, CPU has many features. Here's what we get when we
> specify --cpu-cap $smth option.
> 
> all -- need all caps... Hm, OK
> 
> cpu -- all caps should _match_.
> 
> fpu -- only FPU subset of features should be equal or "better". The
>        rest isn't checked.
> 
> ins -- only "instructions" should be equal or "better". The rest
>        isn't checked.
> 
> Is that correct?
> What's the difference between "all" and "cpu"?

all stands for any possible combination (even if
we will need some new ones in future). At the moment
all and cpu are meaning the same.

> Does "ins" include "fpu"?

yes, because fpu state might be saved with various instructions
(fxsave,xsave  and etc). That said "ins" mode is like relaxed
cpu/all mode where only particular bits should be matched.

> Can we request for "all caps should be equal or better"?

Exactly what is happening in this series.
Look, we've a mask for all known instructions flags

x86_ins_capability_mask, then we test if destination
supports all of source instructions

static int cpu_validate_ins_features(CpuinfoX86Entry *img_x86_entry)
{
	size_t i;

	for (i = 0; i < ARRAY_SIZE(rt_cpu_info.x86_capability); i++) {
		u32 s = img_x86_entry->capability[i] & x86_ins_capability_mask[i];

		this is source bits

		u32 d = rt_cpu_info.x86_capability[i] & x86_ins_capability_mask[i];

		this is destination bits

		/*
		 * Destination might be more feature rich
		 * but not the reverse.
		 */
		if (s & ~d) {

			make sure all bits in source are known in destination

			pr_err("CPU instruction capabilities do not match run time\n");
			return -1;
		}
	}

	return 0;
}