Add support for cpuid options, parsing them into cpuid entries and
populate the cpuid configuration. They conform to the following form:
-o [vcpu.<vcpuid>.]cpuid.<function>[,<index>]=<eax>,<ebx>,<ecx>,<edx>
<function> specifies the cpuid function (aka "cpuid leaf") to create
an entry for, with an optional index specified by <index>. These are
the EAX and ECX register values to match when a CPUID instruction is
emulated for the guest. <eax>, <ebx>, <ecx>, and <edx> specify the
corresponding register values to be returned for the specified function
and index.
If a cpuid option specifies no vcpuid, that is it is rooted under
'cpuid.' in the config tree, it specifies an entry for the global cpuid
configuration, which isentry used for all VCPUs. Otherwise, if a vcpuid
is specified, that is the options rooted under 'vcpu.<vcpuid>.cpuid.',
it specifies an entry for cpuid configuration specific for the given
VCPU. The kernel only knows VCPU-specific cpuid configurations, so the
global cpuid configuration is merged into the VCPU-specific cpuid
configuration, but VCPU-specific cpuid entries always override any
global cpuid options for the same function/index.
cpuid options can be specified on the command line in any order.
Duplicates aren't allowed, although detection of duplicates is limited
by the mechanism of which '-o' options are parsed in bhyve.
In particular, consider the following cases:
1: bhyve [...] -o cpuid,0x00000123=0,0,0,0 -o cpuid=0x00000123=1,2,3,4 [...]
2: bhyve [...] -o cpuid,0x00000123=0,0,0,0 -o cpuid=0x123=1,2,3,4 [...]
The first case isn't a real duplicate entry as the bhyve option parsing
code only keeps the last value given for a particular option name string.
In the 2nd case, the option name string is different, thus they are two
separate options as far as the bhyve option parsing code is concerned
and both will be entered into the config nvlist. But the cpuid option
parser decodes both options into two different cpuid entries for the
same cpuid function, which will be detected as an error.
Note that if a non-legacy cpuid configuration is to be used, all CPUID
functions and indices must be specified, including all VCPU-specific
entries where they differ from one VCPU to another (such as for the
APIC ID, CPU topology information etc.). There is currently no way to
just override individual CPUID functions or just masking/setting
individual bits in a value returned, falling back to the legacy CPUID
emulation for functions/indices not specified.