Bug 1473390 - Add AAVMF dependency for QEMU on aarch64
Add AAVMF dependency for QEMU on aarch64
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm (Show other bugs)
7.4-Alt
aarch64 Linux
unspecified Severity high
: rc
: ---
Assigned To: Miroslav Rezanina
Virtualization Bugs
: OtherQA, Reopened
Depends On:
Blocks: 1173755
  Show dependency treegraph
 
Reported: 2017-07-20 12:46 EDT by Karen Mezick
Modified: 2017-08-15 07:32 EDT (History)
14 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-08-01 03:13:14 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Log from the failed job (80.77 KB, text/plain)
2017-07-20 12:46 EDT, Karen Mezick
no flags Details

  None (edit)
Description Karen Mezick 2017-07-20 12:46:03 EDT
Created attachment 1301891 [details]
Log from the failed job

Description of problem:
The avocado test unattended_install was executed on an apm-mustang system running  RHEL-ALT-7.4-20170707.n.0 Server aarch64

The following error occurred:

IOError: [Errno 2] No such file or directory:
'/usr/share/AAVMF/AAVMF_VARS.fd'

We worked around the error by getting the latest edk2 package from Gerd's latest build: 
https://www.kraxel.org/repos/jenkins/edk2/edk2.git-aarch64-0-20170711.b2794.gb1fe202.noarch.rpm

Upon further investigation, Jeff Nelson found that in the file qemu-kvm/redhat/qemu-kvm.spec.template near lines 89-97, the
dependency on AAVMF firmware is missing for aarch64:

ExclusiveArch: x86_64 %{power64} aarch64 s390x
%ifarch %{ix86} x86_64
Requires: seabios-bin >= 1.10.2-1
Requires: sgabios-bin
%endif
%ifnarch aarch64 s390x
Requires: seavgabios-bin >= 1.10.2-1
Requires: ipxe-roms-qemu >= 20170123-1
%endif

We would like more understanding regarding why a package which seems to be necessary for basic qemu operation on ARM is not yet included with the distro.

Version-Release number of selected component (if applicable):
qemu-kvm-2.9.0-16.el7a.aarch64

How reproducible:
100%

Steps to Reproduce:
1.Install avocado on an aarch64 system
2.Run unattended_install test: /usr/bin/avocado run io-github-autotest-qemu.unattended_install.url.extra_cdrom_ks.default_install.aio_native --vt-guest-os RHEL.7.devel.aarch64 --vt-extra-params url = http://download.devel.redhat.com/released/RHEL-7/7.3/Server/aarch64/os/


Actual results:
IOError: [Errno 2] No such file or directory:
'/usr/share/AAVMF/AAVMF_VARS.fd'


Expected results:
Firmware files should be present.

Additional info:
Comment 3 Karen Mezick 2017-07-21 13:19:00 EDT
This issue is being re-opened because we do have a downstream dependency between qemu-kvm and the firmware. The dependency from qemu-kvm to AAVMF should exist so that the user doesn't have to install AAVMF separately; it should automatically be installed on aarch64 whenever qemu-kvm is installed similar to how it works in RHEL on other architectures (x86_64, ppc64).
Comment 4 Miroslav Rezanina 2017-07-22 05:27:18 EDT
We can add the dependency as it's logical from usage point. 

However,  it is not qemu-kvm using AAVMF_VARS.fd here - it is used by virttest to run qemu-kvm guest. So the dependency should be add for the test package. It is possible to run qemu-kvm without AAVMF installed.
Comment 5 Andrew Jones 2017-07-24 03:14:22 EDT
For convenience to users, I'm OK with adding the dependency to qemu-kvm. I'm
still a bit on the fence about it, though, because technically qemu-kvm does
not depend on AAVMF, and if a user knows they need to install qemu-kvm for virt use, then they can also learn to install AAVMF. IMO, the user shouldn't need to know either though, as all these packages should be wrapped up in the high-level "Virtualization Host" group, and 'yum groupinstall' should work. IOW, I'm tempted to dup this to bug 1364532 (which, despite it being CLOSED, still doesn't work). I'll leave the decision to Miroslav though.
Comment 6 Laszlo Ersek 2017-07-25 07:31:41 EDT
IMO, we don't necessarily have to reevaluate this question for aarch64, we can as well look at the x86_64 concepts and follow suit. On x86_64, the default virtual firmware binary is provided by the "seabios-bin" package, and "qemu-kvm-rhev" and "qemu-kvm" both require "seabios-bin" (on the RPM Requires: level).

On aarch64, the default virtual fw binary comes from the AAVMF package, which suggests that "qemu-kvm" (the aarch64 build) be made dependent on "AAVMF", to stay in sync with x86_64.

Just my opinion of course.
Comment 7 Andrew Jones 2017-07-25 08:00:31 EDT
(In reply to Laszlo Ersek from comment #6)
> IMO, we don't necessarily have to reevaluate this question for aarch64, we
> can as well look at the x86_64 concepts and follow suit. On x86_64, the
> default virtual firmware binary is provided by the "seabios-bin" package,
> and "qemu-kvm-rhev" and "qemu-kvm" both require "seabios-bin" (on the RPM
> Requires: level).
> 
> On aarch64, the default virtual fw binary comes from the AAVMF package,
> which suggests that "qemu-kvm" (the aarch64 build) be made dependent on
> "AAVMF", to stay in sync with x86_64.
> 

But can an x86 guest be boot without seabios/OVMF? If so, then I agree 100% with this. If not, then we still have the argument that QEMU doesn't technically depend on guest firmware for AArch64 guests. Of course guests boot with ACPI do require AAVMF, so effectively we have the dependency, as we only support booting RHEL-ALT guests with ACPI.

Anyway, I'm for adding the dependency to the RPM. I just don't want anyone to misunderstand the motivation; convenience.
Comment 8 Laszlo Ersek 2017-07-26 06:13:38 EDT
I guess we should consider "Recommends:" then:

  https://fedoraproject.org/wiki/Packaging:WeakDependencies

  "[...] Weak dependencies may only be used in a package if the package still
  functions without the dependency present. It is acceptable, however, to
  create packages that have very limited functionality without adding any of
  its weak requirements [...]"

But, I don't know how frequently we use "Recommends:" in RHEL packages.
Comment 9 Miroslav Rezanina 2017-08-01 03:13:14 EDT
I would like this option. Unfortunately, it's not supported in RHEL 7 environment.

I do not like the hard dependency here. Unlike seabios, qemu-kvm can work without AAVMF. We do not require OVMF for x86 so we shouldn't require AAVMF either.

We should ensure AAVMF is part of Virtualization group and properly documented.
Comment 10 Jeff Nelson 2017-08-08 11:09:43 EDT
Can someone describe for me a supported use case of qemu-kvm that does not require AAVMF? I'm having trouble coming up with one.
Comment 11 Andrew Jones 2017-08-09 05:13:03 EDT
(In reply to Jeff Nelson from comment #10)
> Can someone describe for me a supported use case of qemu-kvm that does not
> require AAVMF? I'm having trouble coming up with one.

There is no _supported_ use case, but VMs can be launched without AAVMF. I have no strong opinion on whether or not this dependency is added, but typically dependencies are only added (afaik) when there's a _technical_ dependency. In this case we'd be adding it because there's an effective dependency due to how we configure our supported use cases, avoiding the easy mistake of forgetting to install AAVMF for those supported use cases - a.k.a for convenience. If we're fine with bending the meaning of dependency outside the scope of the purely technical, then let's just add it.
Comment 12 Lukas Doktor 2017-08-15 05:46:33 EDT
Also don't forget people might want to run arm on x86 requiring AAVMF, should it also be added as dependency there? I don't think so. Dependencies are suppose to be "must have" things and not "could benefit in having", that's why groups exists.
Comment 13 Laszlo Ersek 2017-08-15 07:32:33 EDT
(In reply to Lukas Doktor from comment #12)
> Also don't forget people might want to run arm on x86

This would be absolutely unsupported.

> requiring AAVMF,
> should it also be added as dependency there? I don't think so. Dependencies
> are suppose to be "must have" things and not "could benefit in having",
> that's why groups exists.

This would only be relevant if a QEMU emulator binary, for the aarch64 emulation target, were built for the x86_64 host architecture. No such binary is packaged or offered for any kind of RHEL OS, so any dependencies for this non-package cannot exist.

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