On 19/06/2025 17:05, Takashi Kajinami wrote:
I wonder if we can apply the same policies which we agreed with for AMD SEV or SEV-ES.
- All required features have been implemented in kernel/qemu/libvirt (or any other dependent software) and we know exactly what should be checked/configured by nova (from documentations).
- Do not require 3rd party CI due to limited availability of hardware
- Require functional tests with fake libvirt driver (and a few more mocks) which simulates the behavior of kernel/qemu/libvirt with ARM-CCA features enabled.
- Actual functionality with actual hardware(*1) needs to be tested locally by the developer
IIUC this was one of the suggestions bausas mentioned when this topic was first discussed in the past nova meeting (If I understand what he means by "fake hardware") and I didn't find actual specific concern discussed to make third party CI a strict blocker.
for SEV we found actul hardware in redaht to allow core developer to test it too before it was merged we have required testing on real hardware in the past awith actual resutl published for review before. and we did not accpent nabeling intel PMEM feature until there was actul hardware aviabel in the market that supprot it. so we may be able to proceed without a third party ci but i dont think we should proceed until the hardware existi and the testing is doen at least manually onece on the real hardware. without third party ci i also think we would want to conditioner it somewhat experimental. that does not mean jumping though any hoops to be able to use the feature jsut a warnign in the docs that this feature has very limtied testing an that upsream has a limited ablity to fix any bugs that are found. this would make the feature similar to the ablity to emulate diffent arcitreus with qemu i.e. run arm vms on x86 hosts. its aviabel to use but not recommend for production workloads. its intend mainly for CI workloads or devleoper envionment.
I know that having CI which can actually test the functionality is preferred but as you was mentioned earlier it may require a lot of overheads.
[1] https://meetings.opendev.org/meetings/nova/2025/nova.2025-01-28-16.00.log.ht...
(*1) Note that actual CPU with ARM CCA feature is not currently available. All development of ARM CCA support features in kernel/qemu/libvirt use a simulated CPU (which is actually a emulated CPU provided by forked QEMU) and the initial development in OpenStack may follow the same approach.
ya so the actul hardware need to be avaible to merge the supprot in nova. we can use qemu to do the deveopemrnt befor that btu to actully supprot ti the hard ware must exist and be aviabel to buy. it can just exiist in an internal lab soemwhere. also with regards to using qemu if we are merging this withotu thrid party ci i would expect a full writeup in the contibutor docs of how to recplicate a qemu vm that you can install devstack in using ubuntu/debin and run tempest to validate teh feature. similar to https://docs.openstack.org/nova/latest/contributor/testing/pci-passthrough-s... and the other testing guides https://docs.openstack.org/nova/latest/contributor/index.html#testing like this https://docs.openstack.org/nova/latest/contributor/testing/libvirt-numa.html if the core team does nto have a way to replciate and debug a bug i dont think we could really supprot it beyond an experimental capastiy.
On 6/18/25 7:03 PM, taketani.ryo@fujitsu.com wrote:
Hi all and Sean,
Is the ultimate goal to store CI test results from real hardware running upstream versions of OS/libvirt/QEMU/LinuxKernel, and will approval of those results be required for merging?
I apologize for the lack of clarity in my previous question. I'd like to rephrase and clarify my question.
For merging and releasing the nova CCA code, is it mandatory to have Third Party CI running on bare metal (non-emulated) environments? Or is Third Party CI on emulated environments also acceptable?
Furthermore, how long should the Third-Party environment be maintained? Are there any policies (e.g., "X number of years after the CCA feature is released")?
Regards, Ryo Taketani