Repository navigation
ps2, jitv2: cap mouse packets at 127 and let IRIS_JIT_VERIFY turn the IR verifier back on - #379
Merged
Merged
Conversation
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.
Contributor
|
@techomancer cool. |
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.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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 developerbuilds. 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(oron) turns the verifier back on in any build, so a crash can be checked without rebuilding.Also:
verifier_off_emits_the_same_codenow 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.developerdoesn't enable the feature, and integration tests and bins such asjitv2-verifyrun unverified unless the variable is set.Tested with
cargo test --release --features jitv2 --liband nextest (2388 passed), andcargo check --release --bins --testswith and withoutjitv2. Nothing tests the environment variable itself, because unit tests always run the verifier.gitignore: runtime files
Ignore
/.iris/andnvram.bin.*.tmp, the runtime files iris writes in its working directory, so agents stop committing them by accident.