Repository navigation
Speed up QEMU startup and browser/native output delivery - #163
Merged
Merged
Conversation
Signed-off-by: m5agent <329351612+m5agent@users.noreply.github.com>
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.
Speed up QEMU startup and browser/native output delivery while retaining the existing single QEMU device-model architecture and TCI browser runtime. The changes cover verified immutable-asset/module reuse, typed helper calls with libffi fallback, bounded GPIO transactions, opt-in diagnostics, independent frame/output polling, exact-firmware normal-clock profiles, and retained-frame orientation repainting. The experimental JIT is excluded.
Virtual-device validation: a fresh 72-patch runtime, final 19-board / 20-reference-case browser gate (552 checks), independent original StackChan dance cold/repeat and touch runs, original CoreS3 reference composition, and native delivery controls. The 19-board gate is functional regression coverage, not a claim that every board was benchmarked or accelerated. StackChan ready is 3.559/2.746 s versus the previous 11.674 s; the comparison includes the documented clock/profile and cache differences. Official Factory browser compatibility remains PARTIAL; hardware and long-soak validation were not run.
Validation: the complete local platform suite (1,942 tests, 10 skips), seven portable host C contracts, Node contracts, generated validators, source-lock checks, independent patch replay and exact-tree patch application pass. Both updated-head CI runs pass platform-contracts and network-namespace-policy (four successful checks); the host-only follow-up preserves complete assertion/stdout/signal comparisons across macOS and glibc. Reproducible configuration, firmware/runtime hashes, failures and limits are in the fixed work record. Pages deployment is a separate subsequent step authorized by the user.