Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1511991 - Implement "virsh cpu-models s390x"
Summary: Implement "virsh cpu-models s390x"
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libvirt
Version: 7.5-Alt
Hardware: s390x
OS: Linux
Target Milestone: rc
: ---
Assignee: Jiri Denemark
QA Contact: Virtualization Bugs
Depends On:
TreeView+ depends on / blocked
Reported: 2017-11-10 15:26 UTC by David Hildenbrand
Modified: 2018-05-28 14:28 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2018-05-11 14:20:18 UTC
Target Upstream Version:

Attachments (Terms of Use)

Description David Hildenbrand 2017-11-10 15:26:37 UTC
Description of problem:

"virsh cpu-models s390x" is not yet wired up, while we have information about CPU models already in libvirt (e.g. via "virsh domcapabilities").

Steps to Reproduce:

1. "virsh cpu-models s390x"

Actual results:

[root@ibm-z-63 ~]# virsh cpu-models s390x
all CPU models are accepted

Expected results:

List of usable CPU models like on x86.

Comment 2 Jiri Denemark 2018-05-11 14:20:18 UTC
The virConnectGetCPUModelNames API presented by virsh as cpu-models command
was designed to list CPU models supported by libvirt on a specific
architecture. The API doesn't check whether the CPU models are actually
supported by the hypervisor. On some architectures (x86_64 and ppc64) libvirt
has an internal list of supported CPU models while it accepts any CPU model on
other architectures (aarch64, s390x). That is, any CPU model supported by the
hypervisor can be used on these architectures. This is why "all CPU models are
accepted" message is printed by virsh.

In other words, the virConnectGetCPUModelNames API is implemented correctly
for all archs and the observed result is expected. We cannot change the
semantics of the existing API to differ depending on the architecture and list
CPU models accepted by the hypervisor on s390x as requested by this request.

Another issue is that the existing API does not have enough input parameters
to let the caller specify which QEMU binary or domain type (KVM vs TCG) should
be used when reporting the list of CPU models.

So we would need to implement a completely new API with different semantics
and larger set of input parameters. However, as you correctly said the list of
CPU models accepted by a specific QEMU binary is provided in domain
capabilities XML (returned by virsh domcapabilities). Originally, I thought
(without checking) that the domain capabilities XML lists all CPU models
without filtering those which are not supported by libvirt (this would be
irrelevant for s390x), but it's not the case. The CPU models listed in domain
capabilities XML is already filtered and CPU models unsupported by libvirt
will not be reported there. Thus the new API would just duplicate a small part
of the functionality of virConnectGetDomainCapabilities API. And since the
domain capabilities XML shows not only a list of CPU models, but also reports
whether each CPU model is directly usable on current host, I don't see a need
for the new API at all.

That said, we should improve the documentation of the
virConnectGetCPUModelNames API and virsh cpu-models command and direct people
at domain capabilities XML.

Comment 3 Jiri Denemark 2018-05-28 14:28:15 UTC
The improved documentation is now upstream:

commit 95ef9ceea44d3672e0adc644839bd7422a3e0b8b
Refs: v4.3.0-339-g95ef9ceea4
Author:     Jiri Denemark <>
AuthorDate: Fri May 11 16:24:44 2018 +0200
Commit:     Jiri Denemark <>
CommitDate: Mon May 28 15:54:10 2018 +0200

    Improve documentation of virConnectGetCPUModelNames

    Signed-off-by: Jiri Denemark <>
    Reviewed-by: Collin Walling <>
    Reviewed-by: Kashyap Chamarthy <>
    Reviewed-by: Ján Tomko <>

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