RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1184411 - <cpu>cortex-a57</cpu> .. libvirt says: Unable to find CPU definition
Summary: <cpu>cortex-a57</cpu> .. libvirt says: Unable to find CPU definition
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libvirt
Version: 7.1
Hardware: aarch64
OS: Linux
high
high
Target Milestone: rc
: 7.2
Assignee: Andrea Bolognani
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks: TRACKER-bugs-affecting-libguestfs 1173757 1175340 1277314
TreeView+ depends on / blocked
 
Reported: 2015-01-21 10:28 UTC by Richard W.M. Jones
Modified: 2016-11-04 07:45 UTC (History)
11 users (show)

Fixed In Version: libvirt-daemon-1.3.5-1.el7.aarch64
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-11-04 07:45:31 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Richard W.M. Jones 2015-01-21 10:28:32 UTC 
Description of problem:

In qemu the default mach_virt uses a Cortex A15 CPU, which
is stupid for a 64 bit architecture.  Therefore you have to
use -cpu cortex-a57 on the qemu command line.

Unfortunately libvirt refuses to let me use <cpu><model>cortex-a57</model></cpu>,
giving the error:

  Unable to find CPU definition

This problem applies with TCG.  With KVM we are able to use
host-passthrough.

Version-Release number of selected component (if applicable):

libvirt-daemon-1.2.8-12.sa1.4.aarch64

How reproducible:

100%

Steps to Reproduce:
1. Run libguestfs under TCG.

Additional info:

libvirt XML:

<?xml version="1.0"?>
<domain type="qemu" xmlns:qemu="http://libvirt.org/schemas/domain/qemu/1.0">
  <name>guestfs-v6ubsyyn76uet5r4</name>
  <memory unit="MiB">500</memory>
  <currentMemory unit="MiB">500</currentMemory>
  <cpu>
    <model>cortex-a57</model>
  </cpu>
  <vcpu>1</vcpu>
  <clock offset="utc">
    <timer name="rtc" tickpolicy="catchup"/>
    <timer name="pit" tickpolicy="delay"/>
  </clock>
  <os>
    <type machine="virt">hvm</type>
    <loader readonly="yes" type="pflash">/usr/share/AAVMF/AAVMF_CODE.fd</loader>
    <nvram>/home/rjones/d/libguestfs/tmp/libguestfsgPniCg/AAVMF_VARS.fd.2</nvram>
    <kernel>/home/rjones/d/libguestfs/tmp/.guestfs-1000/appliance.d/kernel</kernel>
    <initrd>/home/rjones/d/libguestfs/tmp/.guestfs-1000/appliance.d/initrd</initrd>
    <cmdline>panic=1 console=ttyAMA0 earlyprintk=pl011,0x9000000 ignore_loglevel efi-rtc=noprobe udevtimeout=6000 udev.event-timeout=6000 no_timer_check lpj=500000 acpi=off printk.time=1 cgroup_disable=memory root=/dev/sdb selinux=0 guestfs_verbose=1 TERM=xterm-256color</cmdline>
  </os>
  <on_reboot>destroy</on_reboot>
  <devices>
  [omitted -- boring and irrelevant]
  </devices>
  <qemu:commandline>
    <qemu:env name="TMPDIR" value="/home/rjones/d/libguestfs/tmp"/>
  </qemu:commandline>
</domain>
Comment 1 Richard W.M. Jones 2015-01-21 10:31:27 UTC 
I remembered that I came across this bug before.  See:

https://www.redhat.com/archives/libvirt-users/2014-August/msg00043.html
https://www.redhat.com/archives/libvirt-users/2014-August/msg00049.html
Comment 2 Richard W.M. Jones 2015-01-21 16:25:35 UTC 
libguestfs workaround:
https://github.com/libguestfs/libguestfs/commit/7e4b7a346a4558a02aeb58f82d518509ce6e5d03
Comment 4 Jaroslav Suchanek 2016-04-13 11:54:59 UTC 
Andrea, please have a look at this one. Thanks.
Comment 5 Cole Robinson 2016-04-26 13:41:29 UTC 
FWIW it's very likely this is already fixed with latest RHEL bits, someone just needs to test it
Comment 6 Andrea Bolognani 2016-06-21 12:20:03 UTC 
This seems to no longer be a problem with current libvirt.
Rich, can you try removing the libguestfs workaround and
giving it another go?

By the way, I'm very confused about how the libguestfs
workaround could work in the first place: the "Unable to
find CPU definition" error is coming from qemu-kvm, not
libvirt, so it would stand to reason that using <qemu:arg>
to add the same '-cpu cortex-a57' option libvirt would add
because of <cpu><model>cortex-a57</model></cpu> would lead
to the same failure...
Comment 7 Richard W.M. Jones 2016-06-21 13:49:40 UTC 
I tested this by reverting libguestfs commit 7e4b7a346a4558a02ae and
using this command against the latest libguestfs sources:

$ make quickcheck \
    LIBGUESTFS_BACKEND=libvirt LIBGUESTFS_BACKEND_SETTINGS=force_tcg

Host      libvirt version                    Result

RHEL 7    libvirt-1.2.17-13.el7_2.4.aarch64  Good
RHEL 7    libvirt-1.3.5-1.el7.aarch64        Fails b/c bug 1337869
Fedora 24 libvirt-1.3.3.1-2.fc24.aarch64     Good
Fedora 24 libvirt-1.3.3.1-3.fc24.aarch64     Good

I also checked that the right -cpu flag was being passed.

So I think we can declare this bug fixed.  It would be nice to
get final confirmation with bug 1337869 fixed as well, since I've
not been able to use recent versions of libvirt on RHELSA at all.

I have also pushed the revert patch to libguestfs upstream (not RHEL
however, but will consider it for inclusion in the next round of
patches).
Comment 8 Andrea Bolognani 2016-06-21 14:03:55 UTC 
(In reply to Richard W.M. Jones from comment #7)
> I tested this by reverting libguestfs commit 7e4b7a346a4558a02ae and
> using this command against the latest libguestfs sources:
> 
> $ make quickcheck \
>     LIBGUESTFS_BACKEND=libvirt LIBGUESTFS_BACKEND_SETTINGS=force_tcg
> 
> Host      libvirt version                    Result
> 
> RHEL 7    libvirt-1.2.17-13.el7_2.4.aarch64  Good
> RHEL 7    libvirt-1.3.5-1.el7.aarch64        Fails b/c bug 1337869
> Fedora 24 libvirt-1.3.3.1-2.fc24.aarch64     Good
> Fedora 24 libvirt-1.3.3.1-3.fc24.aarch64     Good
> 
> I also checked that the right -cpu flag was being passed.
> 
> So I think we can declare this bug fixed.

Nice, thanks for trying it out!

> It would be nice to
> get final confirmation with bug 1337869 fixed as well, since I've
> not been able to use recent versions of libvirt on RHELSA at all.

Do you want me to prepare a scratch build of libvirt 1.3.5
that includes the two or three commits that have been merged
upstream last week to fix Bug 1337869, hence making libvirt
usable on RHELSA once again?

I guess that wouldn't just be useful for the bug at hand.

> I have also pushed the revert patch to libguestfs upstream (not RHEL
> however, but will consider it for inclusion in the next round of
> patches).

Fair enough.
Comment 9 Richard W.M. Jones 2016-06-21 14:08:56 UTC 
Yup, added a comment on the other bug.
Comment 10 Andrea Bolognani 2016-06-21 14:19:51 UTC 
Great! Moving this one to ON_QA then.
Note You need to log in before you can comment on or make changes to this bug.