Bug 1325085 - libvirt doesn't recognize arm/aarch64 versioned virt-* machinetypes as capable of multiple PCI buses, names them all "pci"
Summary: libvirt doesn't recognize arm/aarch64 versioned virt-* machinetypes as capabl...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: libvirt
Version: 24
Hardware: armv7hl
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Libvirt Maintainers
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedBlocker
: 1327289 (view as bug list)
Depends On:
Blocks: TRACKER-bugs-affecting-libguestfs F24BetaBlocker
TreeView+ depends on / blocked
 
Reported: 2016-04-08 07:35 UTC by Richard W.M. Jones
Modified: 2016-04-19 20:30 UTC (History)
14 users (show)

Fixed In Version: libvirt-1.3.3-2.fc24
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-04-19 20:30:34 UTC
Type: Bug


Attachments (Terms of Use)
build.log (4.75 MB, text/plain)
2016-04-08 07:37 UTC, Richard W.M. Jones
no flags Details
root.log (204.07 KB, text/plain)
2016-04-08 07:38 UTC, Richard W.M. Jones
no flags Details

Description Richard W.M. Jones 2016-04-08 07:35:00 UTC
Description of problem:

Libvirt assigns the same addr to two PCI devices, so qemu fails
to start with the error:

qemu-system-arm: -device pci-bridge,chassis_nr=2,id=pci,bus=pci,addr=0x1: Duplicate ID 'pci' for device

On the qemu command line:

-device i82801b11-bridge,id=pci,bus=pci,addr=0x1 -device pci-bridge,chassis_nr=2,id=pci,bus=pci,addr=0x1

Version-Release number of selected component (if applicable):

libvirt 1.3.3-1.fc25

How reproducible:

Unknown, at least once.

Steps to Reproduce:
1. Run `libguestfs-test-tool'.

Attached:

build.log
root.log

Please see the end of build.log for the full libvirt XML, qemu
command line, and libvirt debugging.

Comment 1 Richard W.M. Jones 2016-04-08 07:37:39 UTC
Created attachment 1145040 [details]
build.log

Comment 2 Richard W.M. Jones 2016-04-08 07:38:17 UTC
Created attachment 1145041 [details]
root.log

Comment 3 Ján Tomko 2016-04-08 08:22:40 UTC
libvirt is not ready for versioned "virt" machine types.

"virt-2.6" does not match the condition in virQEMUCapsHasPCIMultiBus:
http://libvirt.org/git/?p=libvirt.git;a=blob;f=src/qemu/qemu_capabilities.c;h=5d09dc8f3e2;hb=6e244c65#l2177
2173     if (ARCH_IS_ARM(def->os.arch)) {
2174         /* If 'virt' supports PCI, it supports multibus.
2175          * No extra conditions here for simplicity.
2176          */
2177         if (STREQ(def->os.machine, "virt"))
2178             return true;
2179     }

so it assigns the same "pci" alias to all pci controllers:
http://libvirt.org/git/?p=libvirt.git;a=blob;f=src/qemu/qemu_alias.c;h=ade2033e273c8;hb=6e244c659fb0045#l123
 129     if (controller->type == VIR_DOMAIN_CONTROLLER_TYPE_PCI) {
 130         if (!virQEMUCapsHasPCIMultiBus(qemuCaps, domainDef)) {
 131             /* qemus that don't support multiple PCI buses have
 132              * hardcoded the name of their single PCI controller as
 133              * "pci".
 134              */
 135             return VIR_STRDUP(controller->info.alias, "pci");

Comment 4 Ján Tomko 2016-04-08 08:52:24 UTC
Proposed upstream patch:
https://www.redhat.com/archives/libvir-list/2016-April/msg00327.html

Comment 5 Ján Tomko 2016-04-08 12:19:30 UTC
Should be fixed by:
commit f06ca25d235433f9139cbfb3d5d9eae7409156b9
Author:     Ján Tomko <jtomko@redhat.com>
CommitDate: 2016-04-08 14:15:51 +0200

    qemu: support virt-2.6 machine type on arm
    
    Some places already check for "virt-" prefix as well as plain "virt".
    virQEMUCapsHasPCIMultiBus did not, resulting in multiple PCI devices
    having assigned the same unnumbered "pci" alias.
    
    Add a test for the "virt-2.6" machine type which also omits the
    <model type='virtio'/> in <interface>, to check if
    qemuDomainDefaultNetModel works too.
    
    https://bugzilla.redhat.com/show_bug.cgi?id=1325085

git describe: v1.3.3-36-gf06ca25

Comment 6 Dennis Gilmore 2016-04-14 17:01:11 UTC
*** Bug 1327289 has been marked as a duplicate of this bug. ***

Comment 7 Dennis Gilmore 2016-04-14 17:04:05 UTC
proposing as a Fedora 24 Beta blocker

https://fedoraproject.org/wiki/Fedora_24_Beta_Release_Criteria#Virtualization_requirements

this prevents virtualisation from working

Comment 8 Fedora Update System 2016-04-15 11:54:01 UTC
libvirt-1.3.3-2.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-9efb51303d

Comment 9 Richard W.M. Jones 2016-04-15 15:24:47 UTC
Also affects aarch64:
qemu-system-aarch64-2.6.0-0.1.rc1.fc24.aarch64
libvirt-1.3.3-1.fc24.aarch64

Original error from libvirt: internal error: process exited while connecting to 
monitor: qemu-system-aarch64: -device pci-bridge,chassis_nr=2,id=pci,bus=pci,addr=0x1: Duplicate ID 'pci' for device [code=1 int1=-1]

Comment 10 Fedora Update System 2016-04-15 23:21:43 UTC
libvirt-1.3.3-2.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-9efb51303d

Comment 11 Kamil Páral 2016-04-18 16:24:21 UTC
Discussed at today's blocker review meeting [1]. Voted as AcceptedBlocker (Beta) - as described, the bug is a violation of "The release must be able host virtual guest instances of the same release." on ARM (a primary arch).

[1] https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2016-04-18

Comment 12 Richard W.M. Jones 2016-04-18 16:56:34 UTC
On aarch64, libvirt-1.3.3-2.fc24.aarch64 fixes the problem.

Still testing on armv7hl.

Comment 13 Richard W.M. Jones 2016-04-18 17:13:49 UTC
Looks like I can't test armv7 (because of bug 1315895).

Comment 14 Paul Whalen 2016-04-18 21:08:40 UTC
confirmed, libvirt-1.3.3-2.fc24.armv7hl also working

Comment 15 Fedora Update System 2016-04-19 20:30:24 UTC
libvirt-1.3.3-2.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.


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