microsoft / microsoft/openvmm

BaseChipsetBuilder should accept VmChipsetResult directly instead of piecemeal fields

Open
#3,463 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Rust
Stars
1.9k
Forks
238
Avg merge
1d 15h
Merged PRs (30d)
100

Description

Summary

VmManifestBuilder::build() returns a VmChipsetResult containing chipset (the manifest), chipset_devices, pci_chipset_devices, and capabilities. At every call site, that struct is immediately destructured and its fields are passed individually into BaseChipsetBuilder via separate builder calls:

// underhill_core/src/worker.rs (and openvmm_core/src/worker/dispatch.rs)
let VmChipsetResult {
    chipset,
    mut chipset_devices,
    pci_chipset_devices,
    capabilities,
} = chipset.build()?;

// ... later ...

BaseChipsetBuilder::new(foundation, devices)
    .with_expected_manifest(chipset)
    .with_device_handles(chipset_devices)
    .with_pci_device_handles(pci_chipset_devices)
    // ...
    .build(...)
    .await?;

This pattern appears in at least two places:

  • openhcl/underhill_core/src/worker.rs
  • openvmm/openvmm_core/src/worker/dispatch.rs

Proposed Change

1. BaseChipsetBuilder: accept VmChipsetResult directly

Add a with_vm_chipset_result(result: VmChipsetResult) method (or integrate it into BaseChipsetBuilder::new) so callers can pass the whole VmChipsetResult directly, eliminating the repetitive destructuring at each call site.

2. VmConfig in openvmm_core: consolidate chipset fields

VmConfig currently stores the VmChipsetResult fields split across separate fields:

  • chipset: BaseChipsetManifest
  • chipset_devices: Vec<ChipsetDeviceHandle>
  • pci_chipset_devices: Vec<LegacyPciChipsetDeviceHandle>
  • chipset_capabilities: VmChipsetCapabilities

These are effectively the same as VmChipsetResult. Replacing them with a single VmChipsetResult field would keep the two types in sync and reduce divergence risk.

Motivation

  • VmChipsetResult's fields were designed together and are produced together — splitting them apart at every consumer is accidental complexity.
  • If VmChipsetResult gains or loses fields in the future, each call site must be updated manually; a single with_vm_chipset_result call handles this automatically.
  • Reduces boilerplate at call sites.

Affected Files

  • vmm_core/vmotherboard/src/base_chipset.rs — add the new method
  • openhcl/underhill_core/src/worker.rs — update call site
  • openvmm/openvmm_core/src/worker/dispatch.rs — update call site and VmConfig
  • openvmm/openvmm_entry/src/lib.rs — update call site
  • petri/src/vm/openvmm/construct.rs — may need updating depending on how VmChipsetResult flows through

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with vmm_core/vmotherboard/src/base_chipset.rs and trace VmChipsetResult through the worker and dispatch call sites listed in the issue. Check the affected Rust crates, then update each consumer so the complete result is passed together and verify that openvmm_core::VmConfig no longer splits those fields.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
operating-systems
Issue type
Refactor
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
50/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.