Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description of problem:
If 2 pci bridges have the same chassisNr, vm can be startup
Guest works well. However, chassis_nr used to ensure each
pci-bridge is in a different 'enclosure'. So libvirt should
ensure each chassis_nr is *unique* per pci bridge
Version-Release number of selected component (if applicable):
libvirt-1.3.5-1.el7.x86_64
qemu-kvm-rhev-2.6.0-7.el7.x86_64
How reproducible:
100%
Steps to Reproduce:
1.Set 2 pci bridges to use 1 chassisNr, start vm
<controller type='pci' index='1' model='pci-bridge'>
<model name='pci-bridge'/>
<target chassisNr='1'/>
<alias name='pci.1'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x0a' function='0x0'/>
</controller>
<controller type='pci' index='2' model='pci-bridge'>
<model name='pci-bridge'/>
<target chassisNr='1'/>
<alias name='pci.2'/>
<address type='pci' domain='0x0000' bus='0x01' slot='0x0a' function='0x0'/>
</controller>
# virsh start vm1
Domain vm1 started
# ps -ef|grep qemu
-device pci-bridge,chassis_nr=1,id=pci.1,bus=pci.0,addr=0xa -device pci-bridge,chassis_nr=1,id=pci.2,bus=pci.1,addr=0xa
2. check in guest
guest]#lspci -v
00:0a.0 PCI bridge: Red Hat, Inc. QEMU PCI-PCI bridge (prog-if 00 [Normal decode])
Flags: 66MHz, fast devsel
Memory at fea58000 (64-bit, non-prefetchable) [size=256]
Bus: primary=00, secondary=01, subordinate=02, sec-latency=0
I/O behind bridge: 0000c000-0000cfff
Memory behind bridge: fe600000-fe9fffff
Prefetchable memory behind bridge: 00000000fe000000-00000000fe1fffff
Capabilities: [4c] MSI: Enable- Count=1/1 Maskable+ 64bit+
Capabilities: [48] Slot ID: 0 slots, First+, chassis 01
Capabilities: [40] Hot-plug capable
01:0a.0 PCI bridge: Red Hat, Inc. QEMU PCI-PCI bridge (prog-if 00 [Normal decode])
Flags: 66MHz, fast devsel
Memory at fe800000 (64-bit, non-prefetchable) [size=256]
Bus: primary=01, secondary=02, subordinate=02, sec-latency=0
I/O behind bridge: 0000c000-0000cfff
Memory behind bridge: fe600000-fe7fffff
Prefetchable memory behind bridge: 00000000fe000000-00000000fe1fffff
Capabilities: [4c] MSI: Enable- Count=1/1 Maskable+ 64bit+
Capabilities: [48] Slot ID: 0 slots, First+, chassis 01
Capabilities: [40] Hot-plug capable
3.
Actual results:
PCI bridges are usable if they have the same chassis
Expected results:
Forbid to use the same chassis for more than 1 pci bridge
Additional info:
When libvirt generates the chassisNr automatically, it does so in a way that makes it unique. It is true that on real hardware the chassis_nr is used to locate a physical chassis, but for virtual machines the idea of a physical location for a chassis containing a PCI slot is nonsensical, so this parameter has no practical value (and the fact that the guest operates properly when the same chassis_nr is duplicated is good evidence of this).
Really we are only setting the chassis_nr at all in order to satisfy qemu and make sure that the guest ABI is maintained from one start to the next.
Since the guest is working properly with the duplicated chassisNr's, and there is no hard-written rule that it must be unique, I'm closing this as NOTABUG
(In reply to yangyang from comment #3)
> Hi Marcel,
>
> We discussed this problem the other day. Do you think it's acceptable if
> libvirt does not handle duplicated chassis issue.
>
> Thanks
> Yang
Hi,
Chassis_nr must be unique as required by PCI spec.
The question is here why do we need the chassis at all?
Michael,
I remember you have a good motivation for keeping the chassis nr
as mandatory, something related to pci-bridge being always the
first device in the chassis. Do you remember why?
Thanks,
Marcel
Description of problem: If 2 pci bridges have the same chassisNr, vm can be startup Guest works well. However, chassis_nr used to ensure each pci-bridge is in a different 'enclosure'. So libvirt should ensure each chassis_nr is *unique* per pci bridge Version-Release number of selected component (if applicable): libvirt-1.3.5-1.el7.x86_64 qemu-kvm-rhev-2.6.0-7.el7.x86_64 How reproducible: 100% Steps to Reproduce: 1.Set 2 pci bridges to use 1 chassisNr, start vm <controller type='pci' index='1' model='pci-bridge'> <model name='pci-bridge'/> <target chassisNr='1'/> <alias name='pci.1'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x0a' function='0x0'/> </controller> <controller type='pci' index='2' model='pci-bridge'> <model name='pci-bridge'/> <target chassisNr='1'/> <alias name='pci.2'/> <address type='pci' domain='0x0000' bus='0x01' slot='0x0a' function='0x0'/> </controller> # virsh start vm1 Domain vm1 started # ps -ef|grep qemu -device pci-bridge,chassis_nr=1,id=pci.1,bus=pci.0,addr=0xa -device pci-bridge,chassis_nr=1,id=pci.2,bus=pci.1,addr=0xa 2. check in guest guest]#lspci -v 00:0a.0 PCI bridge: Red Hat, Inc. QEMU PCI-PCI bridge (prog-if 00 [Normal decode]) Flags: 66MHz, fast devsel Memory at fea58000 (64-bit, non-prefetchable) [size=256] Bus: primary=00, secondary=01, subordinate=02, sec-latency=0 I/O behind bridge: 0000c000-0000cfff Memory behind bridge: fe600000-fe9fffff Prefetchable memory behind bridge: 00000000fe000000-00000000fe1fffff Capabilities: [4c] MSI: Enable- Count=1/1 Maskable+ 64bit+ Capabilities: [48] Slot ID: 0 slots, First+, chassis 01 Capabilities: [40] Hot-plug capable 01:0a.0 PCI bridge: Red Hat, Inc. QEMU PCI-PCI bridge (prog-if 00 [Normal decode]) Flags: 66MHz, fast devsel Memory at fe800000 (64-bit, non-prefetchable) [size=256] Bus: primary=01, secondary=02, subordinate=02, sec-latency=0 I/O behind bridge: 0000c000-0000cfff Memory behind bridge: fe600000-fe7fffff Prefetchable memory behind bridge: 00000000fe000000-00000000fe1fffff Capabilities: [4c] MSI: Enable- Count=1/1 Maskable+ 64bit+ Capabilities: [48] Slot ID: 0 slots, First+, chassis 01 Capabilities: [40] Hot-plug capable 3. Actual results: PCI bridges are usable if they have the same chassis Expected results: Forbid to use the same chassis for more than 1 pci bridge Additional info: