(In reply to Andrea Bolognani from comment #0)
> When using PCI addresses for the network device on aarch64, the
> guest is not able to start with the following error:
> 
>   internal error: early end of file from monitor, possible
>   problem: 2016-05-11T16:42:28.837452Z abologna-qemu-kvm: -device
>  
> virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:10:e9:80,bus=pci.2,
> addr=0x1:
>   failed to find romfile "efi-virtio.rom"
> 
> It's been confirmed upstream[1][2] that the relevant ROM is
> missing on purpose, so virt-manager should take care to add
> 
>   <rom bar='off'/>
> 
> to any interface using PCI addresses when creating aarch64
> guests, so that they can boot.

Is that necessarily the right solution?  Does virt-manager/libvirt then need a table of implicit ROMs per device so that it can test whether the ROM is present and disable the PCI BAR if not?  It seems much easier to put that logic in QEMU, ie. do not make failure to load an implicit romfile fatal.

Since this is now assigned to qemu-kvm-rhev, a better bug title
is in order. I've taken a stab at it, but feel free to improve
upon it :)

Please note that libvirt 3.0.0, releasing upstream early next
week, will use virtio-pci by default for aarch64/virt guests.

That works seamlessly with upstream packages, but due to this
bug installation will fail on RHEL with:

  ERROR    internal error: qemu unexpectedly closed the
  monitor: 2017-01-13T14:45:56.610081Z qemu-kvm: -device
  virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:63:70:4d,bus=pci.1,addr=0x0:
  failed to find romfile "pxe-virtio.rom"

Until the bug has been fixed, it can be worked around
by adding:

  rom_bar=off

to virt-install's --network option.

Here's a working virt-install command line for reference:

  virt-install \
    --name $guest \
    --location $URL \
    --arch aarch64 \
    --machine virt \
    --ram 2048 \
    --vcpus 4 \
    --accelerate \
    --graphics none \
    --os-variant fedora22 \
    --disk size=5,bus=scsi \
    --controller scsi,model=virtio-scsi \
    --network network=default,model=virtio,rom_bar=off

Fix included in qemu-kvm-rhev-2.8.0-5.el7

*** Bug 1460923 has been marked as a duplicate of this bug. ***

May I kindly ask if this change in qemu-kvm-rhev-2.8.0-5.el7 is specific to
virtio-net-pci? Currently, when not having ipxe-roms-qemu installed, this
leads (when using a common libvirt client) to a qemu-kvm failure, because the
qemu-kvm expects an existing ROM file by default as it seems (and e.g. the
virt-manager doesn't seem to provide a way to tell "rom_bar=off").

(In reply to Robert Scheck from comment #19)
> May I kindly ask if this change in qemu-kvm-rhev-2.8.0-5.el7 is specific to
> virtio-net-pci?

Yes, it is. In downstream commit 8475d69938a1 ("hw/arm/virt: Disable virtio-net-pci option ROM file loading", 2017-02-15) -- which exists only on our internal 2.8-based development branch and has been squashed with other downstream-only changes, on the to-be-released 2.9-based development branch, in commit d682dec685d0 ("Add RHEL 7 machine types", 2014-12-14) --, we set the

  virtio-net-pci.romfile

property to "", for the "virt-rhel7.4.0" machine type of qemu-system-aarch64.

> Currently, when not having ipxe-roms-qemu installed, this

By "this", do you mean "the issure reported in this BZ"?

> leads (when using a common libvirt client) to a qemu-kvm failure, because the
> qemu-kvm expects an existing ROM file by default as it seems (and e.g. the
> virt-manager doesn't seem to provide a way to tell "rom_bar=off").

Can you provide more details please? Normally, "ipxe-roms-qemu" is a runtime / install dependency of "qemu-kvm-rhev". (Well, except on aarch64 (bug 1337496) and s390x (bug 1449939).) Since none of these changes have been released yet, I'm unsure how you run into a situation where qemu-kvm-rhev is installed, ipxe-roms-qemu is not, and then /usr/libexec/qemu-kvm fails to load the iPXE oprom for the NIC. Can you please clarify? Thanks!

(In reply to Laszlo Ersek from comment #20)
> Can you provide more details please? Normally, "ipxe-roms-qemu" is a runtime
> / install dependency of "qemu-kvm-rhev". (Well, except on aarch64 (bug
> 1337496) and s390x (bug 1449939).) Since none of these changes have been
> released yet, I'm unsure how you run into a situation where qemu-kvm-rhev is
> installed, ipxe-roms-qemu is not, and then /usr/libexec/qemu-kvm fails to
> load the iPXE oprom for the NIC. Can you please clarify? Thanks!

I am working with libvirt upstream outside of the RHEL scope - and I tried
to get rid of the iPXE related ROM files (= ipxe-roms-qemu dependency). When
searching regarding libvirt and rom_bar=off, I found this bug report and had
the hope that it's maybe addressed in a more generic way in libvirt. But I
don't want to hijack this bug report with an issue that's outside of scope.

I understand, thank you.

You might find bug 1425058 relevant. As far as I understand, said bug is exactly about your use case, and it still requires an upstream libvirt patch (i.e., it's not just a backport BZ for RHEL).

(In reply to Laszlo Ersek from comment #22)
> You might find bug 1425058 relevant.

Wow, thank you very much! And yes, that's exactly what I am looking for;
sorry for the wrong noise on this bug report.

This BZ is being closed as CURRENTRELEASE because it falls
into the following criteria:

o It's an aarch64 virt BZ for RHEL7
o It's on ON_QA or VERIFIED state
o Resolution seems to be in place for some years

If you have objections, please add a comment or re-open the BZ.