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.
Bug 1349227 - Forbid to use the same chassisNr for more than 1 pci bridge
Summary: Forbid to use the same chassisNr for more than 1 pci bridge
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libvirt
Version: 7.3
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Laine Stump
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-06-23 02:43 UTC by Yang Yang
Modified: 2023-09-14 03:27 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-06-23 16:47:22 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Yang Yang 2016-06-23 02:43:05 UTC 
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:
Comment 2 Laine Stump 2016-06-23 16:47:22 UTC 
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
Comment 3 Yang Yang 2016-06-24 03:39:05 UTC 
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
Comment 4 Marcel Apfelbaum 2016-06-24 15:28:39 UTC 
(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
Comment 5 Red Hat Bugzilla 2023-09-14 03:27:11 UTC 
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days
Note You need to log in before you can comment on or make changes to this bug.