[BUG] PCIe passthrough devices invisible on q35 with non-sequential hostpci numbering (two related issues)

[BUG] PCIe passthrough devices invisible on q35 with non-sequential hostpci numbering (two related issues)

[Giray Pultar]

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


## 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.

## Workaround (for both issues)

Manually renumber hostpci devices to be sequential (0,1,2,3,4,5)
instead of using non-sequential numbers.


Giray

Re: [BUG] PCIe passthrough devices invisible on q35 with non-sequential hostpci numbering (two related issues)

[Dominik Csapak]

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