Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
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.
Description of problem:
qemu-kvm: Requested safe cache capability level not supported by kvm, try appending -machine cap-cfpc=broken
... when building indirection images in brew.
Extended errors:
libguestfs: launch libvirt guest
libguestfs: error: could not create appliance through libvirt.
Try running qemu directly without libvirt using this environment variable:
export LIBGUESTFS_BACKEND=direct
Original error from libvirt: internal error: process exited while connecting to monitor: 2020-08-05T20:00:42.080975Z qemu-kvm: Requested safe cache capability level not supported by kvm, try appending -machine cap-cfpc=broken [code=1 int1=-1]
libguestfs: trace: launch = -1 (error)
libguestfs: trace: close
libguestfs: closing guestfs handle 0x1001c6cde80 (state 0)
libguestfs: command: run: rm
libguestfs: command: run: \ -rf /tmp/libguestfs9Sb7CN
libguestfs: command: run: rm
libguestfs: command: run: \ -rf /tmp/libguestfsVCqvKz
Version-Release number of selected component (if applicable): qemu-kvm-15:4.2.0-29.module+el8.3.0+7212+401047e6 from virt:rhel
How reproducible: 100%
Steps to Reproduce:
1. Run an indirectionimage build in brew which uses libguestfs to finalize information in qcow2 images.
Actual results:
ppc64le builds fail
x86_64 builds work
Expected results:
Both architectures work
Additional info:
1. This happens regardless of whether LIBGUESTFS_BACKEND=direct is used.
2. This is a new problem on RHEL 8.3.0 builds. 8.2.x builds work correctly.
There are several possibilities.
a. It could be bug 1726075. I suspect not, but I can't rule it out since the qemu version isn't given.
b. It could be that the host doesn't have a recent enough firmware to implement the Spectre workarounds that qemu is trying to activate
c. It could be that libguestfs is trying to use KVM PR rather than KVM HV.
To narrow this down we'll need:
1) What sort of machine is this happening on? POWER8? POWER9? Which model?
2) Is this happening in: a bare metal host? an LPAR under PowerVM? a KVM guest?
3) What KVM modules are loaded? (lsmod output)
4) What firmware versions are on the system (output of "lsprop /proc/device-tree/ibm,firmware-versions")
Note: retried with AV 8.3.0 with this build:
qemu-kvm ppc64le 15:5.0.0-0.module+el8.3.0+6620+5d5e1420
Same failure, FWIW.
I will submit tasks with "cat /proc/cpuinfo", "lsmod", - are there any other things we need to gather?
I can follow up with the hardware owners to figure out the host's hardware information.
I believe the build occurs within a KVM guest. ImageFactory boots a VM using KVM from a "utility image", which contains the environment necessary to build application-specific images (in this case, initrds as well as full operating system images). ImageFactory then SSHs in to the host commands.
Among these commands are various 'virt-customize' and such, which, due to the architecture of libguestfs, launch "lite VMs" inside the VM in order to perform those tasks.
(Again - this works on 8.2.0.)
For the record, the problem is introduced by:
commit 2782ad4c4102d57f7f8e135dce0c1adb0149de77
Author: Suraj Jitindar Singh <sjitindarsingh>
Date: Fri Mar 1 15:46:09 2019 +1100
target/ppc/spapr: Enable mitigations by default for pseries-4.0 machine type
There are currently 3 mitigations the availability of which is controlled
by the spapr-caps mechanism, cap-cfpc, cap-sbbc, and cap-ibs. Enable these
mitigations by default for the pseries-4.0 machine type.
By now machine firmware should have been upgraded to allow these
settings.
Signed-off-by: Suraj Jitindar Singh <sjitindarsingh>
Message-Id: <20190301044609.9626-3-sjitindarsingh>
Signed-off-by: David Gibson <david.id.au>
This explain why it works with rhel-8.2.0 (not rhel-av-8.2.0) because it is based on pseries-3.1 (pseries-rhel7.6.0).
All the pseries-rhel8.X.0 have this change (provided by rhel-8.3.0 and all rhel-av-8.X.0).
The content of /sys/devices/system/cpu/vulnerabilities/* might also help to know the vulnerability level.
And the result of "lsprop /proc/device-tree/ibm,opal/fw-features/*/" helps to know the firmware level.
I think we need either in the vulnerabilities "Meltdown: Not affected" (to enable cap-cfpc=fixed) or
(to enable cap-cpfc=workaround) we need "inst-l1d-flush-trig2" and "inst-l1d-flush-ori30,30,0" set to enabled in fw-features.
"fw-l1d-thread-split" is needed on P9 but not on P8.
(In reply to Laurent Vivier from comment #12)
...
> (to enable cap-cpfc=workaround) we need "inst-l1d-flush-trig2" and
> "inst-l1d-flush-ori30,30,0" set to enabled in fw-features.
we need "inst-l1d-flush-trig2" or "inst-l1d-flush-ori30,30,0", not both.
I was late getting this information, however - the data show that this isn't actually a bug in qemu; simply outdated firmware. I'll file a ticket to get that updated.