On 27/05/2025 09:44, taketani.ryo@fujitsu.com wrote:
Hi, all.
Here are the expected release schedules for key Arm CCA software components:
* Linux Kernel: 2025/12 * This is mentioned in Arm CCA roadmap [1] * QEMU: 2026/02 * libvirt: 2026/03 * These are awaiting Linux Kernel release. The anticipated schedule is based on the Linux Kernel roadmap and the release cycles of QEMU and libvirt. * OS Distribution(Ubuntu 26.04): 2026/04 * Ubuntu xx.xx is expected to be released in alignment with the latest Linux Kernel release.
based on that timeline the earliest release of openstack that would have support for this would be 2026.2 releasing in October 2026 you can however start setting up third party testing and and testing before all of the component are available in ubuntu for example in your ci you could use a custom vm image based on ubuntu/debian that has a mainline kernel with the supprot and qemu/libvirt compileed form source or usign a ppa version. you are free to use other distos for third party ci too, although goign too far form the common distros will liekly create more overhead. currently opendev ci has limit arm hardware so its unlikely that we will be able to do 1st party integration testing now or in the future.
Our goal is to merge Arm CCA feature shortly after all necessary conditions are met.
Therefore, I'd like to propose a discussion about how to best provide the required test environment. Specifically, should we provide real hardware and a CI/CD environment? If so, we should start preparing as soon as possible.
Is it possible to begin this discussion now? If not, what do you think we should do to keep this discussion moving forward?
you can start the discussion the one think i will say is that its unlikely that many will have time to implement this for you so you and your team will have to take lead on doing the work to run the third party ci on your own hardware and make the results available puhlicly. in general as a community we use zuul for ci as our test runner. zull uses nodepool to provide test test host to run the josb on nodepool support sever types of provides like openstack cloud or kubernetes cluster. in your case since you want toe test a hardware feature that likely cannot be emulated? the simplest way to do that would be with static nodes added to your local nodepool instance which can then be used by zuul to execute jobs. if you already have an internal jenkins system with your own provisioning system you can use that instead to set up the ci. as a third party ci provide you have the freedom to define how that ci runs. if runnng a third party ci is too much overhead but you were willing to donate test hardwre to the first party ci that may also be an option but that would need discusion with the openstack/opendev infra team.
Regards,
Ryo Taketani
[1] https://lists.trustedfirmware.org/archives/list/tsc@lists.trustedfirmware.or...