public inbox for pve-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: Dominik Csapak <d.csapak@proxmox.com>
To: Elias Huhsovitz <e.huhsovitz@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 16:05:56 +0200	[thread overview]
Message-ID: <1003d008-f949-4fbf-a8de-6df87376329c@proxmox.com> (raw)
In-Reply-To: <DLQYRO18N6UT.28NS9YNTKE4B3@proxmox.com>



On 9/28/26 2:55 PM, Elias Huhsovitz wrote:
> 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.

i tried that, but that didn't quite workout with the FromStr 
implementations.

The issue here is that a hostpciX device can be either placed
in a pci or pcie slot, depending on its own config.

but see my reply to patch 1

> 
>> +    ]),
>> +};
> 
> [snip]





  reply	other threads:[~2026-09-28 14:06 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
2026-09-28 14:05     ` Dominik Csapak [this message]
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=1003d008-f949-4fbf-a8de-6df87376329c@proxmox.com \
    --to=d.csapak@proxmox.com \
    --cc=e.huhsovitz@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
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal