cache cpu info in a file at boot

[bunnitha]

Instrumented cpuinfo to read the populated cpu info data from cpuid.info file during initialization.
Consumers of the library or OEMs can trigger a oneshot service - cpuinfo-svc - during device boot to link libcpuinfo and dump all cpu info related to processor, model, arch and isa capabilities into cpuid.info file. This arrangement will limit cpuid() intrinsic calls (which causes VM-Exit events and performance overhead) to only once during the init of libcpuinfo at boot by cpuinfo-svc. CPUID being a privileged instn costs considerable number of CPU cycles.

Test (on bare-metal): Test stub to invoke libcpuinfo before and after start of cpuinfo-svc while recording the TSC counter.
Result: 4B CPU cycles are saved in initializing cpuinfo library with the changes.

Test (on VM): It's little tricky to count the exact number of VM-Exits caused by CPUID calls.
For this effect, we have written a script to run an Android (dummy) service
that loads libcpuinfo - first in original version and next in modified version.
libcpuinfo makes around 4 __cpuid() calls on each initialization.
So, to amplify the effect, we have run the dummy service 1000 times and timed the total
execution (4000 __cpuid() calls and 8000 VMX events) in nano second precision.
This test shows that there is a reduction of approx. 0.6% in time to execute libcpuinfo.

Also, we attempted to record the KVM event statistics using perf tool.
Perf records the stats during the execution of same script.
The data shows that approx. 20,000 kvm_cpuid events reduced in modified libcpuinfo calls.
We cannot assume that all the CPUID calls are contributed by our script.
We are only making a safe assumption that the proportional reduction is affected
by the modification we did. We had made all efforts to keep the test conditions
similar in both cases.

[enh-google]

(copying from #261 since this wasn't addressed there.)

is this different from https://www.phoronix.com/news/Linux-Intel-KVM-Cache-CPUID ?

when we talked about this at bootcamp, i didn't really mean that you should upstream this to cpuinfo (because i don't think anyone will use it) --- i was just saying "Android won't take non-upstream patches to cpuinfo".

this still feels like something that should be fixed in the kernel, not hacked around in callers...