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).

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.

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.

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.

(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.

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.

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.

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.

(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.

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.

(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.

in Fedora 39, it seems that the file /usr/share/AAVMF/AAVMF32_CODE.fd does not exist. And if I want to start via virt-manager an arm img, it says:

Unable to complete install: 'Failed to open file /usr/share/AAVMF/AAVMF32_VARS.fd': No such file or directory

so I had to download it from archive.ubuntu.com/ubuntu/pool/main/e/edk2/qemu-efi-arm_2022.02-3_all.deb extracting the AAVMF32_VARS file, and copying it in /usr/share/AAVMF/ lol