Skip to content

nvx-rs: boot templates with an adapter's kernel tuning parameters - #1422

Merged
Pedro Henrique Penna (ppenna) merged 5 commits into
devfrom
agents/issue-995-kernel-tuning
Nov 9, 2026
Merged

nvx-rs: boot templates with an adapter's kernel tuning parameters#1422
Pedro Henrique Penna (ppenna) merged 5 commits into
devfrom
agents/issue-995-kernel-tuning

Conversation

@ppenna

@ppenna Pedro Henrique Penna (ppenna) commented Nov 9, 2026

Copy link
Copy Markdown
Contributor

Fixes #995

What and why

A template's kernel booted with NVX's own command line alone, nvx_sandbox=1
and, for a template whose processors are not all online at boot, maxcpus=.
OpenVMM checks a platform snapshot's manifest when it publishes a capture and
again at every restore, and refused every other token of its command line as
"tenant or unsupported configuration". So an adapter whose cold sandboxes boot
with kernel tuning parameters, such as mitigations=off, could not give them to
its templates, and its clones ran another kernel configuration than its cold
sandboxes: Linux applies mitigations= once, as it boots, so a clone has no
other way to get it.

  • OpenVMM ([DO NOT REVIEW] openvmm_helpers: admit kernel tuning on platform command lines openvmm#5001, b4028c1aa775d8aafba1a170857acc032c7c86a1,
    one commit on feature/microvm/dev f41a1ecfc): a platform snapshot's
    command line admits a closed set of guest kernel tuning parameters, at
    publication and at every restore, each parameter at most once:
    mitigations=off, mitigations=auto, and mitigations=auto,nosmt;
    no_timer_check; and quiet, and loglevel=0 to loglevel=7. Every other
    token stays refused, the time ABI's clock parameters included. The Guide's
    --snapshot-tier entry lists what a platform capture's command line may hold.
  • Pin (openvmm: pin kernel tuning on platform command lines): moves the
    gitlink, copies the new lines of OpenVMM's allowlist, with the constant of the
    tuning parameters, into nvx-rs/tests/vectors/openvmm/, records the commit in
    the vectors' README, and updates nvx-rs's allowlist test, which took quiet
    for a refused token. The commit before it makes the runtime adapter's template
    tests take nokaslr for that token instead, since the guest agent compiles
    the same excerpt, so that the gitlink commit holds only the gitlink and
    coordinated nvx-rs/ changes, as openvmm_pin.py check-branch --topic
    requires.
  • nvx-rs: KERNEL_TUNING_PARAMETERS; CaptureClass::kernel_tuning, which
    CaptureClass::check refuses unless each is in the set and each parameter
    appears once, before any VM boots; TemplatePlan::with_kernel_tuning, which
    renders them after the plan's own tokens, in their order; a Store's captures
    boot with their class's; TemplateKey::new refuses a capture whose command
    line holds other tuning than its class's. The class's canonical encoding holds
    the parameters last under CaptureClass::VERSION 2, with conformance vectors
    in nvx-rs/tests/vectors/capture-class-v2.txt; the key's encoding is
    unchanged, since the key holds the command line. NVX's fake OpenVMM accepts
    the parameters after a capture's own tokens, as OpenVMM does.
  • Runtime adapter: create and refresh take --kernel-tuning PARAMETER,
    once per parameter, in order. Its guest agent's check of a template's command
    line, which compiles the excerpt, admits the parameters; its documentation and
    tests now say so.
  • Roadmap (doc: map the kernel tuning on platform command lines in the OpenVMM roadmap): maps the pin at position 235, after position 234,
    f41a1ecfc, the head of feature/microvm/dev; the pin is 104 commits past
    the mapped tip, and positions 132-235 stay unassigned.

Snapshot formats: OpenVMM's manifest is unchanged, so every existing snapshot
stays restorable. The class encoding's new version changes every class's
identity, so Store::create_template finds no generation that a class of
version 1 captured, and captures one again; those generations still serve the
clones that select them by their keys, which are unchanged.

Design decisions:

  • The class holds the parameters as a Vec<String> in their order, which
    CaptureClass::check checks, as the issue proposes, rather than a type that
    is valid by construction. The order is part of the class, since the kernel
    applies the last of quiet and loglevel=.
  • TemplateKey::new also checks the manifest's tuning against the class's, as
    it checks the rest of the machine that the class requested, so a capture that
    did not boot with them makes no key of its class.
  • TemplatePlan::with_kernel_tuning is a builder method, which leaves
    TemplatePlan::new's signature as it was.
  • The class vectors of version 1 left template-key-v1.txt: nothing encodes or
    decodes a class of version 1 any more, and the version 2 vectors encode the
    same classes, and one with tuning.
  • The runtime adapter leaves the check of its --kernel-tuning values to NVX's
    class, which refuses them before the store is created.
  • The management RPC needs no change: its captures take the kernel command line
    as the command line's do.

Commits:

  1. runtime-adapter: take nokaslr for a token outside the platform allowlist
    (preparation for the pin, valid before and after it).
  2. openvmm: pin kernel tuning on platform command lines.
  3. nvx-rs: boot templates with their class's kernel tuning parameters.
  4. runtime-adapter: capture templates with kernel tuning parameters.
  5. doc: map the kernel tuning on platform command lines in the OpenVMM roadmap.

Landing order: land microsoft/openvmm#5001 first, by fast-forwarding
feature/microvm/dev to b4028c1aa775d8aafba1a170857acc032c7c86a1 exactly
(OpenVMM's merge button squashes and would leave the pin off the branch), then
this pull request. Its only prerequisite, microsoft/openvmm#4997 at
f41a1ecfc, is on feature/microvm/dev, and #1420 pinned it on dev.

Validation

The tree validated below is the branch's at 6bc5cbc34, which differs from this
head only in doc/openvmm-upstream-roadmap.md: #1420's roadmap commit, onto
whose merge the branch was rebased, and this branch's roadmap commit.

Local (Windows):

  • python scripts\local_gates.py --base origin/dev --only test-changes markdown-links test-layout openvmm-vectors openvmm-cpu-profiles nvx-rs-format nvx-rs-lint nvx-rs-test nvx-rs-bundling nvx-rs-doc nvx-rs-msrv nvx-rs-adapter-protocol nvx-rs-adapter-host --run --keep-going:
    all 13 passed; at this head, test-changes, markdown-links, and
    test-layout passed again.
  • nvx-cli, before the rebase onto openvmm: refuse an unknown paired-scratch restore mode #1418-openvmm: don't publish a snapshot over an empty directory #1420, at the same change: 2188 tests,
    of which only the 3 subtests of
    test_host_loopback_allow_script_checks_publication_and_traffic failed, each
    timing out after 10 s in Git for Windows' sh, which this machine's
    host-loopback script tests always do (they pass in CI and on Linux); its other
    steps passed. The change touches no script, so its rerun is left to CI.
  • python scripts\openvmm_pin.py check-branch --topic --target origin/dev,
    check-roadmap --worktree, python scripts\check_markdown_links.py,
    python scripts\rebase_check.py verify, and python scripts\nvx.py verify:
    passed.
  • OpenVMM at the pin, openvmm_helpers: cargo check,
    cargo clippy --all-targets -- -D warnings, cargo doc --no-deps with
    -D warnings, cargo nextest run --profile agent (126 passed), and
    cargo xtask fmt --fix (clean) on Windows; the same clippy, doc, and nextest
    (132 passed) on Linux. With the production change reverted, both new OpenVMM
    tests fail on Windows and Linux; with the new nvx-rs logic neutralized, the
    seven nvx-rs tests of the class check, encoding, plan, key check, and capture
    fail.

Linux (nvx-kvm-test): the check-nvx-rs steps passed: scripts/public_api.py,
cargo fmt --all --check, clippy with all features, with testing alone, and
with cli, cargo test with all features and by default, cargo doc, the
macOS check, the 1.89 check, the ignored openvmm_vectors and
openvmm_cpu_profiles tests, and the runtime adapter's fmt, guest clippy, test,
and doc for x86_64-unknown-linux-musl, host clippy, test, and doc, and 1.89
checks.

Remote runs, with the runtime adapter's new tests
vm_clone a_template_s_clones_run_with_its_kernel_tuning_parameters (capture a
template with mitigations=off, start a clone, and compare its /proc/cmdline)
and vm_template kernel_tuning_that_no_capture_takes_is_refused_before_the_store:

Profile Backend Host type Before (release v0.1.0-dev.8ebadbd3dae0, OpenVMM 98e5b3ca5) After (OpenVMM b4028c1aa built from the pin)
nvx-kvm-test kvm virtual-machine vm_clone fails: OpenVMM refuses the capture, "platform snapshot command line contains tenant or unsupported configuration" both pass; nvx.py test-runtime-adapter --backend kvm: the 161 scenarios of 11 targets passed; nvx.py test-microvm --backend kvm --scenario snapshot-tiers --scenario platform-restore-processors --scenario platform-aggregate-export --processors 1 2: passed
nvx-mshv-test mshv virtual-machine the same refusal both pass; test-runtime-adapter --backend mshv: the 161 scenarios passed
nvx-whp-test whp virtual-machine the same refusal both pass; test-runtime-adapter --backend whp: the 161 scenarios passed

The before runs used the change's first revision, whose OpenVMM commit
8efe38c7f has the same patch as b4028c1aa (git range-diff reports them
equal); the OpenVMM allowlist that refused the capture is unchanged between
98e5b3ca5 and f41a1ecfc.

Left to CI: the nvx-cli suites, the microVM scenarios on every backend, the
OpenVMM suites and OpenVMM's own CI of the pin (microsoft/openvmm#5001's run is
in progress), guest determinism, and the benchmarks.

Changes to existing tests (tests-modified), as
python scripts/check_test_changes.py --base origin/dev lists them (17):

  • openvmms_platform_allowlist_admits_its_tokens_and_refuses_tenant_data
    (nvx-rs), the_platform_tier_s_allowlist_is_openvmm_s,
    the_platform_tier_s_allowlist_takes_tokens_as_openvmm_splits_them, and
    template_mode_refuses_a_token_outside_the_allowlist (runtime adapter): they
    took quiet for a token outside OpenVMM's platform allowlist, which now
    admits it. They take nokaslr instead, admit the tuning parameters, and
    refuse other values and spellings of them.
  • platform_command_line_token_is_invariant.rs (test data): the excerpt of
    OpenVMM's allowlist, copied unchanged from the pinned revision, as
    openvmm_vectors requires.
  • each_part_of_the_key_changes_it: its change of the manifest's command line
    adds quiet, which is now a tuning parameter, so its class requests it too,
    or TemplateKey::new's new check would refuse the capture.
  • the_conformance_vectors_decode_and_encode, KEY_VECTORS (was VECTORS),
    vectors, vector_class, and template-key-v1.txt: the class vectors of
    version 1 moved to capture-class-v2.txt under the new class encoding; the
    key vectors are unchanged.
  • The class helpers of host::template::tests and nvx-rs's
    template_capture, and the runtime adapter's template_capture template
    helper: they name no tuning, for the new field.
  • The fake OpenVMM's CAPTURE_COMMAND_LINE and parse: the fake accepts the
    tuning parameters after a capture's own tokens, as OpenVMM does.
  • tests/runtime-adapter/scenarios.txt: names the three new runtime adapter
    tests.

@ppenna
runtime-adapter: take nokaslr for a token outside the platform allowlist
d3f6885 
The runtime adapter's template tests took `quiet` for a kernel
parameter that the platform tier's allowlist refuses. The next pin of
OpenVMM admits `quiet` on a platform snapshot's command line, with the
other kernel tuning parameters of #995, and so does the guest agent,
which checks a template's command line with the excerpt of OpenVMM's
allowlist.

the_platform_tier_s_allowlist_is_openvmm_s,
the_platform_tier_s_allowlist_takes_tokens_as_openvmm_splits_them, and
template_mode_refuses_a_token_outside_the_allowlist take `nokaslr`
instead, which the allowlist refuses before and after that pin, and
check the same refusals.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
@ppenna
openvmm: pin kernel tuning on platform command lines
5e83848 
Pin microsoft/openvmm#5001's head,
b4028c1aa775d8aafba1a170857acc032c7c86a1, "openvmm_helpers: admit
kernel tuning on platform command lines", one commit on
feature/microvm/dev f41a1ecfc. Its platform snapshots admit a
closed set of guest kernel tuning parameters on their kernel command
lines, at publication and at every restore, each parameter at most
once: `mitigations=off`, `mitigations=auto`, and
`mitigations=auto,nosmt`; `no_timer_check`; and `quiet`, and
`loglevel=0` to `loglevel=7` (#995). It refuses every other token, as
before.

The excerpt of OpenVMM's platform allowlist that nvx-rs's template
tests and the runtime adapter compile,
nvx-rs/tests/vectors/openvmm/platform_command_line_token_is_invariant.rs,
takes the function's new lines unchanged, with the constant of the
tuning parameters before it, and the vectors' README records the
commit. The guest agent of a runtime adapter's template, which checks
its kernel command line with the excerpt, so admits the tuning
parameters too.

nvx-rs's
openvmms_platform_allowlist_admits_its_tokens_and_refuses_tenant_data
took `quiet` for a token outside the allowlist, which the new excerpt
admits. It now admits the tuning parameters, and refuses other values
and spellings of them, such as `mitigations=on`, `loglevel=8`, and
`no-timer-check`, and other parameters, such as `nokaslr`.

`cargo test --test openvmm_vectors -- --ignored` and
`--test openvmm_cpu_profiles -- --ignored` pass at this pin.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
@ppenna
nvx-rs: boot templates with their class's kernel tuning parameters
7a937ff 
A template's kernel booted with NVX's own command line alone,
`nvx_sandbox=1` and, for a template whose processors are not all
online at boot, `maxcpus=`. An adapter whose cold sandboxes boot with
kernel tuning parameters, such as `mitigations=off`, could not give
them to its templates, so its clones ran another kernel configuration
than its cold sandboxes: Linux applies `mitigations=` once, as it
boots, and a clone has no other way to get it (#995).

KERNEL_TUNING_PARAMETERS names the parameters that OpenVMM now admits on
a platform capture's command line: `mitigations=off`,
`mitigations=auto`, and `mitigations=auto,nosmt`; `no_timer_check`; and
`quiet`, and `loglevel=0` to `loglevel=7`. CaptureClass gains
kernel_tuning, the parameters with which the template's kernel boots, in
their order, which CaptureClass::check refuses unless each is one of
them and each parameter appears at most once, so that a class that no
capture takes is refused before any VM boots.
TemplatePlan::with_kernel_tuning renders them after the plan's own
tokens, and a Store's captures boot with their class's. TemplateKey::new
also checks that the tuning parameters of the manifest's command line
are the class's, in their order, as it checks the rest of the machine
that the class requested. The key holds the command line already, so its
encoding is unchanged, and templates of classes that differ in their
tuning alone have keys of their own. NVX's fake OpenVMM accepts the
parameters after a capture's own tokens, as OpenVMM does, each at most
once.

The class's canonical encoding holds the parameters last, as a list of
texts, under version 2. A class's identity names the slot of its
captures and its generations in a store's index, so a creation finds
no generation that a class of version 1 captured, and captures one
again; those generations still serve the clones that select them by
their keys, which are unchanged. tests/vectors/capture-class-v2.txt
holds the class vectors of version 2, derived from the bytes of version
1's vectors and the definition, and one with tuning parameters.
template-key-v1.txt keeps the keys' vectors alone, since nothing
encodes a class of version 1 any more.

Tests: the plan renders the parameters after its own tokens, in their
order, and replaces them; the class check and the plan refuse a
parameter outside the set, another value or spelling of one, and a
repeated parameter; classes that differ in their tuning alone, order
included, have identities of their own, and encode the parameters last;
TemplateKey::new refuses a capture whose command line holds other tuning
than its class's; a store's capture passes its class's parameters in
OpenVMM's --cmdline, and refuses a snapshot whose command line lacks
them; nvx-rs's set is OpenVMM's, as the excerpt of its allowlist defines
it; the class vectors encode; and the fake OpenVMM accepts a capture's
tuning parameters, with or without a limit of the processors online at
boot, refuses others and repeated ones, and holds nvx-rs's set. With the
check, the encoding, the plan, the key's check, and the capture's tuning
neutralized, the seven tests of that logic fail. Existing tests change
where the new check or encoding reaches them: the key test's change of
its command line adds `quiet` to its class too, the class vectors move
to capture-class-v2.txt, and the helpers that build classes name no
tuning. The runtime adapter's class names none either.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
@ppenna
runtime-adapter: capture templates with kernel tuning parameters
a5908fa 
The runtime adapter, which builds on nvx's public API as an independent
adapter does, could not ask for the kernel tuning parameters that NVX's
capture classes now take (#995).

create and refresh take --kernel-tuning PARAMETER, once for each
parameter, in order, which capture::Request carries into the class's
kernel_tuning, so that the template's kernel, and every clone of it,
runs with them. NVX's class check refuses a parameter that is not one
of its KERNEL_TUNING_PARAMETERS, and a parameter given twice, before
the host program creates the store. The guest agent's check of a
template's command line, which compiles the excerpt of OpenVMM's
platform allowlist, admits the parameters since the pin of OpenVMM that
admits them, and is_platform_token's documentation and the README's
template mode now list them.

Tests: template_capture's
a_capture_takes_its_kernel_tuning_from_the_request checks that the
class takes the request's parameters in their order, which name a class
of their own, order included, while nothing else of the capture
changes, and that NVX's class refuses other parameters; vm_template's
kernel_tuning_that_no_capture_takes_is_refused_before_the_store checks
that `nokaslr`, `mitigations=on`, and `mitigations=` with two values
fail with status 1 before the store exists; and vm_clone's
a_template_s_clones_run_with_its_kernel_tuning_parameters captures a
template with `mitigations=off`, whose key's command line holds it, and
starts a clone whose /proc/cmdline is that command line. The template
module's a_template_s_command_line_may_hold_kernel_tuning_parameters
checks that a template's VM boots with the parameters on its command
line, and the_platform_tier_s_allowlist_is_openvmm_s and
template_mode_refuses_a_token_outside_the_allowlist now admit them and
refuse other values and spellings of them, such as `mitigations=on`,
`loglevel=8`, and `no-timer-check`. scenarios.txt and the README's
tables name the new tests, and template_capture's request helper names
no tuning.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
@ppenna
doc: map the kernel tuning on platform command lines in the OpenVMM r…
d487862 
…oadmap

Maps NVX's new pin, b4028c1aa, the head of microsoft/openvmm#5001, at
position 235, after position 234, f41a1ecfc, the head of
feature/microvm/dev, which microsoft/openvmm#4997 merged. The pin is
104 commits past the mapped tip, and positions 132-235 stay unassigned.

Position 235 makes the platform tier's check of a snapshot's command
line, which PR19's position 093 adds and PR20's position 097, PR23's
position 116, and positions 147 and 168 change, admit a closed set of
kernel tuning parameters in its allowlist, and refuse a command line
that repeats one of them, after position 097's check of the boot-online
processor count. It adds tests beside position 093's, and extends the
--snapshot-tier entry that position 093 adds to the CLI reference of
PR15's position 064. Replaying it on upstream main conflicts in both of
its files, since upstream main lacks the microVM snapshot module of
PR17's position 074, the tiers of position 093, and the microVM CLI of
position 064, so it follows PR15, PR17, and PR19 upstream.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot AI balanced review requested due to automatic review settings November 9, 2026 20:10
@github-actions github-actions Bot added the tests-modified Changes existing tests, test data, or test wiring label Nov 9, 2026
@github-actions

github-actions Bot commented Nov 9, 2026

Copy link
Copy Markdown
Contributor

This pull request changes existing tests

It modifies or removes 17 existing test asset(s), listed below. Review each with care: a change to a test can hide a regression that the test caught. See doc/contribute.md#changes-to-existing-tests.

Test code

Change What Before After
modified helper const VECTORS in host::template::key::tests (renamed to KEY_VECTORS) nvx-rs/src/host/template/key/tests.rs:911 nvx-rs/src/host/template/key/tests.rs:1094
modified helper fn vectors in host::template::key::tests nvx-rs/src/host/template/key/tests.rs:923 nvx-rs/src/host/template/key/tests.rs:1109
modified helper fn vector_class in host::template::key::tests nvx-rs/src/host/template/key/tests.rs:944 nvx-rs/src/host/template/key/tests.rs:1129
modified helper fn class in host::template::tests nvx-rs/src/host/template/tests.rs:955 nvx-rs/src/host/template/tests.rs:955
modified helper fn class in template_capture (tests) nvx-rs/tests/template_capture.rs:84 nvx-rs/tests/template_capture.rs:84
modified helper fn template in template_capture (tests) tests/runtime-adapter/tests/template_capture.rs:78 tests/runtime-adapter/tests/template_capture.rs:79
modified test fn each_part_of_the_key_changes_it in host::template::key::tests nvx-rs/src/host/template/key/tests.rs:48 nvx-rs/src/host/template/key/tests.rs:48
modified test fn the_conformance_vectors_decode_and_encode in host::template::key::tests nvx-rs/src/host/template/key/tests.rs:1022 nvx-rs/src/host/template/key/tests.rs:1214
modified test fn openvmms_platform_allowlist_admits_its_tokens_and_refuses_tenant_data in host::template::plan::tests nvx-rs/src/host/template/plan/tests.rs:522 nvx-rs/src/host/template/plan/tests.rs:620
modified test fn the_platform_tier_s_allowlist_is_openvmm_s in template::tests tests/runtime-adapter/src/template/tests.rs:46 tests/runtime-adapter/src/template/tests.rs:64
modified test fn the_platform_tier_s_allowlist_takes_tokens_as_openvmm_splits_them in template::tests tests/runtime-adapter/src/template/tests.rs:126 tests/runtime-adapter/src/template/tests.rs:154
modified test fn template_mode_refuses_a_token_outside_the_allowlist in template::tests tests/runtime-adapter/src/template/tests.rs:243 tests/runtime-adapter/src/template/tests.rs:291

Test data

Change What Before After
modified file nvx-rs/tests/vectors/openvmm/platform_command_line_token_is_invariant.rs nvx-rs/tests/vectors/openvmm/platform_command_line_token_is_invariant.rs nvx-rs/tests/vectors/openvmm/platform_command_line_token_is_invariant.rs
modified file nvx-rs/tests/vectors/template-key-v1.txt nvx-rs/tests/vectors/template-key-v1.txt nvx-rs/tests/vectors/template-key-v1.txt
modified file tests/runtime-adapter/scenarios.txt tests/runtime-adapter/scenarios.txt tests/runtime-adapter/scenarios.txt

Test doubles

Change What Before After
modified helper const CAPTURE_COMMAND_LINE in testing::fake_openvmm nvx-rs/src/testing/fake_openvmm.rs:210 nvx-rs/src/testing/fake_openvmm.rs:211
modified helper fn parse in testing::fake_openvmm nvx-rs/src/testing/fake_openvmm.rs:1145 nvx-rs/src/testing/fake_openvmm.rs:1166

Relocated unchanged: 0; added: 22. Compared the merge base 66b7cc591d0e with d48786283feb.

@ppenna Pedro Henrique Penna (ppenna) mentioned this pull request Nov 9, 2026
Merged
Copilot AI reviewed Nov 9, 2026
View reviewed changes

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔵 Needs a closer look

The OpenVMM pin depends on still-open PR #5001 with CI running, requiring maintainer confirmation that exact-pin CI passes and the revision lands on feature/microvm/dev before merging.

No open issues 🎉

What changed in this PR

Enables NVX templates to boot with an adapter’s supported kernel tuning parameters, addressing #995 so restored clones can use the same boot-time kernel configuration as cold sandboxes.

Changes:

  • Adds ordered, validated kernel tuning to capture classes, template plans, and capture verification, with version 2 class encoding.
  • Exposes repeatable --kernel-tuning options in the runtime adapter and adds validation and clone-inheritance tests.
  • Updates OpenVMM allowlist excerpts, conformance vectors, public API inventories, documentation, and pin roadmap mapping.
File Description
tests/​runtime-adapter/​tests/​vm_template.rs Tests invalid tuning rejection before store creation.
tests/​runtime-adapter/​tests/​vm_clone.rs Tests that clones retain template kernel tuning.
tests/​runtime-adapter/​tests/​template_capture.rs Tests request propagation, identities, and validation.
tests/​runtime-adapter/​src/​template/​tests.rs Tests expanded allowlist and unsupported tokens.
tests/​runtime-adapter/​src/​template.rs Documents supported tuning and duplicate validation.
tests/​runtime-adapter/​src/​capture.rs Carries requested tuning into capture classes.
tests/​runtime-adapter/​src/​bin/​runtime-adapter-host.rs Adds repeatable kernel tuning CLI options.
tests/​runtime-adapter/​scenarios.txt Registers new tuning scenarios.
tests/​runtime-adapter/​README.md Documents tuning options, behavior, and scenarios.
nvx-rs/​tests/​vectors/​template-key-v1.txt Removes class vectors while retaining key vectors.
nvx-rs/​tests/​vectors/​README.md Documents class encoding v2 and excerpt provenance.
nvx-rs/​tests/​vectors/​openvmm/​platform_command_line_token_is_invariant.rs Copies OpenVMM’s expanded tuning allowlist.
nvx-rs/​tests/​vectors/​capture-class-v2.txt Adds class encoding v2 conformance vectors.
nvx-rs/​tests/​template_capture.rs Initializes tuning in capture test fixtures.
nvx-rs/​src/​testing/​fake_openvmm/​tests.rs Tests fake capture tuning validation.
nvx-rs/​src/​testing/​fake_openvmm.rs Accepts supported, nonduplicate capture tuning.
nvx-rs/​src/​host/​template/​tests.rs Initializes tuning in shared class fixtures.
nvx-rs/​src/​host/​template/​store/​capture/​tests.rs Tests capture arguments and tuning mismatch rejection.
nvx-rs/​src/​host/​template/​store/​capture.rs Applies class tuning to capture plans.
nvx-rs/​src/​host/​template/​plan/​tests.rs Tests tuning order, replacement, and validation.
nvx-rs/​src/​host/​template/​plan.rs Adds the kernel tuning builder method.
nvx-rs/​src/​host/​template/​mod.rs Exports tuning parameters and updates encoding documentation.
nvx-rs/​src/​host/​template/​key/​tests.rs Tests tuning identities, matching, and conformance vectors.
nvx-rs/​src/​host/​template/​key.rs Validates and encodes tuning; checks manifest agreement.
nvx-rs/​README.md Documents template tuning and class identity changes.
nvx-rs/​public-api/​windows.txt Records new Windows-visible public API items.
nvx-rs/​public-api/​linux.txt Records new Linux-visible public API items.
doc/​openvmm-upstream-roadmap.md Maps the kernel tuning pin at position 235.

Review effort: Balanced

@ppenna
Pedro Henrique Penna (ppenna) added this pull request to the merge queue Nov 9, 2026
This was referenced Nov 9, 2026
Merged
Merged
Open
Merged via the queue into dev with commit dca5af1 Nov 9, 2026
51 checks passed
@ppenna
Pedro Henrique Penna (ppenna) deleted the agents/issue-995-kernel-tuning branch November 9, 2026 21:40
This was referenced Nov 9, 2026
Merged
Draft
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

Copilot code review Copilot
Copilot review effort
Applies to this pull request for everyone.Learn more about Copilot code review.
Copilot left review comments

Assignees

No one assigned

Labels

tests-modified Changes existing tests, test data, or test wiring

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

nvx-rs: boot templates with an adapter's kernel tuning parameters, such as mitigations=off

2 participants

@ppenna