Sometimes we want to call virCPUGetHost only when it is implemented for
a given architecture to avoid logging expected and possibly misleading
errors. The new virCPUGetHostIsSupported API may be used to guard such
calls to virCPUGetHost.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Because of the changes done in the previous commit, @host is already a
migratable CPU and there's no need to do any additional filtering.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

This reverts commit 5f96b3fe which was
pushed accidentally.

Because of the changes done in the previous commit, @host is already a
migratable CPU and there's no need to do any additional filtering.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

This new internal API makes a copy of virCPUDef while removing all
features which would block migration. It uses cpu_map.xml as a database
of such features, which should only be used as a fallback when we cannot
get the data from a hypervisor. The main goal of this API is to decouple
this filtering from virCPUUpdate so that the hypervisor driver can
filter the features according to the hypervisor.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

The public API flags are handled by the cpuBaselineXML wrapper. The
internal cpuBaseline API only needs to know whether it is supposed to
drop non-migratable features.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

cpuBaseline is responsible for computing a baseline CPU while feature
expansion is done by virCPUExpandFeatures. The cpuBaselineXML wrapper
(used by hypervisor drivers to implement virConnectBaselineCPU API)
calls cpuBaseline followed by virCPUExpandFeatures if requested by
VIR_CONNECT_BASELINE_CPU_EXPAND_FEATURES flag.

The features in the three changed test files had to be sorted using
"sort -k 3" because virCPUExpandFeatures returns a sorted list of
features.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Having to use cpuBaseline with VIR_CONNECT_BASELINE_CPU_EXPAND_FEATURES
flag to expand CPU features is strange. Not to mention that cpuBaseline
can only expand host CPU definitions (i.e., it completely ignores
feature policies). The new virCPUExpandFeatures API is designed to work
with both host and guest CPU definitions.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

There is no "node driver" as there was before, drivers have to do
their own ACL checking anyway, so they all specify their functions and
nodeinfo is basically just extending conf/capablities.  Hence moving
the code to src/conf/ is the right way to go.

Also that way we can de-duplicate some code that is in virsysfs and/or
virhostcpu that got duplicated during the virhostcpu.c split.  And
Some cleanup is done throughout the changes, like adding the vir*
prefix etc.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Both QEMU and bhyve are using the same function for setting up the CPU
in virCapabilities, so de-duplicate it, save code and time, and help
other drivers adopt it.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Since the code checks and handles a NULL 'cpus' anyway, so no need
for the NONNULL.

When guest CPU definition uses VIR_CPU_CHECK_FULL checks, we need to
make sure QEMU does not add or remove any features.

https://bugzilla.redhat.com/show_bug.cgi?id=822148
https://bugzilla.redhat.com/show_bug.cgi?id=824989Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

When starting a domain with custom guest CPU specification QEMU may add
or remove some CPU features. There are several reasons for this, e.g.,
QEMU/KVM does not support some requested features or the definition of
the requested CPU model in libvirt's cpu_map.xml differs from the one
QEMU is using. We can't really avoid this because CPU models are allowed
to change with machine types and libvirt doesn't know (and probably
doesn't even want to know) about such changes.

Thus when we want to make sure guest ABI doesn't change when a domain
gets migrated to another host, we need to update our live CPU definition
according to the CPU QEMU created. Once updated, we will change CPU
checking to VIR_CPU_CHECK_FULL to make sure the virtual CPU created
after migration exactly matches the one on the source.

https://bugzilla.redhat.com/show_bug.cgi?id=822148
https://bugzilla.redhat.com/show_bug.cgi?id=824989Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

When creating host CPU definition usable with a given emulator, the CPU
should not be defined using an unsupported CPU model. The new @models
and @nmodels parameters can be used to limit CPU models which can be
used in the result.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

The parameter can be used to request either VIR_CPU_TYPE_HOST (which has
been assumed so far) or VIR_CPU_TYPE_GUEST definition.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

cpuNodeData has always been followed by cpuDecode as no hypervisor
driver is really interested in raw CPUID data for a host CPU. Let's
create a new CPU driver API which returns virCPUDefPtr directly.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

QEMU should be written all upper or all lower case.

All Intel Haswell processors (except Xeon E7 v3 with stepping >= 4) have
TSX disabled by microcode update. As not all CPUs are guaranteed to be
patched with microcode updates we need to explicitly disable TSX on
affected CPUs to avoid its accidental usage.

https://bugzilla.redhat.com/show_bug.cgi?id=1406791Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

The API is useful for creating virCPUData in a hypervisor driver from
data we got by querying the hypervisor.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

The API is useful for creating virCPUData in a hypervisor driver from
data we got by querying the hypervisor.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

The API is useful for creating virCPUData in a hypervisor driver from
data we got by querying the hypervisor.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

The CPU driver provides APIs to create and free virCPUDataPtr. Thus all
APIs exported from the driver should work with that rather than
requiring the caller to pass a pointer to an internal part of the
structure.

In other words

    virCPUx86DataAddCPUID(cpudata, &cpuid)

is much better than the original

    virCPUx86DataAddCPUID(&cpudata->data.x86, &cpuid)
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

The new API is called virCPUDataFree. Individual CPU drivers are no
longer required to implement their own freeing function unless they need
to free architecture specific data from virCPUData.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

virCPUDef.arch is not required to be filled in for guest CPU
definitions. It doesn't make sense to artificially mandate it to be set
when cpuDecode is called especially when virCPUData.arch passed to
cpuDecode already contains the architecture.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Strings associated with virDomainHyperv values in domain_conf.c are used to
construct HyperV CPU features names to be compared with names defined in
cpu_x86_data.h and the names for HyperV "spinlocks" feature don't match.
This leads to a misleading warning:
"host doesn't support hyperv 'spinlocks' feature" even when it's supported.
Let's fix it and rename along with it VIR_CPU_x86_KVM_HV_SPINLOCK to
VIR_CPU_x86_KVM_HV_SPINLOCKS.
Signed-off-by: NMaxim Nestratov <mnestratov@virtuozzo.com>

virCPUDefStealModel is called with keepVendor == true which means the
cpu structure will keep its original vendor/vendor_id values. Thus it
makes no sense to copy them to the translated definition as they won't
be used there anyway. Except that the translated->vendor pointer might
get lost in x86Decode.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

On s390, the host's features are heavily influenced by not only the host
hardware but also by hardware microcode level, host OS version, qemu
version and kvm version. In this environment it does not make sense to
attempt to report exact host details.
Signed-off-by: NJason J. Herne <jjherne@linux.vnet.ibm.com>
Acked-by: NJiri Denemark <jdenemar@redhat.com>

Implement compare for s390. Required to test the guest against the host for
guest cpu model runnability checking. We always return IDENTICAL to bypass
Libvirt's checking. s390 will rely on Qemu to perform the runnability checking.

Implement update for s390. required to support use of cpu "host-model" mode.
Signed-off-by: NJason J. Herne <jjherne@linux.vnet.ibm.com>
Acked-by: NJiri Denemark <jdenemar@redhat.com>

This check is not required because all i386 and x86_64 cpus have the
cpuid instruction.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

qemu commit: f74eefe0
https://lwn.net/Articles/667156/Signed-off-by: NLin Ma <lma@suse.com>

These features are included:
AVX512DQ, AVX512IFMA, AVX512BW, AVX512VL, AVX512VBMI, AVX512_4VNNIW and
AVX512_4FMAPS.

qemu commits: cc728d14 and 95ea69fb
Signed-off-by: NLin Ma <lma@suse.com>

We can't change feature names for compatibility reasons even if they
contain typos or other software uses different names for the same
features. By adding alternative spellings in our CPU map we at least
allow anyone to grep for them and find the correct libvirt's name.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

They didn't really help anything.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

We have couple of functions that operate over NULL terminated
lits of strings. However, our naming sucks:

virStringJoin
virStringFreeList
virStringFreeListCount
virStringArrayHasString
virStringGetFirstWithPrefix

We can do better:

virStringListJoin
virStringListFree
virStringListFreeCount
virStringListHasString
virStringListGetFirstWithPrefix
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

The API is not used anywhere in the code.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>