Introducing ZoneX: two ThreadX kernels on one Cortex-R52, isolated in memory and in time

[fdesbiens]

ZoneX is a new Eclipse ThreadX component: a deterministic partitioning hypervisor for Armv8-R, running at EL2, giving each partition a statically declared slice of memory and of time. Phase 0 is merged and released as 0.1.0.202603, and this post records the scope decision and the deferral list that came with it.

A hypervisor appearing in the suite without a written scope invites overclaiming, so this is deliberately specific about the boundary.

ZoneX Phase 0 is a demonstrator. It is not production software and it is not close to one. It exists to establish that a small set of mechanisms work on real Armv8-R silicon, and to measure what they cost.

What Phase 0 demonstrates

Two ThreadX kernels run at EL1 on one logical Cortex-R52 core, each confined to its own stage-2 window, time-sharing the core under a static major frame taken from a manifest — on the Armv8-R AEM FVP and on the NXP S32Z280-594EVB.

Neither can read, write or execute the other's memory or the hypervisor's, and not by convention: a partition that grants itself its neighbour's memory in its own EL1 MPU is still refused by stage 2, stopped, and reported with the partition, the address and the guest PC. The other partition runs to the end of the frame with its schedule untouched — being attacked costs the neighbour nothing.

Each partition's clock advances in its own windows and in nobody else's, and a window ends whether the partition running in it agrees or not.

The temporal claim, split by cause

Nothing a partition does through the schedule reaches its neighbour. Computing, masking its own interrupts and violating its boundary without pause each move the critical partition's period by tens of counts.

What reaches it is the hypervisor's own console driver. A guest that prints moves that period by up to one line tag — 22 bytes at 115,200 8N1, 17,640 counts of the board's 8 MHz counter — every run. That is a defect in ZoneX, not a limit of the partitioning, and it is bounded, derived and reproducible.

Measured over six hundred major frames on the board, against an 800,000-count period: the neighbour idle moves it 22 counts, computing 20, computing with IRQ and FIQ both masked 24, and committing a hundred and three thousand boundary violations 185. Storming the console moves it 17,951.

The qualified claim is the one worth having. Stating the temporal result unconditionally and leaving the console out of it would have read better and would have been an overclaim that a customer's own bench would find. The defect is in the repository with its mechanism named, its cost measured and its cure scoped — and it is tracked as the next change rather than as part of a later phase, because it is far smaller than any phase and grouping it with work of a different order of magnitude is the surest way to leave the qualification standing indefinitely.

What Phase 0 does not demonstrate

Dual-core lockstep presents as one logical core, so this is temporal and memory partitioning on a single core. It is not spatial partitioning across multiple cores; that needs split-mode SMP and is deferred.

Deferred to later phases, and not attempted here:

• interrupt virtualisation with a bounded worst-case latency — interrupt latency is not measured at all in Phase 0, because guest interrupts go straight to EL1 and bounding them needs the GIC List Registers this phase does not use;
• inter-partition communication;
• the full time-partition scheduler;
• supervised partition restart — the Phase-0 policy on a violation is to report and halt, deliberately, because continuing would assert a recovery story it does not have;
• TraceX integration;
• the safety-artifact package;
• structural and MC/DC coverage of the port, which needs its own tooling. The architecture-independent core is held to a 100% line and branch floor enforced by the build; no number published for the port stands in for structural coverage of it.

Every timing figure comes from one part on one bench, with the EL2 caches off, built for debuggability rather than speed, and with no clock tree configured. They are a first measurement with its conditions stated, not characterisation across a population.

Portability, stated early because it decides a board

ZoneX's isolation is region descriptors in the EL2 MPU, and they are the scarce resource. On a Cortex-R52 the architecturally permitted EL2 region counts are 0, 16, 20 or 24. A part configured with none cannot run ZoneX at all, and there is no software fallback — on Armv8-R both stages of address control are region-based, so the region MPU is the only memory control there is.

This board has 20, of which ZoneX spends 2 on its own MMIO, because the console and the interrupt controller both fall in the background map's Normal write-through band rather than the Device band. On the fixed virtual platform both sit in the Device band and cost nothing, so the model cannot show you this constraint — and it reports 32 regions, which is not a legal Cortex-R52 value at either stage. A green model run is not evidence about a real part's region budget.

Where the evidence is

• docs/phase-0-evidence.md — the claim, the six-phase silicon run it rests on, the numbers with their conditions, the eleven builds that must fail, and what the measurements de-risk. The place to start.
• docs/decisions.md — every design decision and why it was taken, including the ones measurement corrected.
• docs/armv8r-el2-reference.md — the verified EL2 register sheet, recording what was measured where the Cortex-R52 technical reference manual is ambiguous or contradicts itself. Three of those were consequential enough to change the code.
• docs/coverage.md — which files are held to the floor, which are not, and what stands in for the ones that are not.
• docs/errata.md — the errata sweep, at stated notice revisions, with the reasoning for each entry that does not apply rather than only the conclusion.
• docs/wcet-inputs.md — every data-dependent path on the switch and trap paths, as input to worst-case-execution-time work.
• docs/misra-deviations.md — the deviation index: eighteen sites across seven rules, all in the port, the board support or the examples bar two.

Where the code is

Released: Eclipse ThreadX ZoneX v0.1.0.202603, whose notes carry the requirements, the build instructions and the known issues.

It landed through eclipse-threadx/zonex#5, whose description is the long form of this post if you want the engineering detail rather than the scope. The documentation-site pages are still in review: eclipse-threadx/rtos-docs-asciidoc#59.

And one gap recorded rather than glossed: the model-execution lane builds every image and executes none, because the fixed virtual platform is not available on a hosted runner. So continuous integration currently demonstrates that ZoneX compiles under four toolchains and that the repository checks pass — it does not demonstrate that an image runs. That evidence exists and comes from a workstation and a development board rather than from CI. See eclipse-threadx/zonex#6, and eclipse-threadx/threadx#712 for the same gap in the Cortex-R52 port.

Questions are welcome here, and review of the documentation pages on the pull request above.