Bug 1337510
Summary: | Don't try to use a romfile for virtio-net-pci on aarch64 | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | Andrea Bolognani <abologna> |
Component: | qemu-kvm-rhev | Assignee: | Eric Auger <eric.auger> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Chao Yang <chayang> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 7.3 | CC: | alex.williamson, chayang, drjones, dyuan, jfeeney, juzhang, juzhou, knoel, kraxel, lersek, mrezanin, mxie, mzhan, phrdina, redhat-bugzilla, tzheng, virt-maint, wei, xchen, xiaodwan |
Target Milestone: | rc | Keywords: | OtherQA |
Target Release: | --- | ||
Hardware: | aarch64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | qemu-kvm-rhev-2.8.0-5.el7 | Doc Type: | If docs needed, set a value |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2020-03-09 19:09:59 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 1173755 |
Description
Andrea Bolognani
2016-05-19 11:13:27 UTC
(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. |