Bug 1349227
| Summary: | Forbid to use the same chassisNr for more than 1 pci bridge | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Yang Yang <yanyang> |
| Component: | libvirt | Assignee: | Laine Stump <laine> |
| Status: | CLOSED NOTABUG | QA Contact: | Virtualization Bugs <virt-bugs> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 7.3 | CC: | alex.williamson, dyuan, marcel, mst, mzhan, rbalakri |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2016-06-23 16:47:22 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: | |||
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 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 (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 The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days |
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: