Bug 1850680 - hypervisor-cpu-compare raises internal error for host-passthrough cpu model
Summary: hypervisor-cpu-compare raises internal error for host-passthrough cpu model
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: libvirt
Version: 8.3
Hardware: s390x
OS: Linux
Target Milestone: rc
: 8.4
Assignee: Tim Wiederhake
QA Contact: smitterl
Depends On: 1660904
Blocks: 1796871
TreeView+ depends on / blocked
Reported: 2020-06-24 17:28 UTC by smitterl
Modified: 2021-05-18 15:21 UTC (History)
11 users (show)

Fixed In Version: libvirt-6.0.0-29.el8
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2021-05-18 15:21:15 UTC
Type: Bug
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Github autotest tp-libvirt pull 3142 0 None closed Fix hypervisor-cpu-compare for host-processor on s390x 2021-02-10 03:53:16 UTC
IBM Linux Technology Center 186434 0 None None None 2020-06-25 09:42:47 UTC
Red Hat Bugzilla 1660904 1 None None None 2021-02-04 07:12:47 UTC
Red Hat Bugzilla 1850614 0 medium CLOSED hypervisor-cpu-compare succeeds on invalid cpu definition 2023-02-12 18:56:56 UTC

Description smitterl 2020-06-24 17:28:25 UTC
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):

How reproducible:

Steps to Reproduce:
1. Define passthrough-cpu.xml as <cpu check="none" mode="host-passthrough" />
2. # virsh hypervisor-cpu-compare /root/passthrough-cpu.xml 

Actual results:
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

Expected results:
Similar to x86_64
The CPU provided by hypervisor on the host is a superset of CPU described in /root/passthrough-cpu.xml

Additional info:
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 1 IBM Bug Proxy 2020-06-25 22:11:00 UTC
------- 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

Comment 2 Thomas Huth 2020-09-14 12:08:15 UTC
(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:
> https://www.redhat.com/archives/libvir-list/2020-June/msg01232.html

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 3 IBM Bug Proxy 2020-09-15 14:14:28 UTC
------- 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.

Comment 4 Thomas Huth 2020-09-21 07:34:28 UTC
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.

Comment 5 Tim Wiederhake 2020-09-23 07:35:57 UTC
Updated the patch proposed in #2 as https://www.redhat.com/archives/libvir-list/2020-September/msg01177.html

Comment 6 Thomas Huth 2020-09-29 08:13:24 UTC
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...

Comment 8 Tim Wiederhake 2020-10-01 07:54:28 UTC
I can confirm that backporting is feasible and easy. I do not expect any adverse side effects.

Comment 13 smitterl 2020-11-05 13:03:32 UTC

Verified with:

# 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)
JOB TIME   : 95.26 s

Comment 15 errata-xmlrpc 2021-05-18 15:21:15 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.