From: Dominik Csapak <d.csapak@proxmox.com>
To: Giray Pultar <giray@pultar.org>, pve-devel@lists.proxmox.com
Subject: Re: [BUG] PCIe passthrough devices invisible on q35 with non-sequential hostpci numbering (two related issues)
Date: Tue, 23 Jun 2026 14:02:58 +0200 [thread overview]
Message-ID: <74183b0f-b76a-4152-a433-253afdf40a56@proxmox.com> (raw)
In-Reply-To: <11ce85d1-eb5d-48d1-a4ba-046424613f29@pultar.org>
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
prev parent reply other threads:[~2026-06-23 12:03 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-22 14:38 [BUG] PCIe passthrough devices invisible on q35 with non-sequential hostpci numbering (two related issues) Giray Pultar
2026-06-23 12:02 ` Dominik Csapak [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=74183b0f-b76a-4152-a433-253afdf40a56@proxmox.com \
--to=d.csapak@proxmox.com \
--cc=giray@pultar.org \
--cc=pve-devel@lists.proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox