From: "Elias Huhsovitz" <e.huhsovitz@proxmox.com>
To: "Dominik Csapak" <d.csapak@proxmox.com>, <pve-devel@lists.proxmox.com>
Subject: Re: [PATCH pve-qemu-server-rs 3/9] pci: layout: add v2 PCI and PCIe layouts
Date: Mon, 28 Sep 2026 14:55:21 +0200 [thread overview]
Message-ID: <DLQYRO18N6UT.28NS9YNTKE4B3@proxmox.com> (raw)
In-Reply-To: <20260922105550.2084078-4-d.csapak@proxmox.com>
Since the `v2` name is just a development placeholder, I will start with
some suggestions:
* `grouped` - describing the property of the new layout.
* `per_device` | `per_kind` - since each device gets its own bridges.
* `default` - since it is the new default (might age badly if a new
default is introduced).
On Tue Sep 22, 2026 at 12:55 PM CEST, Dominik Csapak wrote:
> The legacy layout grew over many releases and it shows: devices of one
> kind are spread over several buses, the bus a device lands on depends on
> how many devices of other kinds exist, and the remaining free slots are
> scattered. That makes it hard to raise any of the per-kind limits
> without further scattering the types over the available addresses.
>
> Add a second set of layouts that gives every device kind its own set of
> bridges instead. A device's address then only depends on its own index,
> so raising a limit adds bridges at the end rather than shifting anything
> that exists, and the built-in devices move to a bridge of their own to
> keep the root bus free.
>
> These are not wired up to the entry points yet: they are meant for new
> guests only, and the machine property selecting them still has to be
> added on the qemu-server side.
>
> Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
> ---
> pve-qemu-server-pci/src/layout/mod.rs | 2 +
> pve-qemu-server-pci/src/layout/v2.rs | 344 ++++++++++++++++++++++++++
> pve-qemu-server-pci/src/types/mod.rs | 3 +
> 3 files changed, 349 insertions(+)
> create mode 100644 pve-qemu-server-pci/src/layout/v2.rs
>
> diff --git a/pve-qemu-server-pci/src/layout/mod.rs b/pve-qemu-server-pci/src/layout/mod.rs
> index c81d730..0b72abd 100644
> --- a/pve-qemu-server-pci/src/layout/mod.rs
> +++ b/pve-qemu-server-pci/src/layout/mod.rs
> @@ -13,6 +13,8 @@ macro_rules! single_device {
>
> pub(crate) mod legacy;
>
> +pub mod v2;
> +
> /// Constructs a correctly sized list of bridge slots, starting at address 0x01
> /// because 0x00 is always taken by the bridge itself.
> ///
> diff --git a/pve-qemu-server-pci/src/layout/v2.rs b/pve-qemu-server-pci/src/layout/v2.rs
> new file mode 100644
> index 0000000..9525492
> --- /dev/null
> +++ b/pve-qemu-server-pci/src/layout/v2.rs
> @@ -0,0 +1,344 @@
> +use crate::constants::{
> + BRIDGE_SLOT_NUM, MAX_HOSTPCI_DEVICES, MAX_NET_DEVICES, MAX_SCSI_DEVICES,
> + MAX_VIRTIO_BLK_DEVICES, MAX_VIRTIOFS_DEVICES,
> +};
> +use crate::layout::bridge_slots;
> +use crate::{Bus, Device, DeviceLayout, Function, PveBridge, Slot};
> +
> +/// The guest's built-in devices, which all live on a bridge of their own so
> +/// that the root bus stays free for the per-kind bridges.
> +///
> +/// NOTE: only append here, don't reorder. The order implies the address, which
> +/// has to stay stable.
> +const SYS_BRIDGE_SLOTS: [Slot; BRIDGE_SLOT_NUM] = bridge_slots(&[
nit: name: I would prefer `BUILTIN_BRIDGE_SLOTS` or
`BUILTIN_DEVICE_SLOTS`. Since devies are usually in slots, we can also
just shorten it to `BUILTIN_DEVICES`.
> + single_device!(Ahci),
> + single_device!(Balloon),
> + single_device!(XhciController(0)),
> + single_device!(GuestAgent),
> + single_device!(SpiceSerial),
> + single_device!(Rng),
> + single_device!(Audio),
> + single_device!(Watchdog),
> + single_device!(Ivshmem),
> +]);
> +
> +/// The layout for guests with a PCI root bus.
> +pub static PCI_LAYOUT: DeviceLayout = DeviceLayout {
> + pcie: false,
> + root: bridge_slots(&[
> + Slot::Reserved,
> + Slot::Multi(&[
> + Function::Device(Device::Vga(0)),
> + Function::Device(Device::Vga(1)),
> + Function::Device(Device::Vga(2)),
> + Function::Device(Device::Vga(3)),
> + Function::Unused,
> + Function::Unused,
> + Function::Unused,
> + Function::Unused,
> + ]),
> + Slot::Single(Function::Device(Device::Viommu)),
> + Slot::Single(Function::FixedBridge(Bus::Sys(0), &SYS_BRIDGE_SLOTS)),
> + Slot::DynamicBridge {
> + kind: PveBridge::VirtioFs,
> + max: MAX_VIRTIOFS_DEVICES,
> + },
> + Slot::DynamicBridge {
> + kind: PveBridge::Net,
> + max: MAX_NET_DEVICES,
> + },
> + Slot::Unused,
> + Slot::DynamicBridge {
> + kind: PveBridge::Scsi,
> + max: MAX_SCSI_DEVICES,
> + },
> + Slot::Unused,
> + Slot::DynamicBridge {
> + kind: PveBridge::VirtioBlk,
> + max: MAX_VIRTIO_BLK_DEVICES,
> + },
> + Slot::Unused,
> + Slot::Unused,
> + Slot::Unused,
> + Slot::DynamicBridge {
> + kind: PveBridge::Hostpci,
> + max: MAX_HOSTPCI_DEVICES,
> + },
> + ]),
> +};
> +
> +/// The layout for guests with a PCIe root bus.
> +///
> +/// Identical to [`PCI_LAYOUT`] except for the root bus type and the root ports
> +/// for passed through PCIe devices, which a PCI machine cannot have.
> +pub static PCIE_LAYOUT: DeviceLayout = DeviceLayout {
> + pcie: true,
> + root: bridge_slots(&[
> + Slot::Reserved,
> + Slot::Multi(&[
> + Function::Device(Device::Vga(0)),
> + Function::Device(Device::Vga(1)),
> + Function::Device(Device::Vga(2)),
> + Function::Device(Device::Vga(3)),
> + Function::Unused,
> + Function::Unused,
> + Function::Unused,
> + Function::Unused,
> + ]),
> + Slot::Single(Function::Device(Device::Viommu)),
> + Slot::Single(Function::FixedBridge(Bus::Sys(0), &SYS_BRIDGE_SLOTS)),
> + Slot::DynamicBridge {
> + kind: PveBridge::VirtioFs,
> + max: MAX_VIRTIOFS_DEVICES,
> + },
> + Slot::DynamicBridge {
> + kind: PveBridge::Net,
> + max: MAX_NET_DEVICES,
> + },
> + Slot::Unused,
> + Slot::DynamicBridge {
> + kind: PveBridge::Scsi,
> + max: MAX_SCSI_DEVICES,
> + },
> + Slot::Unused,
> + Slot::DynamicBridge {
> + kind: PveBridge::VirtioBlk,
> + max: MAX_VIRTIO_BLK_DEVICES,
> + },
> + Slot::Unused,
> + Slot::Unused,
> + Slot::Unused,
> + Slot::DynamicBridge {
> + kind: PveBridge::Hostpci,
> + max: MAX_HOSTPCI_DEVICES,
> + },
> + Slot::Unused,
> + Slot::Multi(&[
> + Function::RootPort(0, Device::Hostpcie(0)),
> + Function::RootPort(1, Device::Hostpcie(1)),
> + Function::RootPort(2, Device::Hostpcie(2)),
> + Function::RootPort(3, Device::Hostpcie(3)),
> + Function::RootPort(4, Device::Hostpcie(4)),
> + Function::RootPort(5, Device::Hostpcie(5)),
> + Function::RootPort(6, Device::Hostpcie(6)),
> + Function::RootPort(7, Device::Hostpcie(7)),
> + ]),
> + Slot::Multi(&[
> + Function::RootPort(8, Device::Hostpcie(8)),
> + Function::RootPort(9, Device::Hostpcie(9)),
> + Function::RootPort(10, Device::Hostpcie(10)),
> + Function::RootPort(11, Device::Hostpcie(11)),
> + Function::RootPort(12, Device::Hostpcie(12)),
> + Function::RootPort(13, Device::Hostpcie(13)),
> + Function::RootPort(14, Device::Hostpcie(14)),
> + Function::RootPort(15, Device::Hostpcie(15)),
> + ]),
We have 16 device slots via the dynmic bridge and 16 devices slots via
root ports = 32 passthrough slots. But the config schema only allows
for 16 total `hostpciN` devices.
IMO we need to add `hostpcieN` as a config key in perl and add a new
constant.
pub const MAX_HOSTPCIE_DEVICES: u8 = 16;
OR what about removing the explicit `Device::Hostpcie` and folding in the
placement into the enum, like this:
pub enum Device {
Hostpci(u8, HostpciPlacement),
}
pub enum HostpciPlacement {
Bridge,
RootPort,
}
Since, if I understand this correctly, we primarily care about the placement.
> + ]),
> +};
[snip]
next prev parent reply other threads:[~2026-09-28 12:55 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-22 10:55 [RFC proxmox-perl-rs/qemu-server/qemu-server-rs 0/9] pci-handling rewrite (part 1) Dominik Csapak
2026-09-22 10:55 ` [PATCH pve-qemu-server-rs 1/9] add pve-qemu-server-pci crate for guest PCI address generation Dominik Csapak
2026-09-28 12:53 ` Elias Huhsovitz
2026-09-28 14:00 ` Dominik Csapak
2026-09-22 10:55 ` [PATCH pve-qemu-server-rs 2/9] pci: add machine abstraction and PCI bridge generation Dominik Csapak
2026-09-28 12:55 ` Elias Huhsovitz
2026-09-28 14:04 ` Dominik Csapak
2026-09-22 10:55 ` [PATCH pve-qemu-server-rs 3/9] pci: layout: add v2 PCI and PCIe layouts Dominik Csapak
2026-09-28 12:55 ` Elias Huhsovitz [this message]
2026-09-28 14:05 ` Dominik Csapak
2026-09-22 10:55 ` [PATCH pve-qemu-server-rs 4/9] fixup! add pve-qemu-server-pci crate for guest PCI address generation Dominik Csapak
2026-09-22 10:55 ` [PATCH proxmox-perl-rs 5/9] pve: add bindings for `pve-qemu-server-pci` crate Dominik Csapak
2026-09-28 12:56 ` Elias Huhsovitz
2026-09-28 14:06 ` Dominik Csapak
2026-09-22 10:55 ` [PATCH proxmox-perl-rs 6/9] pve: pci bindings: add bindings for the `Machine` struct Dominik Csapak
2026-09-22 10:55 ` [PATCH qemu-server 7/9] pci: use PVE::RS::PCI bindings Dominik Csapak
2026-09-22 10:55 ` [PATCH qemu-server 8/9] helpers: factor out the version parts parsing Dominik Csapak
2026-09-22 10:55 ` [PATCH qemu-server 9/9] pci: bridges: use the rust `Machine` struct to pass parameters Dominik Csapak
2026-09-22 11:06 ` [RFC proxmox-perl-rs/qemu-server/qemu-server-rs 0/9] pci-handling rewrite (part 1) Dominik Csapak
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=DLQYRO18N6UT.28NS9YNTKE4B3@proxmox.com \
--to=e.huhsovitz@proxmox.com \
--cc=d.csapak@proxmox.com \
--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