microsoft / microsoft/openvmm

ci: add virt stack etl traces to petri runs

Open
#1,689 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

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

Description

Petri-based Test Diagnostics: Technical Summary & Next Steps

This summary captures the approach, technical feedback, and recommendations from PR #1656, which explored adding Windows WPR trace collection to petri-based tests in OpenVMM.


Approach

  • Proposed automatic WPR trace collection during petri-based test runs.
  • For each test, a WPR trace session was started/stopped, saving output to the test directory.
  • Used an embedded WPR profile targeting OpenVMM/OpenHCL/Hyper-V.

Limitations & Feedback

  • Process Isolation: Each test case ("trial" in libmimic) runs in its own process, with process spawning managed externally by cargo-nextest. This makes coordinated trace management challenging—there is no OpenVMM-specific code for process control.
  • Test Runner Integration: Robust trace management should be handled by the test runner (flowey), which ought to start/stop trace sessions per test for reliability and isolation.
  • Trace File Handling: Output management and clean-up introduce complexity, especially with parallel test execution.
  • Profile Customization: The default WPR profile may not fit all scenarios; customization per test or suite is desirable.
  • Platform Scope: Current solution is Windows-only.

Recommendations

  • Delegate trace session lifecycle to the test runner (flowey).
  • Make trace collection opt-in or configurable at the test/suite level.
  • Support custom WPR profiles for targeted diagnostics.
  • Consider platform-agnostic approaches if future needs arise.

This summary is intended for rapid onboarding and planning of diagnostic improvements for petri-based tests.

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 by reviewing PR #1656 and the trace-collection limitations described here, then read how flowey runs petri-based tests alongside libmimic and cargo-nextest. Define the trace-session lifecycle, configuration, profile handling, and output cleanup needed for isolated and parallel trials; done means the agreed flowey-based approach is implemented and validated for the supported Windows scenarios.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
ci-cd, testing-qa, tooling
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.