openvmm: Add PCIe bus selection for virtio vsock

[Anatol Belski (weltling)]

Extend VirtioBusCli with named PCIe ports and route selected devices through PcieDeviceConfig.

Apply shared bus selection to virtio fs and RNG. Reject one global PCIe port for multiple fs devices and document the accepted values.

Linux direct boot can use a native PCIe topology without legacy PCI interrupt routing. Virtio vsock could only select generic PCI or MMIO, which left no way to attach it to a named PCIe root port.

Extend --virtio-vsock-bus with pcie and pcie:PORT. Bare pcie selects root port vsock by default. The named form selects another root port.

[Copilot]

🟢 Approval recommended

The only noted gap is a non-blocking test-coverage nit.

Pull request overview

Adds pcie and pcie:PORT support for virtio-vsock bus selection.

Changes:

• Supports default and named PCIe root ports.
• Routes vsock devices through PCIe configuration.
• Documents the new syntax and adds parser tests.

File summaries

File	Summary
openvmm/openvmm_entry/src/lib.rs	Maps PCIe vsock selections into device configuration.
openvmm/openvmm_entry/src/cli_args.rs	Adds parsing and tests for PCIe bus forms.
Guide/src/reference/openvmm/management/cli.md	Documents the new option syntax.

Review details

Suppressed comments (1)

openvmm/openvmm_entry/src/lib.rs:1998

• The new behavior is covered only by parser assertions; no test exercises vm_config_from_command_line to verify that pcie/pcie:PORT emits a PcieDeviceConfig for the selected port (for either the Unix relay or Linux vhost backend). Add a focused configuration test so a regression cannot silently route vsock through the old bus path.

    let (virtio_vsock_bus, virtio_vsock_pcie_port) = match &opt.virtio_vsock_bus {
        None => (Some(VirtioBusCli::Auto), None),
        Some(VirtioVsockBusCli::Mmio) => (Some(VirtioBusCli::Mmio), None),
        Some(VirtioVsockBusCli::Pci) => (Some(VirtioBusCli::Pci), None),
        Some(VirtioVsockBusCli::Pcie(port)) => (None, Some(port)),

• Files reviewed: 3/3 changed files
• Comments generated: 0
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

🔵 Needs a closer look

Reject extra colons in named PCIe ports and add a parser regression test.

Review details

Suppressed comments (1)

openvmm/openvmm_entry/src/cli_args.rs:1605

• This split_once accepts values such as pcie:port:extra and stores port:extra as the port name. --pcie-root-port rejects names containing a second colon (via PortNamePair), so this can never resolve and only fails later as a missing PCIe port; reject an additional : here (and add a parser regression test).

    } else if let Some((bus, port)) = value.split_once(':')
        && bus.eq_ignore_ascii_case("pcie")
        && !port.is_empty()
    {

• Files reviewed: 3/3 changed files
• Comments generated: 0 new
• Review effort level: Lite

[Copilot]

🔵 Needs a closer look

Add coverage for PCIe port mapping and address the documentation line-width nit.

Review details

Suppressed comments (2)

Guide/src/reference/openvmm/management/cli.md:242

• The new Guide line exceeds the repository's 80-character documentation width (.github/instructions/guide-docs.instructions.md:16), which makes this option harder to scan in the CLI reference. Wrap the description before created by.

* `--virtio-vsock-bus <mmio|pci|pcie[:PORT]>`: Select the bus for a virtio-vsock device

openvmm/openvmm_entry/src/lib.rs:1998

• The tests added here cover only parsing VirtioVsockBusCli; the new mapping that places the resource in pcie_devices is not exercised. Add a config-level or CLI integration test that requests pcie:<port> and asserts the resulting PcieDeviceConfig uses that port (including the vhost backend where supported), so a regression cannot silently return the device to the legacy virtio bus.

    let (virtio_vsock_bus, virtio_vsock_pcie_port) = match &opt.virtio_vsock_bus {
        None => (Some(VirtioBusCli::Auto), None),
        Some(VirtioVsockBusCli::Mmio) => (Some(VirtioBusCli::Mmio), None),
        Some(VirtioVsockBusCli::Pci) => (Some(VirtioBusCli::Pci), None),
        Some(VirtioVsockBusCli::Pcie(port)) => (None, Some(port)),

• Files reviewed: 3/3 changed files
• Comments generated: 0 new
• Review effort level: Lite

[Copilot]

🟢 Approval recommended

The only finding is a minor platform-specific import lint nit and no approval-blocking issues remain.

Review details

• Files reviewed: 3/3 changed files
• Comments generated: 1
• Review effort level: Lite

[Copilot]

🟢 Approval recommended

No unresolved issues were identified in the reviewed changes.

Review details

• Files reviewed: 3/3 changed files
• Comments generated: 0 new
• Review effort level: Lite

[github-actions]

3 Petri tests failed (1 unstable)

[Copilot]

🟡 Changes recommended

Document virtio-fs-shmem support and the shared pcie:PORT one-device restriction.

Get a fresh assessment by requesting another Copilot review.

Review details

Suppressed comments (1)

Guide/src/reference/openvmm/management/cli.md:238

• --virtio-fs-bus is also applied to --virtio-fs-shmem in vm_config_from_command_line, but this description only documents the per-device pcie_port override for --virtio-fs. Mention --virtio-fs-shmem here as well so users of the shared-memory form know that the same override is supported.

  `auto`. A `pcie_port` prefix on `--virtio-fs` overrides this option.

• Files reviewed: 3/3 changed files
• Comments generated: 1
• Review effort level: Lite

[github-actions]

3 Petri tests failed (1 unstable)

[Copilot]

🔵 Needs a closer look

Reject duplicate PCIe port assignments across all routed devices and add focused fs/RNG routing tests.

Review details

Suppressed comments (2)

openvmm/openvmm_entry/src/lib.rs:1818

• PcieDeviceConfig attaches only one endpoint per named PCIe port, so a second registration is rejected as an occupied port. This branch appends without checking existing pcie_devices; for example, --virtio-fs-bus pcie:foo together with --virtio-rng --virtio-rng-bus pcie:foo (or an explicit pcie_port=foo) produces two devices on foo, while the precheck below only counts unprefixed filesystem devices. Track effective port names for all PCIe-routed devices and reject duplicates before building the config.

            VirtioBusCli::Pcie(port_name) => pcie_devices.push(PcieDeviceConfig {
                port_name,
                resource: VirtioPciDeviceHandle(resource).into_resource(),
            }),

openvmm/openvmm_entry/src/lib.rs:1880

• The new PCIe bus path is exercised only for vsock; the fs and RNG call sites are not covered by a config-building test. A regression that accidentally routes either --virtio-fs-bus pcie:PORT or --virtio-rng-bus pcie:PORT through the legacy virtio list would therefore pass the current tests. Add a focused test (or table-driven case) that asserts these options produce PcieDeviceConfig entries with the selected port.

            add_virtio_device(opt.virtio_fs_bus.clone(), resource, &mut pcie_devices);

• Files reviewed: 3/3 changed files
• Comments generated: 0 new
• Review effort level: Lite

[Copilot]

🟢 Approval recommended

No unresolved review issues were identified.

Review details

• Files reviewed: 3/3 changed files
• Comments generated: 0 new
• Review effort level: Lite

[github-actions]

2 Petri tests failed (1 unstable)

[Copilot]

🟢 Approval recommended

No unresolved issues were identified in the reviewed changes.

Review details

• Files reviewed: 3/3 changed files
• Comments generated: 0 new
• Review effort level: Lite

[github-actions]

1 Petri tests failed (1 unstable)

[Copilot]

Copilot review overview

🟢 Approval recommended

No unresolved blocking issues were identified.

Review effort: Lite
Findings: None

[github-actions]

3 Petri tests failed (0 unstable)

[John Starks (jstarks)]

I don't love the CLI options for this stuff. This doesn't compose well and we have too many options. But this seems like a reasonable extension to the mess we have right now.

[Chris Oo (chris-oo)]

+1 to johns feedback but i think it's fine for now.

[Anatol Belski (weltling)]

Thanks for the reviews! I was initially only thinking about exposing the vsock device over PCIe so it can be discovered more easily during direct kernel boot. However, a discussion with Daman showed there are others like virtio-rng that would benefit. Adding PCIe selection to them would bring a little more unity to the existing options, at least as long as they stay.

And yep, I've also explicitly avoided targeting any new console options for exactly the same reason mentioned in the review :)