What happens today
zx_fvp.yml builds every Cortex-R52 image and then executes none of them, because the Armv8-R AEM Fixed Virtual Platform is not present on a GitHub-hosted runner. The workflow takes a download location from the FVP_AEMV8R_URL repository variable; that variable is unset, so the lane emits a warning, writes ### ZoneX FVP execution: SKIPPED to the job summary, and exits zero.
That is the designed behaviour: the four build lanes still gate every pull request, and the skip is loud rather than silent. But the consequence is worth stating plainly.
CI proves that ZoneX compiles under four toolchains and that the repository checks pass. It does not prove that a single ZoneX image runs.
Why that is the gap that matters here
Every claim ZoneX makes is behavioural. A partition is denied its neighbour's memory even after granting itself that memory in its own EL1 MPU. A window ends on time whether the partition agrees or not. A guest's clock advances inside its own window and nowhere else. None of those has a static equivalent, which is why the suite is shaped the way it is: each image judges itself and reports a verdict, 14 registration sites produce 24 tests, and several of those are builds that must fail on the one check they were written to violate. A build that starts passing is a suite failure.
A compile exercises none of that. There is no static check for "the partition still runs".
Today the model suite and the silicon matrix are run by hand before anything lands, and the results are recorded with their logs. That is what the project's published measurements rest on. It does not scale to a contributor who has neither the model nor a development board, and it means a behavioural regression is caught by a person rather than by CI.
Why the download-URL route has not closed it
Arm distributes the AEM FVP free of charge, but behind a click-through licence and with no stable unauthenticated download URL. Setting FVP_AEMV8R_URL therefore means either publishing a redistribution of Arm's archive somewhere a runner can reach, or pointing at a URL that will rot. The first is a redistribution question for the Foundation rather than a technical one for this project; the second reintroduces the fragility the variable exists to avoid.
What is being pursued
A Foundation-hosted runner with the model installed. Requested: eclipsefdn/helpdesk#7864. Raised through the Foundation's infrastructure channel rather than solved inside this repository. A model already present on a persistent runner needs no download URL at all, which removes the redistribution question from the critical path instead of answering it. A Foundation-hosted mirror that FVP_AEMV8R_URL could point at would close the gap equally well.
Deliberately not pursued: a runner maintained by the project. It would be a single point of failure attached to whichever contributor owns a development board, and GitHub advises against self-hosted runners on public repositories for good reason — a pull request from a fork can change the workflow it runs, and every pull request this repository has had came from a fork. That isolation duty belongs with infrastructure that is somebody's job.
This issue exists to record the gap and to be the thing a reviewer can read when they see five green checks and wonder what the green covers. The same gap exists for the ThreadX Cortex-R52 port, which ships its own model runner that CI never invokes, and one runner would serve both.
What closing it looks like
- The execution lane runs the images and reports each one's self-declared verdict.
- The negative builds still fail the suite when they pass, which is the property that makes the positive results evidence rather than decoration.
- The skip path stays, so a contributor without the model and a fork without runner access still get the build lanes rather than a red cross they cannot act on.
- Execution is constrained to whatever trigger the isolation model requires —
push to dev and main is sufficient and is what will be asked for first.
CONTRIBUTING.md's continuous-integration section is updated, since it currently describes five workflows all running on GitHub-hosted runners.
What happens today
zx_fvp.ymlbuilds every Cortex-R52 image and then executes none of them, because the Armv8-R AEM Fixed Virtual Platform is not present on a GitHub-hosted runner. The workflow takes a download location from theFVP_AEMV8R_URLrepository variable; that variable is unset, so the lane emits a warning, writes### ZoneX FVP execution: SKIPPEDto the job summary, and exits zero.That is the designed behaviour: the four build lanes still gate every pull request, and the skip is loud rather than silent. But the consequence is worth stating plainly.
CI proves that ZoneX compiles under four toolchains and that the repository checks pass. It does not prove that a single ZoneX image runs.
Why that is the gap that matters here
Every claim ZoneX makes is behavioural. A partition is denied its neighbour's memory even after granting itself that memory in its own EL1 MPU. A window ends on time whether the partition agrees or not. A guest's clock advances inside its own window and nowhere else. None of those has a static equivalent, which is why the suite is shaped the way it is: each image judges itself and reports a verdict, 14 registration sites produce 24 tests, and several of those are builds that must fail on the one check they were written to violate. A build that starts passing is a suite failure.
A compile exercises none of that. There is no static check for "the partition still runs".
Today the model suite and the silicon matrix are run by hand before anything lands, and the results are recorded with their logs. That is what the project's published measurements rest on. It does not scale to a contributor who has neither the model nor a development board, and it means a behavioural regression is caught by a person rather than by CI.
Why the download-URL route has not closed it
Arm distributes the AEM FVP free of charge, but behind a click-through licence and with no stable unauthenticated download URL. Setting
FVP_AEMV8R_URLtherefore means either publishing a redistribution of Arm's archive somewhere a runner can reach, or pointing at a URL that will rot. The first is a redistribution question for the Foundation rather than a technical one for this project; the second reintroduces the fragility the variable exists to avoid.What is being pursued
A Foundation-hosted runner with the model installed. Requested: eclipsefdn/helpdesk#7864. Raised through the Foundation's infrastructure channel rather than solved inside this repository. A model already present on a persistent runner needs no download URL at all, which removes the redistribution question from the critical path instead of answering it. A Foundation-hosted mirror that
FVP_AEMV8R_URLcould point at would close the gap equally well.Deliberately not pursued: a runner maintained by the project. It would be a single point of failure attached to whichever contributor owns a development board, and GitHub advises against self-hosted runners on public repositories for good reason — a pull request from a fork can change the workflow it runs, and every pull request this repository has had came from a fork. That isolation duty belongs with infrastructure that is somebody's job.
This issue exists to record the gap and to be the thing a reviewer can read when they see five green checks and wonder what the green covers. The same gap exists for the ThreadX Cortex-R52 port, which ships its own model runner that CI never invokes, and one runner would serve both.
What closing it looks like
pushtodevandmainis sufficient and is what will be asked for first.CONTRIBUTING.md's continuous-integration section is updated, since it currently describes five workflows all running on GitHub-hosted runners.