{"id":"52d36edd-2f49-4fd0-970f-56c787df5949","arxiv_id":"1908.06807","paper_version":2,"verdict":"CONDITIONAL","confidence":"HIGH","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":2,"one_line_summary":"Boomerang's composable tuned pipes provide end-to-end delay guarantees for I/O pipelines that span a real-time OS and Linux, outperforming Linux with SCHED_DEADLINE reservations.","lead":"This paper presents Boomerang, a system that runs a small real-time operating system and a full Linux system on the same computer, separated by a lightweight partition hypervisor, so time-critical I/O can use Linux features while meeting hard deadlines. It shows that carefully tuned data pipelines spanning both systems meet worst-case delay bounds, and that a Linux-only setup fails to do so under the same workload.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"End-to-end delay guarantee depends on pre-profiled WCET values (Sec. III-A/E); no evidence these are safe upper bounds, so the 'guarantee' is empirical, not proven.","rationale":"Reader identified WCET as the weakest assumption; I agree. The paper's novelty is a composable abstraction that turns a QoS spec into budgets/periods, but the transformation is only as sound as the WCET inputs. All subsequent analysis (Sec. III-E) is standard reservation theory; the evaluation shows the implementation meets bounds on the tested workloads, which is genuine supporting evidence (real CAN hardware, 10 runs, two pipelines, MIMO). The ACRN comparison is methodologically weak—it changes both hypervisor and guest OS and uses a heavyweight virtio/TCP path—but it is not load-bearing for the main guarantee claim; it only supports the secondary 'outperforms ACRN' claim. Lack of code/data is a reproducibility concern, not a correctness flaw per se. The most direct threat to the central claim is the unvalidated WCET: if the profiled bounds are too small, the solver produces an infeasible schedule and every downstream delay guarantee collapses. The concrete test—static WCET analysis or adversarial instrumentation—would determine whether this concern lands. If the test shows budgets are safe, the main claim is substantially supported; if not, the guarantee must be restated as best-effort or the budgets must be increased.","tokens_in":19243,"tokens_out":8713,"duration_ms":92294,"concrete_test":"Run a sound static WCET analysis (e.g., OTAWA or aiT) on the exact binaries of the callbacks in Table I for the Pentium N4200, including worst-case input sizes and cache states; if any computed WCET exceeds the budget C_i listed in Table I (0.1/0.2 ms), the sum-of-periods delay bound is unsound. Alternatively, instrument the Boomerang kernel to log each callback's execution time over 10^6 invocations with worst-case CAN bursts and cache-cold starts; if any observed execution exceeds C_i, the guarantee is falsified. A negative result (all executions below C_i) would support but not prove the claim; a positive result would settle that the current budgets are not true WCETs.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central claim—that Boomerang guarantees end-to-end processing delays—rests on the repository's assertion that 'each callback has a known worst-case execution time (WCET) based on pre-profiled timing information' (Sec. III-A), and on Sec. III-E's assumption that each budget C_i is derived from this WCET. The solver then chooses periods T_i with sum T_i ≤ e2e delay, and the delay analysis assumes every callback finishes within C_i. Profiling is not a sound method for obtaining WCET: it cannot bound rare microarchitectural states (cache misses, TLB misses, bank conflicts, interrupt-induced pipeline flushes) or input-dependent execution paths unless the profiling campaign happens to exercise them. Table I sets budgets as low as 0.1 ms and 0.2 ms, yet no per-callback execution-time measurements or profiling methodology are reported; only end-to-end delays for the first 200 packets over 30 s are shown. If any callback overruns C_i, the VCPU/SCHED_DEADLINE server throttles it, so that message is delayed to a later period and the sum-of-periods bound is no longer valid—the 'guarantee' becomes an empirical observation about those specific runs. The Linux-side pipeline stage (ProcData) is also subject to interrupt interference on Core 1, which Sec. II explicitly excludes from SCHED_DEADLINE guarantees; the evaluation redirects other device interrupts to that core, so the cross-guest guarantee has an unmodelled interference source. Without code or data release (Sec. VI: 'will be made available'), none of this can be independently checked. These points do not show the system is broken; they show the headline guarantee is conditional on an unverified and possibly unverifiable WCET assumption.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper presents Boomerang, a partitioning hypervisor that co-locates the Quest RTOS and a Linux guest on separate cores of a multicore machine, partitioning CPU cores, memory, and I/O devices between the guests. The main contribution is a composable 'tuned pipe' abstraction: each pipeline stage is a callback bound to a VCPU or server with a budget C_i and period T_i, and a constraint solver sets these parameters from pre-profiled per-callback WCETs so that the sum of periods along the longest path is within a user-specified end-to-end delay, while throughput and loss requirements are handled for FIFO and four-slot buffering. The evaluation on an Up Squared board with CAN bus traffic compares Boomerang against standalone Linux using SCHED_DEADLINE and against the ACRN hypervisor, for asynchronous, synchronous (FIFO), and MIMO pipelines. The measurements show Boomerang staying within the computed delay bounds in the tested runs, while Linux SMP and ACRN do not.","tokens_in":19534,"tokens_out":9152,"duration_ms":91630,"significance":"If the end-to-end guarantees are taken as validated, Boomerang offers a useful integration point for mixed-criticality systems that need legacy Linux services alongside RTOS-timed I/O. The design strength is that the delay bound is computed a priori by the constraint solver and then checked by measurement, so the evaluation is a genuine check of the design rather than a post-hoc fit. The RTOS-side handling of interrupt bottom-halves via IO VCPUs addresses a real priority-inversion problem in Linux. However, the validity of the guarantee rests on pre-profiled WCETs, which are not shown to be safe upper bounds, and the Linux-side pipeline stage is subject to unmodeled interrupt interference. The ACRN comparison is also not apples-to-apples. These issues affect the central claims enough that revision is required, but the core ideas are defensible.","major_comments":[{"comment":"The end-to-end guarantee is built on the assumption in Section III-A that each callback has a known worst-case execution time based on pre-profiled timing information, and Section III-E states that C_i is derived from this WCET. Profiling alone does not establish a worst-case bound: it cannot capture rare cache, TLB, or microarchitectural states or input-dependent path variations unless the profiling campaign exhaustively exercises them. Table I sets the tightest budgets at 0.1 ms, yet no per-callback execution-time measurements or profiling methodology are reported. If any callback occasionally exceeds C_i, the server throttles that pipe and the affected message is deferred to a later period, so the sum-of-periods bound in Section III-E is no longer valid. As written, the 'guarantee' is conditional on an unverified WCET bound; the paper should either provide evidence that the profiled values are safe upper bounds (for example, a measurement methodology with margins, or static WCET analysis) or soften the guarantee claim accordingly.","section":"Section III-A and III-E"},{"comment":"Pipeline 1's Linux-side stage ProcData (τ4) runs on Core 1, where Section IV states that all device interrupts other than xHCI are redirected, and where 11 background tasks generate disk and network I/O. Section II explicitly conditions SCHED_DEADLINE scheduling guarantees on the absence of interrupt interference. The delay bound in Table I therefore does not account for interrupt-induced delays on the cross-guest path, which is exactly the path the paper claims as its principal new capability. The measurements show the bound is met in these runs, but a guarantee requires that the interference source be modeled or excluded; without that, the cross-guest delay claim is empirical rather than assured.","section":"Section IV (setup) and Section II"},{"comment":"The ACRN comparison is confounded: Boomerang and Linux SMP use Yocto Linux kernel 4.9.99 with PREEMPT_RT, while the ACRN SOS and UOS use ClearOS Linux kernel 4.19.73 (as recommended by the ACRN developers). The paragraph also states that Quest was intentionally not ported to ACRN. Because the compared systems differ in both the hypervisor and the guest OS, the observed latency differences cannot be attributed to Boomerang's design. The Abstract's claim that Boomerang 'outperforms' ACRN is not supported by a controlled comparison.","section":"Section IV-B"},{"comment":"The bound stating that worst-case end-to-end delay equals the sum of the tuned-pipe periods is justified only by the special-case example in Figure 7, in which all tasks have the same service time and period. No proof is given for pipelines with different C_i/T_i, arbitrary phase offsets, multi-CPU paths, or mixed Quest/Linux scheduling. If the bound is intended as a formal guarantee, the authors should state the assumptions (e.g., each stage consumes at most one quantum per period, no release jitter, no scheduling overhead) and provide a concise derivation; otherwise the reader cannot verify the central claim for the general pipelines used in the evaluation.","section":"Section III-E"}],"minor_comments":[{"comment":"The terms 'RT_ASYNC' and 'RT_FIFO' are introduced before the buffering modes are explained; consider defining them at first use.","section":"Section III-B"},{"comment":"In the toy example, the symbol T is used both for the number of tasks and the common period, which is confusing; use n for the number of tasks.","section":"Section III-E"},{"comment":"The caption of Figures 10a and 10b contains a typo: 'show the the performance' should read 'show the performance'.","section":"Section IV-A"},{"comment":"End-to-end delay results are limited to the first 200 packets, and the claim that 'similar behavior was observed for more extensive runs' is not supported by data; consider showing a longer trace or a summary statistic.","section":"Section IV-A"},{"comment":"The statement 'As Boomerang already outperforms Linux SMP, it follows that ACRN's lack of timing predictability makes it inferior' is a non-sequitur; the ACRN comparison needs explicit data.","section":"Section IV-B"},{"comment":"The source-code release is promised as 'will be made available' at www.questos.org; if code is not available at the time of review, reproducibility would be strengthened by including the experimental configuration and raw data in a supplement.","section":"Section VI"}],"recommendation":"major_revision","confidential_remarks":"The paper is an incremental extension of the authors' prior work (Quest, Quest-V, and tuned pipes), but the cross-guest composability and the constraint-solver-based parameter setting are sufficiently novel for a systems venue. The main risk is the gap between the word 'guarantee' and the pre-profiling/WCET basis; the authors should be pushed either to substantiate the WCET bounds or to explicitly restrict the claim to empirical performance. The ACRN comparison should also be redone or downplayed."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Here's my take on Golchin et al.'s Boomerang paper. It's a real systems contribution: it extends the tuned-pipe idea from a single OS to pipelines that span Quest and Linux under a partitioning hypervisor, with end-to-end delay bounds computed as the sum of VCPU periods. The evaluation is on real CAN hardware, and the measured delays stay under the bound for both an all-Quest pipeline and one that dips into Linux. That is a meaningful step for mixed-criticality I/O, and the paper does it without pretending Linux alone can be made predictable by SCHED_DEADLINE. The experiments actually show Linux missing the bound, which is good evidence for their design.\n\nThe soft spot I'd push on is the WCET assumption. Section III-A says each callback has a \"known WCET based on pre-profiled timing information,\" and Section III-E repeats that C_i is derived from that WCET. But no profiling methodology or per-callback numbers are reported. Budgets like 0.1ms are taken as fact. If any callback overruns its budget, the server throttles it, and the sum-of-periods delay bound no longer applies. So the headline \"guarantees\" is more precisely an empirical result for the tested runs. This isn't fatal for a systems paper, but it is exactly the kind of thing a referee should ask the authors to substantiate.\n\nThe ACRN comparison is weaker than it looks: they changed both the hypervisor and the guest OS (ClearOS rather than Yocto Linux), and the inter-guest communication mechanism differs as well. So the comparison says \"Boomerang as a whole beats ACRN as a whole,\" not \"partitioning hypervisor X beats Y.\" That's a minor-to-moderate flaw, not a reason to reject.\n\nNo code or data yet. They say it will be made available, but the paper would be more credible with the tpipe implementation and the profiling scripts.\n\nOverall: the paper is worth a serious referee. I would accept it for review, with a request for stronger evidence on WCETs, a cleaner comparison, and a commitment to release code. It is an honest, well-argued systems paper, but the central guarantee needs to be stated with more care.","headline":"Solid systems paper extending tuned pipes across a partitioning hypervisor, but the end-to-end 'guarantee' rests on unvalidated pre-profiled WCETs and the ACRN comparison isn't clean; still deserves peer review.","tokens_in":20130,"tokens_out":3147,"would_cite":true,"duration_ms":32767,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"Boomerang guarantees end-to-end I/O delays for pipelines that span a real-time OS and legacy Linux, and its evaluation keeps measured delays inside the bounds.","keywords":["real-time I/O","partitioning hypervisor","mixed-criticality systems","composable tuned pipes","end-to-end delay guarantees","Quest RTOS","Linux SCHED_DEADLINE","CAN bus"],"falsifier":"Run the paper's CAN-bus pipelines on an Up Squared board while forcing one callback to exceed its profiled worst-case execution time, for example by using a slower USB device or injecting cache misses; if any packet's end-to-end delay goes above the sum of the tuned-pipe periods on its path, the guarantee as stated has failed.","tokens_in":19016,"feed_emoji":"⏱️","tokens_out":7667,"duration_ms":70936,"temperature":0.7,"pith_summary":"Boomerang is an I/O system that claims to guarantee end-to-end processing delays for sensing, processing, and actuation paths whose tasks run partly in a custom real-time OS (Quest) and partly in a legacy Linux system. It does this by turning each pipeline stage into a tuned pipe whose CPU budget and period are chosen by a constraint solver so that the sum of periods along the longest path stays within the required end-to-end delay. The paper argues that this gives mixed-criticality systems a way to use Linux's drivers, libraries, and accelerators while keeping time-critical I/O on an RTOS that is spatially isolated from everything else. In experiments with two CAN-bus pipelines on an Up Squared board, Boomerang kept measured delays below the computed bounds, whereas a standalone Linux system using SCHED_DEADLINE reservations missed the bounds and dropped packets, and the ACRN partitioning hypervisor was less predictable still.","feed_headline":"Boomerang keeps I/O deadlines when pipelines cross into Linux","feed_subtitle":"Composable tuned pipes let a real-time OS and a legacy OS cooperate within a single end-to-end delay bound.","key_machinery":"The central object is the composable tuned pipe (tpipe): a pipeline stage bound to a VCPU with an automatically computed budget $C_i$ and period $T_i$, connected to other pipes through either Simpson's four-slot asynchronous buffers (for freshness without blocking) or FIFO ring buffers (for lossless, rate-matched communication). The load-bearing identity is the end-to-end delay bound: for the longest path $l$, $\\sum_{i\\in l} T_i \\le \\text{e2e delay}$, with throughput bounded by $\\min_i \\{m_i/T_i\\}$ and four-slot loss bounded by $\\max\\{1 - T_p/T_c\\}$. The solver adjusts periods and budgets, halving producer periods and doubling consumer budgets, until the path meets the bound and all VCPUs pass a schedulability test on their PCPUs.","core_discovery":"The paper's central claim is that composable tuned pipes can give end-to-end timing guarantees to I/O paths that cross the boundary between an RTOS and a non-real-time legacy OS. A tuned pipe is a VCPU with a budget $C_i$ and period $T_i$; for a pipeline, Boomerang's constraint solver sets these parameters so that the sum of the periods on the longest path is no larger than the required end-to-end delay, with buffers sized so that blocking is avoided, and with all VCPUs satisfying a schedulability test (RMS or EDF) on their assigned physical cores. Interrupt handling in the RTOS is charged to IO VCPUs tied to the Main VCPU that issued the I/O, so bottom-half handlers run at the priority of the task they serve; in the Linux guest, tasks run under SCHED_DEADLINE with interrupts demoted to lower priority. The paper reports that for two CAN-bus pipelines spanning Quest and Linux, measured end-to-end delays stayed within bounds (for example, a maximum of 9.57 ms against a 10 ms bound), loss stayed within the allowed 20 percent, and throughput matched arrival rates, while Linux-only pipelines frequently exceeded the bounds and lost 28 to 56 percent of packets.","pith_inferences":["The same composition mechanism should carry over to any legacy guest that offers reservation-based scheduling and lets interrupt handling be demoted or isolated; Windows or Android guests would be natural next targets, though the paper only demonstrates Linux.","Because the guarantee rests on profiled worst-case execution times, Boomerang would benefit from coupling each tpipe callback to a runtime enforcement mechanism such as budget exhaustion traps that convert a WCET violation into a detectable pipeline failure rather than a silent deadline miss.","The endpoint capability model left as future work could turn Boomerang into a substrate for secure information-flow control: if pipe connectivity is restricted by access policies, the same delay analysis would bound leakage channels, an idea the paper mentions but does not develop.","A testable extension is to use the same tuning equations with different schedulers, such as global EDF or partitioned EDF across many cores, and derive the analogous sum-of-periods bound; the paper's single-core-per-path analysis may understate the complexity on heterogeneous hardware."],"forward_implications":["Mixed-criticality automotive and avionics systems can run safety-critical sensing and actuation on an RTOS while offloading rich services such as cameras, GPUs, and machine-learning libraries to Linux, without dedicating separate hardware.","A legacy OS can be made part of a hard real-time path if its tasks use reservation scheduling and its interrupts are demoted below task priority; the bottleneck is interrupt handling, not the OS itself.","Boomerang-style partitioning removes the hypervisor from runtime resource management, shrinking the trusted code base and avoiding VMExits during inter-guest communication.","Pipeline QoS specifications can express throughput, loss, and delay together: a four-slot pipeline tolerates known loss rates for sensor data, while a FIFO pipeline enforces lossless throughput.","The design extends to multiple-input, multiple-output pipelines, since the delay constraint is applied per longest path and the throughput constraint per bottleneck output."],"supporting_citations":[{"why":"Supplies the tuned-pipe abstraction for end-to-end throughput and delay guarantees within a single OS, which Boomerang extends to span multiple guests.","marker":"[7]"},{"why":"Provides the Quest VCPU scheduling model, including Main VCPUs, IO VCPUs, and Sporadic Server budgets that Boomerang uses for real-time tasks and interrupt handling.","marker":"[8]"},{"why":"Diagnoses the priority mismatch of interrupt handling in conventional systems, motivating the RTOS's interrupt charging and the Linux interrupt demotion in Boomerang.","marker":"[9]"},{"why":"Describes the Quest-V separation kernel on which Boomerang's partitioning hypervisor approach is modeled.","marker":"[10]"},{"why":"Presents the Jailhouse partitioning hypervisor, a related design with no VM exits for guests, used as context for Boomerang's hypervisor and for comparison with ACRN.","marker":"[11]"},{"why":"Gives the exact rate-monotonic schedulability characterization used to test whether a new VCPU can be admitted alongside existing pipeline VCPUs.","marker":"[13]"},{"why":"Supplies the RMS and EDF scheduling constraints that the constraint solver applies to ensure all tuned-pipe VCPUs are schedulable on their assigned cores.","marker":"[15]"},{"why":"Defines Simpson's four-slot fully asynchronous communication mechanism used for the RT_ASYNC buffers in Boomerang's tuned pipes.","marker":"[16]"},{"why":"Describes the Constant Bandwidth Server that underpins Linux SCHED_DEADLINE, the mechanism by which Linux-side tuned-pipe tasks receive CPU reservations.","marker":"[23]"},{"why":"Identifies ACRN, the partitioning hypervisor used in the comparison experiments that Boomerang outperforms.","marker":"[50]"}],"fun_headline_variants":["Boomerang guarantees I/O deadlines across RTOS and Linux","Tuned pipes bridge real-time and legacy OS without breaking bounds","Cross-OS I/O pipelines meet end-to-end delay guarantees","Boomerang beats Linux and ACRN for real-time I/O pipelines","Composable pipes enforce I/O timing across OS boundaries"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The end-to-end guarantee rests on each callback's worst-case execution time being known from pre-profiling; if a callback ever runs longer than its profiled budget on real hardware, the solver's CPU budgets are too small and the delay bound no longer holds.","fun_headline_variants_meta":{"raw":{"variants":["Boomerang guarantees I/O deadlines across RTOS and Linux","Tuned pipes bridge real-time and legacy OS without breaking bounds","Cross-OS I/O pipelines meet end-to-end delay guarantees","Boomerang beats Linux and ACRN for real-time I/O pipelines","Composable pipes enforce I/O timing across OS boundaries"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000227,"raw_usage":{"total_tokens":1488,"prompt_tokens":979,"completion_tokens":509,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":595,"completion_tokens_details":{"reasoning_tokens":420}},"tokens_in":595,"tokens_out":509,"duration_ms":4768,"temperature":1.0,"reasoning_tokens":420,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-14T12:34:13.069209+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run the paper's CAN-bus pipelines on an Up Squared board while forcing one callback to exceed its profiled worst-case execution time, for example by using a slower USB device or injecting cache misses; if any packet's end-to-end delay goes above the sum of the tuned-pipe periods on its path, the guarantee as stated has failed.","supporting_citations":[{"cited_title":"Tuned Pipes: End-to-E nd Through- put and Delay Guarantees for USB Devices,","cited_arxiv_id":null,"evidence_quote":"Supplies the tuned-pipe abstraction for end-to-end throughput and delay guarantees within a single OS, which Boomerang extends to span multiple guests."},{"cited_title":"Virtual-CPU Scheduling in the Quest Operating System,","cited_arxiv_id":null,"evidence_quote":"Provides the Quest VCPU scheduling model, including Main VCPUs, IO VCPUs, and Sporadic Server budgets that Boomerang uses for real-time tasks and interrupt handling."},{"cited_title":"Process-Aware Interrupt Scheduli ng and Ac- counting,","cited_arxiv_id":null,"evidence_quote":"Diagnoses the priority mismatch of interrupt handling in conventional systems, motivating the RTOS's interrupt charging and the Linux interrupt demotion in Boomerang."},{"cited_title":"A Virtualize d Separation Kernel for Mixed-Criticality Systems,","cited_arxiv_id":null,"evidence_quote":"Describes the Quest-V separation kernel on which Boomerang's partitioning hypervisor approach is modeled."},{"cited_title":"Loo k Mum, No VM Exits! (Almost),","cited_arxiv_id":null,"evidence_quote":"Presents the Jailhouse partitioning hypervisor, a related design with no VM exits for guests, used as context for Boomerang's hypervisor and for comparison with ACRN."},{"cited_title":"The Rate Monotonic Sch eduling Algorithm: Exact Characterization and Average Case Behavi or,","cited_arxiv_id":null,"evidence_quote":"Gives the exact rate-monotonic schedulability characterization used to test whether a new VCPU can be admitted alongside existing pipeline VCPUs."},{"cited_title":"Scheduling Algorithms for M ultiprogram- ming in a Hard Real-Time Environment,","cited_arxiv_id":null,"evidence_quote":"Supplies the RMS and EDF scheduling constraints that the constraint solver applies to ensure all tuned-pipe VCPUs are schedulable on their assigned cores."},{"cited_title":"Four-slot Fully Asynchronous Communicat ion Mechan- ism,","cited_arxiv_id":null,"evidence_quote":"Defines Simpson's four-slot fully asynchronous communication mechanism used for the RT_ASYNC buffers in Boomerang's tuned pipes."},{"cited_title":"Integrating Multimedia Appl ications in Hard Real-Time Systems,","cited_arxiv_id":null,"evidence_quote":"Describes the Constant Bandwidth Server that underpins Linux SCHED_DEADLINE, the mechanism by which Linux-side tuned-pipe tasks receive CPU reservations."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Identifies ACRN, the partitioning hypervisor used in the comparison experiments that Boomerang outperforms."}],"review_version":1}