Openstack Nova calls virConnectBaselineCPU() during initialization
of the instance to get a full list of CPU features.
This patch adds a stub to aarch64-specific code to handle
this request (no actual work is done). That's enough to have
this stub with limited functionality because qemu/kvm backend
supports only 'host-passthrough' cpu mode on aarch64.
Signed-off-by: Oleg Strikov <oleg.strikov@canonical.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1049391
When all source CPU XMLs contain just a single CPU model (with a
possibly varying set of additional feature elements),
virConnectBaselineCPU will try to use this CPU model in the computed
guest CPU. Thus, when used on just a single CPU (useful with
VIR_CONNECT_BASELINE_CPU_EXPAND_FEATURES), the result will not use a
different CPU model.
If the computed CPU uses the source model, set fallback mode to 'forbid'
to make sure the guest CPU will always be as close as possible to the
source CPUs.
https://bugzilla.redhat.com/show_bug.cgi?id=1049391
VIR_CONNECT_BASELINE_CPU_EXPAND_FEATURES flag for virConnectBaselineCPU
did not work if the resulting guest CPU would disable some features
present in its base model. This patch makes sure we won't try to add
such features twice.
This patch allows libvirt user to specify 'host-passthrough'
cpu mode while using qemu/kvm backend on aarch64.
It uses 'host' as a CPU model name instead of some other stub
(correct CPU detection is not implemented yet) to allow libvirt
user to specify 'host-model' cpu mode as well.
Signed-off-by: Oleg Strikov <oleg.strikov@canonical.com>
(crobinso: fix some indentation)
Some of the emulator features are presented in the <features> element in
the domain XML although they are virtual CPUID feature bits when
presented to the guest. To avoid confusing the users with these
features, as they are not configurable via the <cpu> element, this patch
adds an internal array where those can be stored privately instead of
exposing them in the XML.
Additionaly KVM feature bits are added as example usage of this code.
The CPUID functions were stored in multiple arrays according to a
specified prefix of those. This made it very hard to add another prefix
to store KVM CPUID features (0x40000000). Instead of hardcoding a third
array this patch changes the approach used:
The code is refactored to use a single array where the CPUID functions
are stored ordered by the cpuid function so that they don't depend on
the specific prefix and don't waste memory. The code is also less
complex using this approach. A trateoff to this is the change from O(N)
complexity to O(N^2) in x86DataAdd and x86DataSubtract. The rest of the
functions were already using O(N^2) algorithms.
Until now the map was loaded from the XML definition file every time a
operation on the flags was requested. With the introduciton of one shot
initializers we can store the definition forever (as it will never
change) instead of parsing it over and over again.
This makes virCPUx86DataAddCPUID, virCPUx86DataFree, and
virCPUx86MakeData available for direct usage outside of cpu driver in
tests and the new qemu monitor that will request the actual CPU
definition from a running qemu instance.
This patch adds cpuDataFormat and cpuDataParse APIs to be used in unit
tests for testing APIs that deal with virCPUData. In the x86 world, this
means we can now store/load arbitrary CPUID data in the test suite to
check correctness of CPU related APIs that could not be tested before.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
'const fooPtr' is the same as 'foo * const' (the pointer won't
change, but it's contents can). But in general, if an interface
is trying to be const-correct, it should be using 'const foo *'
(the pointer is to data that can't be changed).
Fix up offenders in src/cpu.
* src/cpu/cpu.h (cpuArchDecode, cpuArchEncode, cpuArchUpdate)
(cpuArchHasFeature, cpuDecode, cpuEncode, cpuUpdate)
(cpuHasFeature): Use intended type.
* src/conf/cpu_conf.h (virCPUDefCopyModel, virCPUDefCopy):
Likewise.
(virCPUDefParseXML): Drop const.
* src/cpu/cpu.c (cpuDecode, cpuEncode, cpuUpdate, cpuHasFeature):
Fix fallout.
* src/cpu/cpu_x86.c (x86ModelFromCPU, x86ModelSubtractCPU)
(x86DecodeCPUData, x86EncodePolicy, x86Encode, x86UpdateCustom)
(x86UpdateHostModel, x86Update, x86HasFeature): Likewise.
* src/cpu/cpu_s390.c (s390Decode): Likewise.
* src/cpu/cpu_arm.c (ArmDecode): Likewise.
* src/cpu/cpu_powerpc.c (ppcModelFromCPU, ppcCompute, ppcDecode)
(ppcUpdate): Likewise.
* src/conf/cpu_conf.c (virCPUDefCopyModel, virCPUDefCopy)
(virCPUDefParseXML): Likewise.
Signed-off-by: Eric Blake <eblake@redhat.com>
On Power platform, Power7+ can support Power7 guest.
It needs to define XML configuration to specify guest's CPU model.
For exmaple:
<cpu match='exact'>
<model>POWER7_v2.1</model>
<vendor>IBM</vendor>
</cpu>
Signed-off-by: Li Zhang <zhlcindy@linux.vnet.ibm.com>
The s390, ppc and arm CPU drivers never set the 'arch' field
in their impl of cpuArchNodeData. This leads to error messages
being reported from cpuDataFree later, due to trying to use
VIR_ARCH_NONE.
#0 virRaiseErrorFull (filename=filename@entry=0x76f94434 "cpu/cpu.c", funcname=funcname@entry=0x76f942dc <__FUNCTION__.18096> "cpuGetSubDriver", linenr=linenr@entry=58,
domain=domain@entry=31, code=code@entry=1, level=level@entry=VIR_ERR_ERROR, str1=0x76f70e18 "internal error: %s",
str2=str2@entry=0x7155f2ec "undefined hardware architecture", str3=str3@entry=0x0, int1=int1@entry=-1, int2=int2@entry=-1, fmt=0x76f70e18 "internal error: %s")
at util/virerror.c:646
#1 0x76e682ea in virReportErrorHelper (domcode=domcode@entry=31, errorcode=errorcode@entry=1, filename=0x76f94434 "cpu/cpu.c",
funcname=0x76f942dc <__FUNCTION__.18096> "cpuGetSubDriver", linenr=linenr@entry=58, fmt=0x76f7e7e4 "%s") at util/virerror.c:1292
#2 0x76ed82d4 in cpuGetSubDriver (arch=<optimized out>) at cpu/cpu.c:57
#3 cpuGetSubDriver (arch=VIR_ARCH_NONE) at cpu/cpu.c:51
#4 0x76ed8818 in cpuDataFree (data=data@entry=0x70c22d78) at cpu/cpu.c:216
#5 0x716aaec0 in virQEMUCapsInitCPU (arch=VIR_ARCH_ARMV7L, caps=0x70c29a08) at qemu/qemu_capabilities.c:867
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Currently the virConnectBaselineCPU API does not expose the CPU features
that are part of the CPU's model. This patch adds a new flag,
VIR_CONNECT_BASELINE_CPU_EXPAND_FEATURES, that causes the API to explicitly
list all features that are part of that model.
Signed-off-by: Don Dugger <donald.d.dugger@intel.com>
Signed-off-by: Eric Blake <eblake@redhat.com>
Until now CPU features inherited from a specified CPU model could only
be overridden with 'disable' policy. With this patch, any explicitly
specified feature always overrides the same feature inherited from a CPU
model regardless on the specified policy.
The CPU in x86-exact-force-Haswell.xml would previously be incompatible
with x86-host-SandyBridge.xml CPU even though x86-host-SandyBridge.xml
provides all features required by x86-exact-force-Haswell.xml.
https://bugzilla.redhat.com/show_bug.cgi?id=799354
Until now, the "host-model" cpu mode couldn't be influenced. This patch
allows to use the <feature> elements to either enable or disable
specific CPU flags. This can be used to force flags that can be emulated
even if the host CPU doesn't support them.
Convert the type of loop iterators named 'i', 'j', k',
'ii', 'jj', 'kk', to be 'size_t' instead of 'int' or
'unsigned int', also santizing 'ii', 'jj', 'kk' to use
the normal 'i', 'j', 'k' naming
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
The source code base needs to be adapted as well. Some files
include virutil.h just for the string related functions (here,
the include is substituted to match the new file), some include
virutil.h without any need (here, the include is removed), and
some require both.
The cpu_map.xml file is there to separate CPU model definitions from the
code. Having the only interesting data for PowerPC models only in the
source code. This patch moves this data to the XML file and removes the
hardcoded list completely.
PowerPC CPUs are either identical or incompatible and thus we just need
to look up the right model for given PVR without pretending we have
several candidates which we may choose from.
The function is also renamed as ppcDecode to match other functions in
PowerPC CPU driver.
Baseline API is supposed to return guest CPU definition that can be used
on any of the provided host CPUs. Since PowerPC CPUs are either
identical or incompatible, the API just needs to check that all provided
CPUs are identical. Previous implementation was completely bogus.
The function is also renamed as ppcBaseline to match other functions in
PowerPC CPU driver.
When ppcVendorLoad fails to parse the vendor element for whatever
reason, it is supposed to ignore it and return 0 rather than -1. The
patch also removes PowerPC vendor string from the XML as it is not
actually used for anything.
Make getting node CPU data for PowerPC unsupported on other
architectures. The function is also renamed as ppcNodeData to match
other functions in PowerPC CPU driver.
This makes code easier to read, by avoiding lines longer than
80 columns and removing the repetition from the callers.
* src/util/virstoragefile.c (qedGetHeaderUL, qedGetHeaderULL):
Delete in favor of more generic macros.
(qcow2GetBackingStoreFormat, qcowXGetBackingStore)
(qedGetBackingStore, virStorageFileMatchesVersion)
(virStorageFileGetMetadataInternal): Use new macros.
* src/cpu/cpu_x86.c (x86VendorLoad): Likewise.
