vmm_core/vmotherboard: chipset bus resolution for pcie enumerators and downstream ports

[jackschefer-msft]

This change introduces vmotherboard support in OpenVMM for wiring PCIe topology components together. This PR builds on previous changes to introduce root complex and root port emulators, and in subsequent PRs will be used to wire endpoint devices up to their parent devices. For a view of how this fits together, see #1976

Specifially, this change:

• Introduces two vmotherboard::BusId types. which are separate because they have distinct wiring requirements.
  • The first such type represents a multi-port upstream device such as a root complex or in the future a switch. These devices represent an internal bus, with multiple downstream ports
  • The second such type represents each downstream port of the multi-port devices, at most one downstream device can be attached to each downstream port.
• Adds a bus resolver to the motherboard, with associated error handling types, to facilitate the motherboard connecting upstream and downstream devices based on port names
  • These are modeled off of the legacy PCI bus resolution architecture, though had to be separate. The legacy PCI bus infrastructure models a multi-device bus, where BDFs are statically defined at VM-start, whereas the PCIe bus infrastructure models both multi-port semantics for upstream devices and single-parent semantics for the PCIe links and resolution is done based on string identifiers not BDFs
  • When an enumerator is registered with the motherboard, the motherboard queries the downstream ports of the enumerator and tracks them internally for resolution
• Updates the VM worker to register PCIe root complexes with this new resolution architecture.

[Copilot]

Pull Request Overview

This PR introduces PCIe topology component wiring support in OpenVMM's vmotherboard. It adds infrastructure for connecting PCIe enumerators (root complexes, switches) with downstream ports and endpoint devices through a bus resolution system.

Key changes:

• Introduces two new PCIe bus ID types for enumerators and downstream ports
• Adds PCIe bus resolver with error handling similar to existing PCI infrastructure
• Updates VM worker to register PCIe root complexes with the new resolution architecture

Reviewed Changes

Copilot reviewed 10 out of 11 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
vmm_core/vmotherboard/src/lib.rs	Defines new bus ID types for PCIe enumerators and downstream ports
vmm_core/vmotherboard/src/chipset/mod.rs	Adds PCIe conflict error types and display formatting
vmm_core/vmotherboard/src/chipset/builder/mod.rs	Implements PCIe enumerator registration and device resolution logic
vmm_core/vmotherboard/src/chipset/builder/errors.rs	Adds PCIe conflict error to builder error enum
vmm_core/vmotherboard/src/chipset/backing/arc_mutex/services.rs	Adds PCIe device registration service
vmm_core/vmotherboard/src/chipset/backing/arc_mutex/pci.rs	Implements PCIe bus resolver and device registration traits
vmm_core/vmotherboard/src/chipset/backing/arc_mutex/device.rs	Adds PCIe port configuration to device builder
vmm_core/vmotherboard/src/base_chipset.rs	Implements PCIe root complex integration with device infrastructure
vmm_core/vmotherboard/Cargo.toml	Adds pcie dependency
openvmm/hvlite_core/src/worker/dispatch.rs	Registers PCIe root complexes with new bus resolution system

[smalis-msft]

If we have a need to add a bunch more buses maybe we should invest in deduplicating some of this code with some macros or higher-level generic shenanigans, but I don't think it's likely we're going to need more than this any time soon right?

[jackschefer-msft]

If we have a need to add a bunch more buses maybe we should invest in deduplicating some of this code with some macros or higher-level generic shenanigans, but I don't think it's likely we're going to need more than this any time soon right?

I don't think we'll need any more buses for PCIe stuff, and I agree adding these is pretty rare