In spec there are some sections to describe the testing plan so once you propose

Technically we can start discussions in OpenStack with reference to draft libvirt API, if we have details such as xml format. However approval may be on-hold until support for Arm CCA is completed in libvirt. This is because we should avoid problems caused by the change made in libvirt AFTER design is made in nova. Also nova implements

Thank you for your response. the spec we can discuss details based on the plan described in that section. I will add the testing methodologies to the "Testing" section (and other relevant sections) of the spec before submitting it. We'll start by implementing an internal and local testing environment. the mechanism to check minimum libvirt/qemu version to use requested features and we may need to know the exact libvirt/qemu version to support CCA to complete the implementation in nova. I understand that patch approval may be on-hold until support for Arm CCA is completes in libvirt. To facilitate discussion of implementation strategies, I will submit the specifications shortly. I will add a note in blueprint and spec that underlying components like libvirt are under development, and their specifications are subject to change . Best regards,

in the past we have ask for hardware vendor to provided third party ci and commit to helping to maintain the integration going forward. we don't always require that as it can be a large ask of a new contributor. 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. you can propose the design and even start working on the implementation but we would hold merging the implementationuntil all the dependencies are met and officially publicly released. 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. if its released hardware that is just hard to get hold of because its only available in the latest generation and is expensive or otherwise not widely available provide there is enough unit/functional testing and the author of the code can provide log/test results showing the integration works that might be sufficient. i stress might since that would need wider discussion in the spec. On 27/12/2024 07:20, taketani.ryo@fujitsu.com wrote:

I submitted a spec for Arm CCA instances. In developing my spec, I drew upon aspects of the AMD-SEV ES spec. Thank you very much.

https://review.opendev.org/c/openstack/nova-specs/+/938276

im not actully back to work until monday but i did see that spec while i was off. i only skimmed it quickly but the general direction seam ok, i.e. reusign the memory_encryption_context resouce class with a new triat for the ARM CCA feature. 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. what are the minium qemu/libvirt/linux verisions? how does this impact lifecycle operation like live migration? 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? 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 regards sean.