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.

Dear Bauza, Mooney Following up on our discussion during the Weekly Meeting on 2028-01-25 ([1] 16:31:58~) about Arm CCA merging, I'd appreciate your confirmation on a couple of points. The relevant portion of the meeting minutes is included below:

16:35:46 <bauzas> if specific hardware can't be tested on upstream CI, then there are two possibilities : 16:36:35 <bauzas> 1/ either you're able to test nova against fake hardware that reproduces the hardware behaviour 16:36:49 <bauzas> 2/ or you have to provide third-party CI 16:38:37 <sean-k-mooney> while 2 is preferd it much more overhead btu actull tests that the feature works end to end ... 16:44:54 <bauzas> but I strongly suggest you to invest a bit of your time into providing a testing kernel framework that could mock any specific hardware

Following the above comments, I've investigated the tests that can be provided within nova. My proposal and a question are outlined below. Could you please confirm the following? 1. My proposed testing strategy for unreleased hardware We understand that nova's testing framework provides mechanisms to mock kernel functions such as libvirt(using fakelibvirt), kernel files, and so on. However, end-to-end testing, including Arm CCA-enabled hardware emulation, cannot be fully achieved solely within nova. Therefore, to submit end-to-end tests before the hardware release, we will utilize QEMU driver with Arm CCA enabled [2] (The development for CCA is in development now). E2e tests will be executed on these Arm CCA-enabled VMs. I will be able to submit e2e test codes and results, including unit/functional tests leveraging nova's existing mechanisms like fakelibvirt. Please review this approach and provide any feedback. 2. A Question about test strategy after the hardware release The merging schedule for Arm CCA feature will be determined on the next PTG. If the merge is scheduled after the hardware release, what kind of test code and test results need to be submitted?

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.

FUJITSU-MONAKA is likely to be the first to support Arm CCA. So, we will be adding a feature targeted at the newly released hardware. Will e2e tests using the actual Arm CCA-enabled hardware be required in addition to unit/function tests? (Are tests on a hardware-emulated environment unnecessary?) [1] https://meetings.opendev.org/meetings/nova/2025/nova.2025-01-28-16.00.log.ht... [2] https://linaro.atlassian.net/wiki/spaces/QEMU/pages/29051027459/Building+an+... Regards, Taketani