Skip to content

ps2, jitv2: cap mouse packets at 127 and let IRIS_JIT_VERIFY turn the IR verifier back on - #379

Merged
techomancer merged 5 commits into
techomancer:mainfrom
jamesbraid:ps2-packet-cap
Oct 31, 2026
Merged

techomancer merged 5 commits into
techomancer:mainfrom
jamesbraid:ps2-packet-cap

Conversation

@jamesbraid

@jamesbraid jamesbraid commented Oct 31, 2026 •

Copy link
Copy Markdown
Contributor

Folds in #381 (the IRIS_JIT_VERIFY toggle), which is now closed.

ps2: mouse packets capped at 127

Fast host mouse moves, or a mouse queue the guest has fallen behind
on, produced PS/2 packets carrying more than 127 counts on an axis.
IRIX 6.5.30 misreads those: a packet with 128 counts or more leaves the
X pointer stuck, and later small moves are ignored until a large move
the other way. Single-packet tests found the limit exactly: 127 moves
the pointer, 128 sticks it. The guest read every byte, so the fault is
in how it takes a 9-bit delta, not in delivery. The PS/2 code is shared
by the Indy, Indigo2 and Octane models.

The controller sent any move up to 255 in one packet, and merged moves
into the queue's last packet up to 255 when the guest fell behind.

Split a move into packets of at most 127 counts an axis, and merge into
the last packet only while the sum stays within that, so no motion is
dropped. A mouse at its default sampling rate does not report more in
one packet in normal use, and QEMU's hw/input/ps2.c caps its packets
the same way.

Tested with the two new unit tests (a 200/-300 move splits into packets within 127 that sum to the move; a merge into a backed-up queue stays within 127 and loses none), the full cargo test --release --lib (1901 passed) and nextest (1901 passed). Not run against a guest.

jitv2: IRIS_JIT_VERIFY turns the IR verifier back on

#377 turned Cranelift's IR verifier off outside unit tests and --features developer builds. A codegen bug in a release build then shows up as a miscompile or crash at run time instead of a verifier panic at compile time. IRIS_JIT_VERIFY=1 (or on) turns the verifier back on in any build, so a crash can be checked without rebuilding.

Also:

  • verifier_off_emits_the_same_code now compares verifier-on and verifier-off machine code for five page shapes instead of one: loads and stores of each width, FP, branch-likely, and a multi-block page with forward and backward branches.
  • The doc comment and CHANGELOG say exactly where the verifier runs. A Cargo profile named developer doesn't enable the feature, and integration tests and bins such as jitv2-verify run unverified unless the variable is set.
  • The CHANGELOG quotes the same boot timings as jitv2: compile without Cranelift's IR verifier #377's description.

Tested with cargo test --release --features jitv2 --lib and nextest (2388 passed), and cargo check --release --bins --tests with and without jitv2. Nothing tests the environment variable itself, because unit tests always run the verifier.

gitignore: runtime files

Ignore /.iris/ and nvram.bin.*.tmp, the runtime files iris writes in its working directory, so agents stop committing them by accident.

Fast host mouse moves, or a mouse queue the guest has fallen behind
on, produced PS/2 packets carrying more than 127 counts on an axis.
IRIX 6.5.30 misreads those: a packet with 128 counts or more leaves the
X pointer stuck, and later small moves are ignored until a large move
the other way. Single-packet tests found the limit exactly: 127 moves
the pointer, 128 sticks it. The guest read every byte, so the fault is
in how it takes a 9-bit delta, not in delivery. The PS/2 code is shared
by the Indy, Indigo2 and Octane models.

The controller sent any move up to 255 in one packet, and merged moves
into the queue's last packet up to 255 when the guest fell behind.

Split a move into packets of at most 127 counts an axis, and merge into
the last packet only while the sum stays within that, so no motion is
dropped. A mouse at its default sampling rate does not report more in
one packet in normal use, and QEMU's hw/input/ps2.c caps its packets
the same way.
The verifier is off outside unit tests and developer builds, so invalid
IR from a codegen bug becomes a miscompile or a crash at run time rather
than a panic at compile time. Setting IRIS_JIT_VERIFY=1 (or "on") runs it
in any build, which lets someone holding a crash report get the clean
panic without rebuilding. Same values and caching as IRIS_JIT_CACHE.

The doc comment and CHANGELOG now say where it is on: a Cargo profile
named developer does not enable features, and integration tests and bins
such as jitv2-verify run unverified unless the variable is set.
The test compared the two builds on one page of word loads and stores.
The IR for narrow and 64-bit memory ops, FP ops, branch-likely, forward
and backward branches and jumps comes from different codegen paths, so
a flag that changed any of them would have gone unnoticed. Compile one
page of each and compare the machine code.
The entry gave x86 timings that appear nowhere else; the pull request
reports Fuel's boot to the login prompt in the loop and fast profiles.
Use those so the two agree.
@Samueltgg12

Copy link
Copy Markdown
Contributor

@techomancer cool.

@jamesbraid jamesbraid changed the title ps2: send mouse moves as packets of at most 127 counts an axis ps2, jitv2: cap mouse packets at 127 and let IRIS_JIT_VERIFY turn the IR verifier back on Oct 31, 2026
iris writes .iris/rex-jit-profile.bin and nvram.bin.<pid>.<n>.tmp into the
working directory at run time, and agents have committed them by accident.
Ignore both so they stay out of status and commits.
@techomancer
techomancer merged commit b60021a into techomancer:main Oct 31, 2026
13 of 14 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants