Commit 65b0b746b5 changed spice tests to use latest caps. Before this
change, "FLAG_REAL_CAPS" wasn't being set in testQemuInfoInitArgs(). The
absence of this flag triggered the code path inside
testCompareXMLToArgv() that executed testUpdateQEMUCaps(). This function
will update the host CPU via virQEMUCapsUpdateHostCPUModel() into
virQEMUCapsInitHostCPUModel(). In this function,
virQEMUCapsInitCPUModel() would end up updating the hostCPU inside the
qemuCaps (via virQEMUCapsProbeHostCPU()). Before the forementioned
commit, the host CPU was being defaulted to x86_64, vendor Intel, for
the 'graphics-spice-timeout' test that is using the 'pc' machine type
and 'accel=kvm'.
Today, "FLAG_REAL_CAPS" is being set because we're using the latest caps
from x86_64. This means that the whole code path mentioned above is
skipped. qemuCaps are now being loaded via virQEMUCapsLoadCache()
directly. Without the handling being done by testUpdateQEMUCaps(), the
host CPU is being retrieved later on, down below
qemuProcessCreatePretendCmdPrepare() into qemuProcessUpdateGuestCPU().
The latter will attempt to update the domain cpu and executing a
virCPUCompare with the hostCPU and def->cpu.
All this logic ended up causing a failure of the
'graphics-spice-timeout' test in ppc64 and s390x hosts. This test is
being run with KVM acceleration, and the KVM driver for ppc64 and s390x
will return a default x86_64 CPU with vendor "AMD", making
virCPUCompare() fail with the following message:
"QEMU XML-2-ARGV graphics-spice-timeout.x86_64-latest ... libvirt: CPU
Driver error : the CPU is incompatible with host CPU: host CPU vendor does
not match required CPU vendor Intel"
Fix this test by setting cpu check='none' and avoid the virCPUCompare()
that causes the problem for ppc64 and s390x hosts.
Note that this is a build fix. A more adequate fix would be to mock the
getHost() interface of the cpuDriverX86 for non-x86 hosts, allowing
'fullCPU' to be retrieved in qemuProcessUpdateGuestCPU(), and a proper
x86 CPU to be retrieved in the scenario described above.
Reported-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Reduce the churn in following patches.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Tim Wiederhake <twiederh@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Recently CPU hardware vendors have started to support a new structure
inside the CPU package topology known as a "die". Thus the hierarchy
is now:
sockets > dies > cores > threads
This adds support for "dies" in the XML parser, with the value
defaulting to 1 if not specified for backwards compatibility.
For example a system with 64 logical CPUs might report
<topology sockets="4" dies="2" cores="4" threads="2"/>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The 32-bit x86 binary is called qemu-system-i386, not
qemu-system-i686. This mistake across many test XML files was
not noticed because the mistake was also made in testutilsqemu.c
when mocking the capabilities.
Reviewed-by: Erik Skultety <eskultet@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
These XMLs live in a separate directory, there's no need for them
to have a special prefix in addition. It also doesn't play nicely
with ':e' completion in Vim, finding proper file based on
qemuxml2argvtest.c is also needlessly complicated.
The files were renamed using the following commands. From
qemuxml2argvdata:
for i in qemuxml2argv-*.xml; do mv $i ${i#qemuxml2argv-}; done
and then (to fix broken symlinks) from qemuxml2argvdata and
qemuxml2xmloutdata:
for i in $(find . -xtype l); do \
ln -sf $(readlink $i | sed 's/qemuxml2argv-//') $i;
done
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
