public inbox for pve-devel@lists.proxmox.com
 help / color / mirror / Atom feed
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




      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
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal