Wasmtime GitHub notifications bot (Oct 21 2026 at 21:32): Wasmtime GitHub notifications bot (Oct 21 2026 at 21:32):erikrose opened PR #14929 from erikrose:mmu-interrupt-config to bytecodealliance:main:
This is step 2 of implementing MMU-triggered interruption of Wasm, broken off the large #12990 for ease of review. Additional background is in the original feature suggestion: #1749.
This PR consists of...
- A
Configoption, for controlling runtime behavior- An engine tunable, for controlling whether interruption checkpoints get compiled into JITted wasm
- A
has_mmu_interruptioncfg flag in crates/wasmtime for avoiding compilation of MMU-interruption runtime code on unsupported platforms or compile-time configurations- A second
has_mmu_interruption, in the top level, for gating compile-time code in the CLI.These controls will keep to-be-landed parts of MMU interruption from running until the entire feature is in place. Keep in mind not all of these are read by anything yet.
No vestige of MMU interruption is yet visible from the commandline.
Wasmtime GitHub notifications bot (Oct 21 2026 at 23:45):github-actions[bot] added the label wasmtime:api on PR #14929.
Wasmtime GitHub notifications bot (Oct 21 2026 at 23:45):github-actions[bot] added the label winch on PR #14929.
Wasmtime GitHub notifications bot (Oct 21 2026 at 23:45):github-actions[bot] added the label wasmtime:config on PR #14929.
Wasmtime GitHub notifications bot (Oct 22 2026 at 01:55):github-actions[bot] commented on PR #14929:
Subscribe to Label Action
cc @saulecabrera
<details>
This issue or pull request has been labeled: "wasmtime:api", "wasmtime:config", "winch"Thus the following users have been cc'd because of the following labels:
- saulecabrera: winch
To subscribe or unsubscribe from this label, edit the <code>.github/subscribe-to-label.json</code> configuration file.
Learn more.
</details>
Wasmtime GitHub notifications bot (Oct 22 2026 at 03:52):github-actions[bot] commented on PR #14929:
Label Messager: wasmtime:config
It looks like you are changing Wasmtime's configuration options. Make sure to
complete this check list:
[ ] If you added a new
Configmethod, you wrote extensive documentation for
it.<details>
Our documentation should be of the following form:
```text
Short, simple summary sentence.More details. These details can be multiple paragraphs. There should be
information about not just the method, but its parameters and results as
well.Is this method fallible? If so, when can it return an error?
Can this method panic? If so, when does it panic?
Example
Optional example here.
```</details>
[ ] If you added a new
Configmethod, or modified an existing one, you
ensured that this configuration is exercised by the fuzz targets.<details>
For example, if you expose a new strategy for allocating the next instance
slot inside the pooling allocator, you should ensure that at least one of our
fuzz targets exercises that new strategy.Often, all that is required of you is to ensure that there is a knob for this
configuration option in [wasmtime_fuzzing::Config][fuzzing-config] (or one
of its nestedstructs).Rarely, this may require authoring a new fuzz target to specifically test this
configuration. See [our docs on fuzzing][fuzzing-docs] for more details.</details>
[ ] If you are enabling a configuration option by default, make sure that it
has been fuzzed for at least two weeks before turning it on by default.[fuzzing-config]: https://github.com/bytecodealliance/wasmtime/blob/ca0e8d0a1d8cefc0496dba2f77a670571d8fdcab/crates/fuzzing/src/generators.rs#L182-L194
[fuzzing-docs]: https://docs.wasmtime.dev/contributing-fuzzing.html
<details>
To modify this label's message, edit the <code>.github/label-messager/wasmtime-config.md</code> file.
To add new label messages or remove existing label messages, edit the
<code>.github/label-messager.json</code> configuration file.</details>
Wasmtime GitHub notifications bot (Oct 22 2026 at 16:39)::memo: alexcrichton submitted PR review:
I'm mostly a bit worried here about how the filter of what architectures/OS-es are supported is replicated across 4 different locations -- I'd ideally like to consolidate this all to just one if that's workable.
Wasmtime GitHub notifications bot (Oct 22 2026 at 16:39)::speech_balloon: alexcrichton created PR review comment:
I think the architecture/OS checks here are redundant -- this is already gated at compile-time right?
Wasmtime GitHub notifications bot (Oct 22 2026 at 16:39)::speech_balloon: alexcrichton created PR review comment:
How come the CLI crate needs this?
Wasmtime GitHub notifications bot (Oct 22 2026 at 16:39)::speech_balloon: alexcrichton created PR review comment:
Is this necessary as an extra #[cfg]? This largely boils down to
has_native_signals, right?
Wasmtime GitHub notifications bot (Oct 29 2026 at 20:30):erikrose commented on PR #14929:
I took another swing at factoring out the
has_mmu_interruptionconfig while working on the fuzzer scaffolding (which was going to require a third repetition). I think it's going to work out. Will push an update soon.
Last updated: Oct 31 2026 at 23:03 UTC