Description of problem:
On s390x, host-passthrough cpu definition causes error.
By manpage for hypervisor-cpu-compare:
"The guest CPU definition is the <cpu> element and its contents from the domain XML definition"
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Define passthrough-cpu.xml as <cpu check="none" mode="host-passthrough" />
2. # virsh hypervisor-cpu-compare /root/passthrough-cpu.xml
error: Failed to compare hypervisor CPU with /root/passthrough-cpu.xml
error: internal error: unable to execute QEMU command 'query-cpu-model-comparison': Invalid parameter type for 'modelb.name', expected: string
Similar to x86_64
The CPU provided by hypervisor on the host is a superset of CPU described in /root/passthrough-cpu.xml
Not sure if expected result on x86_64 makes sense; shouldn't it be identical? Maybe this is related to the parsing issue https://bugzilla.redhat.com/show_bug.cgi?id=1850614
------- Comment From Collin.Walling 2020-06-25 18:00 EDT-------
I've proposed a single patch to the libvirt list to amend this. There may be some non-s390 specific things that need to be accounted for, but this should set things in the right direction.
The patch can be found here: https://www.redhat.com/archives/libvir-list/2020-June/msg01232.html
(In reply to IBM Bug Proxy from comment #1)
> ------- Comment From Collin.Walling 2020-06-25 18:00 EDT-------
> I've proposed a single patch to the libvirt list to amend this. There may be
> some non-s390 specific things that need to be accounted for, but this should
> set things in the right direction.
> The patch can be found here:
Any news on that one? ... If I got the replies there right, the first approach was rejected? Did you ever send a v2?
Anyway, it's getting late for RHEL 8.3, so I moved the Target Release to 8.4 now.
------- Comment From Collin.Walling 2020-09-15 10:06 EDT-------
I posted a ping to the list last month, CC'ing the appropriate maintainer this time asking for guidance. Still no response. I'll spin up a v2 with the minor altercations that were discussed and see if it gets attention.
Hi! Seems like the patch is still not upstream? I'm moving this into the backlog for the time being, please let us know once the patch gets merged upstream.
Updated the patch proposed in #2 as https://www.redhat.com/archives/libvir-list/2020-September/msg01177.html
Patch is upstream now:
("qemu: substitute missing model name for host-passthrough")
Tim, do you think it's still feasible to backport this patch for RHEL8.4? If so, I'd move it out of the backlog back into the release...
I can confirm that backporting is feasible and easy. I do not expect any adverse side effects.
# echo '<cpu check="none" mode="host-passthrough" />' > passthrough-cpu.xml
# virsh hypervisor-cpu-compare ./passthrough-cpu.xml
CPU described in ./passthrough-cpu.xml is identical to the CPU provided by hypervisor on the host
Related for automation review: https://bugzilla.redhat.com/show_bug.cgi?id=1850654
# avocado run --vt-type libvirt --vt-machine-type s390-virtio --vt-connect-uri qemu:///system virsh.hypervisor_cpu_compare
JOB ID : 3c7f32d20d618292c9b808dac10d7ee1023bc955
JOB LOG : /root/avocado/job-results/job-2020-11-05T07.55-3c7f32d/job.log
(01/16) type_specific.io-github-autotest-libvirt.virsh.hypervisor_cpu_compare.none_option: PASS (5.41 s)
(02/16) type_specific.io-github-autotest-libvirt.virsh.hypervisor_cpu_compare.virttype_option.normal_test: PASS (5.68 s)
(03/16) type_specific.io-github-autotest-libvirt.virsh.hypervisor_cpu_compare.virttype_option.invalid_virttype: PASS (5.49 s)
(04/16) type_specific.io-github-autotest-libvirt.virsh.hypervisor_cpu_compare.virttype_emulator_option.normal_test: PASS (5.70 s)
(05/16) type_specific.io-github-autotest-libvirt.virsh.hypervisor_cpu_compare.virttype_emulator_option.invalid_emulator: PASS (5.89 s)
(06/16) type_specific.io-github-autotest-libvirt.virsh.hypervisor_cpu_compare.virttype_emulator_arch_option.normal_test: PASS (6.14 s)
(07/16) type_specific.io-github-autotest-libvirt.virsh.hypervisor_cpu_compare.virttype_emulator_arch_option.invalid_arch: PASS (5.51 s)
(08/16) type_specific.io-github-autotest-libvirt.virsh.hypervisor_cpu_compare.virttype_emulator_arch_machine_option.normal_test: PASS (5.76 s)
(09/16) type_specific.io-github-autotest-libvirt.virsh.hypervisor_cpu_compare.virttype_emulator_arch_machine_option.invalid_machine: PASS (5.62 s)
(10/16) type_specific.io-github-autotest-libvirt.virsh.hypervisor_cpu_compare.domcapa_xml: PASS (5.71 s)
(11/16) type_specific.io-github-autotest-libvirt.virsh.hypervisor_cpu_compare.dom_xml.custom_mode.action_none: PASS (5.67 s)
(12/16) type_specific.io-github-autotest-libvirt.virsh.hypervisor_cpu_compare.dom_xml.custom_mode.define_content: PASS (6.83 s)
(13/16) type_specific.io-github-autotest-libvirt.virsh.hypervisor_cpu_compare.dom_xml.host_passthrough: PASS (7.06 s)
(14/16) type_specific.io-github-autotest-libvirt.virsh.hypervisor_cpu_compare.cpu_xml.f_domxml: PASS (5.44 s)
(15/16) type_specific.io-github-autotest-libvirt.virsh.hypervisor_cpu_compare.cpu_xml.f_domcapa_xml: PASS (5.76 s)
(16/16) type_specific.io-github-autotest-libvirt.virsh.hypervisor_cpu_compare.cpu_xml.illegal_format: PASS (5.65 s)
RESULTS : PASS 16 | ERROR 0 | FAIL 0 | SKIP 0 | WARN 0 | INTERRUPT 0 | CANCEL 0
JOB TIME : 95.26 s
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory (Moderate: virt:rhel and virt-devel:rhel security, bug fix, and enhancement update), and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.