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.
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.