From bbbf774fb2c104e374313b7489834df88a08fbfb Mon Sep 17 00:00:00 2001 From: Daniel Henrique Barboza Date: Tue, 16 Nov 2021 12:21:11 -0500 Subject: [PATCH] tests/qemuxml2*/graphics-spice-timeout: skip CPU model check Commit 65b0b746b516 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 Reviewed-by: Boris Fiuczynski Signed-off-by: Daniel Henrique Barboza --- tests/qemuxml2argvdata/graphics-spice-timeout.xml | 2 +- .../qemuxml2xmloutdata/graphics-spice-timeout.x86_64-latest.xml | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/tests/qemuxml2argvdata/graphics-spice-timeout.xml b/tests/qemuxml2argvdata/graphics-spice-timeout.xml index 065318651f..33dae5c4bf 100644 --- a/tests/qemuxml2argvdata/graphics-spice-timeout.xml +++ b/tests/qemuxml2argvdata/graphics-spice-timeout.xml @@ -15,7 +15,7 @@ - + core2duo Intel diff --git a/tests/qemuxml2xmloutdata/graphics-spice-timeout.x86_64-latest.xml b/tests/qemuxml2xmloutdata/graphics-spice-timeout.x86_64-latest.xml index fd34a6caf5..9e6782d00b 100644 --- a/tests/qemuxml2xmloutdata/graphics-spice-timeout.x86_64-latest.xml +++ b/tests/qemuxml2xmloutdata/graphics-spice-timeout.x86_64-latest.xml @@ -15,7 +15,7 @@ - + core2duo Intel