DAAT-MCS: A Framework to Deploy, Analyse, and Auto-Tune Interference Mitigation Techniques in Mixed-Criticality Systems

The compile-time stage is driven by a YAML specification describing workload setups, guest variants, and hypervisor control parameters. The framework supports multiple setup types, including standalone VMs and co-running VM scenarios, together with cache-coloring configuration and profiling utilities. When cache coloring is enabled without an explicit configuration list, the framework enumerates valid LLC partitions for the VMs in each setup under user-defined constraints. For each resulting $(\mathrm{𝗌𝖾𝗍𝗎𝗉},c)$ pair, it generates the corresponding hypervisor configuration and builds the required artifacts, namely the guest and hypervisor images. Although our prototype targets the Bao hypervisor, this stage is designed to remain largely hypervisor-agnostic and may generalize to other SPHs.

The run-time stage iterates over the generated images, flashes the target board, boots the system, and collects the exported traces and execution logs. To support unattended campaigns over many $(\mathrm{𝗌𝖾𝗍𝗎𝗉},c)$ pairs, failed runs trigger a bounded reset-and-retry procedure.

Figure 3 illustrates the run-time workflow. The profiler runs on a designated master core and can be enabled or disabled at boot; when profiling is disabled, this core can be assigned to a workload VM. Thus, dedicating one core to the profiler is a profiling-time design choice that simplifies orchestration and trace collection, rather than a requirement of the final deployed system. In the current implementation, the profiler runs on a lightweight Linux OS; however, the design only requires connectivity for trace export and does not depend on Linux-specific services, so it can be ported to a smaller runtime OS, e.g., Zephyr, to reduce footprint and boot time. When profiling is enabled, the hypervisor boots the profiler first and stalls the remaining cores until it reports readiness ①. Once the profiler is ready, the remaining cores boot their VMs and, after the guest OSes reach a steady state, each core issues a CPU_READY hypercall ②, which acts as a global synchronization barrier. The profiling session starts only after all participating VMs have reached this barrier ③, preventing boot activity from contaminating ${𝒯}_p(c)$. During profiling, each VM issues PROFILE_SET_CHECKPOINT hypercalls at developer-selected points in the workload, e.g., per iteration, at phase boundaries, or upon request completion. In Figure 3, these checkpoints appear as “Set Checkpoint” events on the non-master core timelines. Each checkpoint notifies the profiler, and the master core asynchronously records the corresponding timestamp in a per-core buffer, keeping guest-side overhead low and predictable. The session ends with a PROFILE_STOP hypercall ④, which finalizes the buffers and triggers export of the traces to the host framework ⑤. Figure 3 also shows the common case in which a designated VM, e.g., the critical one, determines when to stop profiling.

To ensure cross-configuration comparability of activity-based metrics, the profiling session follows a fixed termination policy. In our experiments, the designated high-criticality VM issues PROFILE_STOP only after completing a fixed, configuration-independent amount of work, e.g., a fixed benchmark segment or a fixed number of iterations. Because the stop condition is work-based rather than time-based, session duration may vary across configurations, e.g., due to different interference levels affecting the critical VM’s completion time. Accordingly, for non-critical VMs, the checkpoint count $K_p(c)$ should be interpreted as the amount of background work completed during the execution window of the designated high-criticality VM, rather than as absolute throughput over a fixed wall-clock interval; equivalently, it captures best-effort progress during that fixed-work execution window. Alternatively, the same mechanism can require all participating VMs to issue PROFILE_STOP before ending the session. In both cases, the framework produces a consistent set of per-core checkpoint traces ${𝒯}_p(c)$ for each evaluated configuration $c\in 𝒞$. The current workflow characterizes the finite scenario set explicitly described in the campaign specification; it does not exhaustively enumerate all asynchronous phasings, event arrivals, or input-dependent execution paths. Therefore, the resulting traces should be interpreted as empirical evidence for the profiled scenarios, not as an exhaustive characterization of all possible executions.

In the current implementation, DAAT-MCS does not perform online search over an implicit combinatorial space. Instead, it operates on a finite candidate set $𝒞$ generated offline by the profiling workflow described in Section 3, where each $c\in 𝒞$ denotes one complete system-wide cache-color assignment across the participating workloads/cores and has already been deployed and measured on real hardware. Therefore, the contribution of the tuner in this paper is not a heuristic search strategy, but a deterministic measurement-driven selection step that maps the enumerated set $𝒞$ into the subset ${𝒞}_{\mathrm{acc}}$ of system-wide acceptable cache partitions. This distinction is important because the tuner itself performs filtering, classification, and ranking over measured candidates, while scalability at the full-system level is primarily determined by the offline profiling campaign required to populate $𝒞$.

We denote by $𝒞$ the set of cache-coloring configurations under evaluation. For each configuration $c\in 𝒞$ and each CPU $p\in 𝒫$, we profile execution by tracing workload checkpoints to produce a duration sequence ${𝒯}_p(c)=\{t_{p,1}(c),t_{p,2}(c),\mathrm{\dots },t_{p,N_p(c)}(c)\},$ where each $t_{p,i}(c)$ is the measured duration of the $i$-th profiling interval on core $p$ under configuration $c$, and $N_p(c)$ is the number of checkpoints observed. From this sequence, the tuner derives scalar metrics such as

where $K_p(c)$ captures activity (checkpoint count) while $T_p(c)$ captures the total profiled time in kcycles. The factor ${10}^3$ is a unit-conversion constant used only to express the accumulated duration in kcycles rather than cycles; it keeps the reported values compact in tables and figures, but does not affect ranking, degradation, or acceptability because all comparisons are performed after consistent normalization.

As described in Section 3, when the profiling session is terminated by a designated high-criticality VM after completing a fixed, configuration-independent amount of work, $K_p(c)$ for non-critical workloads should be interpreted as progress achieved during that execution window, rather than as absolute throughput over a fixed wall-clock interval. The tuner then selects a single score metric $S_p(c)$ per core and configuration based on workload criticality. Lower $S_p(c)$ is better for higher-criticality workloads, whereas higher $S_p(c)$ is better for lower-criticality workloads.

DAAT-MCS is agnostic to the specific scalar score $S_p(c)$ as long as it preserves a total order of configurations for each core $p$. While this work instantiates $S_p(c)$ using total profiled time $T_p(c)$ for higher-criticality cores and activity $K_p(c)$ for lower-criticality cores, the same tuning logic also supports real-time-oriented objectives derived from ${𝒯}_p(c)$, such as the worst-case observed interval $W_p(c)={\max }_i{t}_{p,i}(c),$ a tail-oriented metric such as $Q_p(c)=\mathrm{p99}({𝒯}_p(c)),$ or a deadline-miss ratio when checkpoints correspond to jobs with deadlines. In this sense, the tuner separates (i) the collection of empirical traces from (ii) the symbolic selection policy, enabling alternative timing objectives without changing the underlying feasibility reasoning.

Given a chosen score $S_p(c)$, the tuner establishes a per-core relative baseline by selecting a baseline configuration $c_p^{\star }$ and value $B_p^{\mathrm{rel}}$: For higher-criticality cores, $c_p^{\star }$ yields the best observed timing under $S_p$; for lower-criticality cores, it yields the highest observed activity. By default, DAAT-MCS normalizes degradation to $B_p^{\mathrm{rel}}$, i.e., the best configuration within the evaluated candidate set $𝒞$. This makes the tuner rank and filter feasible partitions relative to the best observed profiled candidate, rather than relative to solo execution. When an absolute reference is required, the same formulation can be instantiated with an isolation baseline $B_p^{\mathrm{iso}}$ obtained from standalone execution of workload $p$ without co-runners. The tuning logic itself remains unchanged; only the reference used to compute degradation differs. In the rest of this section, we use the relative baseline unless otherwise stated.

Using the relative baseline, the tuner computes a degradation factor for each configuration $c$ and core $p$:

When an isolation baseline is available, the same form yields $is{o}_p(c)$ by replacing $B_p^{\mathrm{rel}}$ with $B_p^{\mathrm{iso}}$. For higher-criticality workloads, $re{l}_p(c)$ is the percentage slowdown from the baseline; for lower-criticality workloads, it is the percentage activity reduction from the baseline.

Given the measured candidate set $𝒞$, the tuner applies the following deterministic steps: (1) select the score $S_p(c)$ for each core $p$; (2) compute the per-core baseline $B_p^{\mathrm{rel}}$ and baseline configuration $c_p^{\star }$; (3) evaluate $re{l}_p(c)$ for every $p\in 𝒫$ and $c\in 𝒞$; (4) classify each pair $(p,c)$ into tolerance regions; (5) intersect the acceptable per-core candidate sets to obtain ${𝒞}_{\mathrm{acc}}$; and (6) if multiple feasible configurations remain, rank them according to a deterministic secondary criterion. This makes explicit that DAAT-MCS is a measurement-driven filtering and ranking stage over an already enumerated set of candidates, rather than a search heuristic over unmeasured configurations.

DAAT-MCS treats each configuration $c$ as a point in a per-core degradation space, with one degradation value for each core $p$. Tolerances are needed because, in a shared-resource setting, insisting that every workload match its per-core best observed baseline exactly would often eliminate otherwise deployable system-wide configurations; instead, the user specifies how much degradation each workload may tolerate according to its criticality. This also lets the framework represent asymmetric requirements, e.g., tight slowdown bounds for higher-criticality workloads and looser progress-loss bounds for lower-criticality ones. We additionally define a near-tolerance slack factor $\alpha >1$ that controls the width of the near-tolerance region. In this work, and in the toy example below, we use $\alpha =1.2$, such that degradations up to $20\%$ above the baseline tolerance are labeled as near tolerance. Formally,

System-wide acceptable configurations are then obtained by intersecting the acceptable per-core sets and discarding any configuration that violates the policy on at least one core:

This produces a set of configurations whose performance remains sufficiently close to each workload’s baseline behavior, while still allowing a controlled relaxation through class 1. The same decision logic can be interpreted as a deterministic pruning tree, in which per-core constraints are applied sequentially and any configuration classified as class 2 for one core is removed from further consideration. If multiple feasible configurations remain after constraint intersection, DAAT-MCS ranks them using two ordered criteria. First, it prefers configurations with fewer cores in the near-tolerance region, i.e., fewer cores for which ${\mathrm{𝑐𝑙𝑎𝑠𝑠}}_p(c)=1$. Second, among configurations with the same number of near-tolerance cores, it prefers the one with the lowest aggregate degradation, ${\sum }_{p\in 𝒫}re{l}_p(c)$. where $n_1(c)$ denotes the number of cores classified as near tolerance. Thus, the first term is the primary ranking criterion and the second term is used only to break ties. If a higher-criticality workload already meets its deadlines for all candidates, the tuner does not attempt to “optimize past” that external requirement; rather, it still filters and ranks configurations according to the user-specified tolerance policy, or, when desired, the score $S_p(c)$ can be instantiated directly with a deadline-oriented metric.

To make this concrete, consider a two-core system $𝒫=\{p_0,p_1\}$ with one higher-criticality core $p_0$ and one lower-criticality core $p_1$. We evaluate four cache-color configurations $𝒞=\{c_1,c_2,c_3,c_4\}$, each assigning a different fraction of LLC colors to each core. We set tolerances to ${\tau }_0=5\%$ for the critical workload and ${\tau }_1=30\%$ for the non-critical workload, and use $\alpha =1.2$. Table 2 reports the raw per-core scores $S_p(c)$, the derived degradations $re{l}_p(c)$, the corresponding classes ${\mathrm{𝑐𝑙𝑎𝑠𝑠}}_p(c)$, and the final acceptability outcome.

For each configuration $c$, the tuner computes a per-core score $S_p(c)$ based on workload criticality: the critical core uses $S_0(c)=T_0(c)$ (execution time in kcycles, lower is better), while the non-critical core uses $S_1(c)=K_1(c)$ (checkpoint count, higher is better). The tuner then establishes per-core baselines over $𝒞$ only: $c_0^{\star }=\arg {\min }_{c\in 𝒞}{T}_0(c)$ with $B_0^{\mathrm{rel}}=T_0(c_0^{\star })=100$ (here, $c_2$), and $c_1^{\star }=\arg {\max }_{c\in 𝒞}{K}_1(c)$ with $B_1^{\mathrm{rel}}=K_1(c_1^{\star })=90$ (here, $c_4$).

Given the baselines $B_p^{\mathrm{rel}}$, the tuner converts raw scores into relative degradations $re{l}_p(c)$. For the critical core, $re{l}_0(c)=100\cdot \frac{T_0(c)-B_0^{\mathrm{rel}}}{B_0^{\mathrm{rel}}}$ (slowdown from the best observed time); for the non-critical core, $re{l}_1(c)=100\cdot \frac{B_1^{\mathrm{rel}}-K_1(c)}{B_1^{\mathrm{rel}}}$ (activity loss from the best observed checkpoint count). In this example, $p_0$ observes $re{l}_0(c_1)=20\%$, $re{l}_0(c_3)=6\%$, and $re{l}_0(c_4)=30\%$, while $p_1$ observes $re{l}_1(c_1)=44.4\%$, $re{l}_1(c_2)=11.1\%$, and $re{l}_1(c_3)=33.3\%$.

Finally, the tuner applies the tolerance policy to label each configuration: class 0 if $re{l}_p(c)\le {\tau }_p$, class 1 if , and class 2 otherwise. A configuration is acceptable only if it is not an outlier for any core, i.e., ${\mathrm{𝑐𝑙𝑎𝑠𝑠}}_p(c)\in \{0,1\}$ for all $p$. For $p_0$, with ${\tau }_0=5\%$ and $\alpha =1.2$, the near-tolerance threshold is $6\%$, so only $c_2$ and $c_3$ remain feasible, while $c_1$ and $c_4$ are rejected (class 2). For $p_1$ ($\alpha {\tau }_1=36\%$), $c_2$ and $c_4$ fall into class 0, $c_3$ falls into class 1, and only $c_1$ is rejected (class 2). Intersecting both per-core feasible sets therefore yields ${𝒞}_{\mathrm{acc}}=\{c_2,c_3\}$.

Our evaluation targets a specific SPH; however, DAAT-MCS is not tied to Bao’s internal design and can be adapted to other SPHs (e.g., Jailhouse). In practice, porting DAAT-MCS to a different SPH requires only two integration points: (i) implementing the guest-to-monitor instrumentation interface used by the profiler (i.e., the hypercall handlers for session start/stop and checkpoint setup, as described in Section 3); and (ii) extending the configuration back-end to generate the corresponding hypervisor configuration artifacts (e.g., VM descriptions and cache-partition assignments in the target SPH’s format, when using an hypervisor). More broadly, the same measurement-and-selection pipeline can be deployed without a hypervisor by integrating instrumentation and enforcement into the OS kernel; for example, prior work such as MemGuard [49] follows this paradigm for memory-bandwidth reservation within the Linux kernel.

The current work focuses primarily on LLC cache coloring (altough the framework also supports memory-bandwidth regulation), but modern high-end embedded platforms increasingly expose additional mechanisms (e.g., Arm QoS regulators and standardized partitioning/monitoring interfaces such as Arm MPAM). These mechanisms are complementary to cache coloring because they can bound contention that manifests beyond the LLC [51], which cache partitioning per se cannot directly regulate. Crucially, extending DAAT-MCS to such mechanisms does not require changing the core auto-tuning logic (tolerance classification plus system-wide feasibility intersection); instead, it requires extending the configuration space definition and generation pipeline so that (i) the new mechanism parameters are described in the framework’s input specification, (ii) candidate configurations enumerating those parameters are generated, and (iii) those candidates are compiled/deployed by the corresponding back-end (hypervisor configuration generation when using an SPH, or kernel configuration hooks when operating at OS level).

The current implementation dedicates one CPU core to a Linux-based control VM that coordinates profiling, reducing the number of cores available for workload consolidation from 4 to 3 on the quad-core Xilinx UltraScale+ ZCU104. In addition, the Linux VM increases the profiling image size due to the guest kernel and userspace tooling. These trade-offs can be mitigated through two orthogonal directions: (i) offloading profiling coordination to auxiliary platform components (e.g., FPGA fabric or an auxiliary cluster when available), removing persistent CPU dedication while preserving hypervisor mediation; or (ii) replacing the always-on control VM with a minimal “profile-then-run” workflow in which the profiler executes briefly at the beginning and end of the experiment to synchronize, collect, and export traces, requiring only two hypervisor transitions per profiling cycle while preserving full core availability for production deployments.

Short-term extensions will address current limitations by (i) offloading profiling coordination to external platform resources (e.g., RPU and/or FPGA fabric) to avoid dedicating a CPU core, (ii) supporting VM stacking with minimal context switches to further reduce trace-collection overhead, and (iii) integrating additional interference mitigation mechanisms (e.g., QoS regulators) into the same tolerance-guided workflow. Future work also encompasses the improvement of performance characterization by complementing (or replacing) user-defined checkpoints with PMU-based monitoring (e.g., cache misses and memory stalls), providing richer workload information for tolerance classification.

Several frameworks and tools have been proposed to systematically create interference scenarios, measure slowdowns, and support integration-time decision making on real hardware. RT-Bench provides an extensible benchmark framework for real-time experimentation by attaching task semantics (e.g., periods and deadlines) to co-scheduled workloads [32]. FrATM2 automates microbenchmark generation under diverse contention scenarios and learns memory-subsystem timing models that can be leveraged by response-time analysis [43]. SP-IMPact provides an open-source workflow to deploy VM configurations on static-partitioning hypervisors and assess the impact of mitigation techniques such as cache coloring and memory-bandwidth reservation under consolidation [13]. At the tooling level, RapiDaemons and MinervaSys Architect provide stress/inference generation and inspection capabilities to expose interference paths and assess mitigation impact [46, 45]. Beyond hypervisor-centered workflows, Dasari et al. propose a framework to compute memory-contention bounds under shared-bus arbitration assumptions [14], and Oliveira et al. provide an empirical framework to quantify contention on low-end multi-core microcontrollers [33]. In the cache domain, Mancuso et al. present a real-time cache-management framework that uses page coloring to control cache-set usage and reason about timing impact [26]. Finally, MEMSCOPE provides an open-source, kernel-level framework to characterize heterogeneous memory subsystems under controlled contention, enabling precise measurement of latency/bandwidth behavior and interference effects at the OS level [16].

A second line of work focuses on mitigation mechanisms and on configuration/allocation strategies that bound interference under mixed-criticality constraints. In the cache domain, works study cache partitioning, cache-aware virtualization, and cache-centric isolation (e.g., page-coloring-based management and cache DoS prevention) [26, 6]. In the memory domain, extensive research addresses bandwidth regulation and memory-system control across different enforcement models: OS-level regulators (e.g., MemGuard and subsequent bandwidth-management systems), external/polling-based policing (e.g., MemPol), and studies of regulation dynamics and platform-specific constraints (e.g., DynamIQ/DSU-oriented regulators) [49, 50, 52, 2, 41, 36]. Complementary approaches target specific bottlenecks and heterogeneity, including QoS-enabled accelerator/CPU bandwidth management, programmable-logic-assisted memory scheduling infrastructures, and hardware support for contention tracking in shared caches [42, 20, 5]. Finally, prediction and virtualization-oriented techniques complement pure regulation by either anticipating interference at runtime or strengthening isolation within virtualized deployments [40, 24, 31].

Prior work has made substantial progress on (i) frameworks and tools to generate and measure interference under consolidation, and (ii) analytical or learned models that explain or predict contention-induced slowdowns. DAAT-MCS targets a different point in the design space: it is not intended to provide new insight into interference mechanisms, nor to propose a new interference-mitigation primitive. Instead, it fills a practical gap that remains largely manual in current integration workflows: the automatic configuration of existing mitigation techniques for concrete mixed-criticality deployments under explicit, per-core degradation requirements. Concretely, given a finite candidate configuration set $𝒞$, DAAT-MCS provides an end-to-end workflow that (i) profiles each candidate on real hardware via a hypervisor-integrated checkpoint tracer and (ii) applies tolerance-guided classification plus constraint reasoning to derive ${𝒞}_{\mathrm{acc}}$, the set of system-wide feasible configurations. Compared to modeling/prediction approaches, DAAT-MCS does not seek a reusable interference model; it makes feasibility decisions directly from measured traces, thereby retaining platform- and workload-specific effects. Compared to evaluation frameworks that primarily report performance/isolation outcomes across configurations, DAAT-MCS provides a deterministic selection procedure that maps measurements into deployable configurations aligned with certification-oriented tolerance bounds, replacing ad-hoc trial-and-error with a repeatable offline step. To the best of our knowledge, no prior work provides this specific combination of hypervisor-level checkpoint profiling, tolerance-guided classification, and system-wide feasibility intersection to automatically configure interference mitigation techniques for static-partitioning mixed-criticality consolidation.