Sean Mooney wrote:
the answer also partly comes down to exactly what unavailable hardware means.
As noted above if its unavailable because it does not exist yet in the market as a product you can buy then its to early merge the support in nova. We only hardware support for released hardware.
To our knowledge, no products currently support Arm CCA. FUJITSU-MONAKA [1], scheduled for release by Fujitsu in 2027, may be the first such product. Our goal is to have OpenStack ready for use upon the release of the first Arm CCA-supporting product. Sean Mooney wrote:
officially nova required any hardware feature to be supported in a public official release of all software dependencies.
That normally means supported by libvirt/qemu but also a released upstream kernel if driver/kernel enablement is needed.
We do not allow merging support of functionality for unreleased hardware.
We understand nova's policies. However, we would like to discuss and confirm alternatives. While no CPUs with this feature are currently on the market, It's possible to emulate the Arm hardware, including Arm CCA functionality, using a emulator like QEMU [2]. Even if Arm CCA is available in prerequisite software like qemu/libvirt/linux, and we can develop and test Arm CCA feature for OpenStack on an emulator with fixed prerequisite software stack, is there still no possibility of merging before the release of the actual hardware? We would appreciate the opportunity to share our goals and discuss a potential schedule for merge with you in a suitable meeting such as a nova weekly meeting. Sean Mooney wrote:
the main question the will need to be answer is how can we test this this end to end? for something like this unit test would not be sufficient. function tests, which are like unit test but test the interaction betwen multiple nova agents with test fixture to fake out real hardware, may be sufficient.
We acknowledge that the tests currently specified in the spec are insufficient. We will consider adding tests that simulate real hardware. Sean Mooney wrote:
what are the minium qemu/libvirt/linux verisions?
how does this impact lifecycle operation like live migration?
These are still undetermined and will be updated later. libvirt RFC for Arm CCA has just been submitted. [3] Limitations on certain lifecycle operations will apply to Arm CCA VMs. Sean Mooney wrote:
how does this interact with other features like cinder volumes? virtio-scsi? for SEV we had to add special handeling for virtio devices like the console or virtio disks to make it funciton.
does it have any other requirements to function? iommu? firmware=uefi? a specific machine type i.e. virt?
Thank you for your comments. We will verify these points and add them if necessary. Sean Mooney wrote:
realistically the spec approval deadline for this cycle is thrusday the 9th.
given that its likly too late to include in 2025.1 (epoxy) but it may make sense to start working on it for 2025.2
We submitted this to foster community discussion. However, as several key issues remain to be addressed, we must resubmit a spec for the next release cycle. # I apologize if submitting it to the 2025.1 directory was inappropriate. Regards, [1] https://www.fujitsu.com/downloads/SUPER/topics/isc24/next-arm-based-processo... [2] https://linaro.atlassian.net/wiki/spaces/QEMU/pages/29051027459/Building+an+... [3] https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/Q2AZF... Taketani