From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) by lore.proxmox.com (Postfix) with ESMTPS id 73DF91FF146 for ; Tue, 23 Jun 2026 14:03:36 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id D31B832E82; Tue, 23 Jun 2026 14:03:33 +0200 (CEST) Message-ID: <74183b0f-b76a-4152-a433-253afdf40a56@proxmox.com> Date: Tue, 23 Jun 2026 14:02:58 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Beta Subject: Re: [BUG] PCIe passthrough devices invisible on q35 with non-sequential hostpci numbering (two related issues) To: Giray Pultar , pve-devel@lists.proxmox.com References: <11ce85d1-eb5d-48d1-a4ba-046424613f29@pultar.org> Content-Language: en-US From: Dominik Csapak In-Reply-To: <11ce85d1-eb5d-48d1-a4ba-046424613f29@pultar.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1782216168370 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.049 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [proxmox.com] Message-ID-Hash: 3OKWW5ZBD7POKCNYUUEI2DL35BZUKRV4 X-Message-ID-Hash: 3OKWW5ZBD7POKCNYUUEI2DL35BZUKRV4 X-MailFrom: d.csapak@proxmox.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.10 Precedence: list List-Id: Proxmox VE development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: Hi, first, bugs are usually tracked via our bugtracker (https://bugzilla.proxmox.com) so I encourage you to open bugs there, but see my answers to the two points below: On 6/23/26 12:33 PM, Giray Pultar wrote: > > Package: pve-manager > Version: 9.2.3 > pve-qemu-kvm: 11.0.0-4 > proxmox-kernel: 7.0.6-2-pve > Machine type: q35 > > ## Summary > > When PCI passthrough devices use non-sequential hostpci numbers (e.g., > hostpci0,1,2,3,7,9) with pcie=1 on a q35 machine type, the devices at > higher indices become completely invisible to the guest OS. This is caused > by two related issues in qemu-server and proxmox-ve. > > > ## Issue 1: qemu-server places PCIe root ports at invalid addresses > > ### Steps to Reproduce > > 1. Create a q35 VM with more than 4 PCIe passthrough devices > 2. Use non-sequential hostpci numbering, e.g.: >    hostpci0: mapping=devA,pcie=1 >    hostpci1: mapping=devB,pcie=1 >    hostpci2: mapping=devC,pcie=1 >    hostpci3: mapping=devD,pcie=1 >    hostpci7: mapping=devE,pcie=1 >    hostpci9: mapping=devF,pcie=1 > 3. Start the VM > 4. Observe that hostpci7 and hostpci9 are invisible in the guest > > ### Actual Behavior > > Only hostpci0-3 appear. The remaining devices get dynamically-created > PCIe root ports at addresses such as: > >   pcie-root-port,id=ich9-pcie-port-8,addr=10.3,bus=pcie.0,port=8,chassis=8 > > pcie-root-port,id=ich9-pcie-port-10,addr=10.5,bus=pcie.0,port=10,chassis=10 > > These map to PCI slot 0x10 (decimal 16), functions 3 and 5. No device > exists at function 0 of this slot. Per the PCI specification, function 0 > must be present before the OS will scan higher functions. The guest never > discovers these root ports, and the devices behind them are invisible. > > Guest dmesg confirms empty buses: >   pci_bus 0000:07: extended config space not accessible >   pci_bus 0000:08: extended config space not accessible > > ### Expected Behavior > > All PCIe passthrough devices should appear in the guest regardless of > the hostpciN index numbering. > > ### Suggested Fix > > qemu-server's PCI address allocation logic for dynamically-created PCIe > root ports should either: >   - Place each root port at its own slot with function 0, or >   - Create a placeholder function 0 when using multifunction, or >   - Avoid multifunction grouping for root ports without function 0 > I get why this is problematic and this needs to be fixed, probably has to be gated behind a new machine version, otherwise we could have issues with live migration/backup-restore/suspend resume (though most of these are probably irrelevant with pci passthrough enabled) Reworking the PCI address assignment is already on my todo (for different reasons though). I didn't have the time yet for that, but I should pick that up again in the near future. Please open an issue on our bugtracker for this so we can better track this and you get a notification if there is any development on that front. > > ## Issue 2: proxmox-ve does not keep hostpci numbering sequential > > ### Problem Description > > When a PCI passthrough device is removed from the middle of a sequence, > Proxmox VE does not renumber the remaining devices to fill the gap: > > Before removal of devC (hostpci2): >   hostpci0: mapping=devA >   hostpci1: mapping=devB >   hostpci2: mapping=devC >   hostpci3: mapping=devD >   hostpci4: mapping=devE >   hostpci5: mapping=devF > > After removal: >   hostpci0: mapping=devA >   hostpci1: mapping=devB >   hostpci3: mapping=devD >   hostpci4: mapping=devE >   hostpci5: mapping=devF > > The gap at hostpci2 persists. These gaps directly trigger Issue 1 above. > > ### Expected Behavior > > Proxmox VE should either: >   1. Automatically renumber hostpci devices sequentially (0,1,2,...) >      when a device is removed, or >   2. Provide a CLI/API command to compact/renumber PCI device indices, or >   3. At minimum, warn the user when non-sequential numbering is detected > > ### Suggested Solution > > Renumber hostpci entries automatically when a device is removed via > the GUI or `qm set --delete hostpciN`, preventing gaps from accumulating. I don't think this is a good idea. Each config entry (including numbered ones) should stand on their own. Since we have to 'statically' assign the addresses (for live-migration, etc) we can't renumber them automatically, otherwise the guest could get confused (since the layout inside would change) If we fix the issue1, this should not be a problem anymore and we don't have to do any renumbering here.. > > ## Workaround (for both issues) > > Manually renumber hostpci devices to be sequential (0,1,2,3,4,5) > instead of using non-sequential numbers. > > > Giray > > > thanks for the report best regards Dominik