Hi Sean, Thanks for your detailed explanation (as always !). I wasn't aware full context about the past development of SEV support and it helps me understand the situation more clearly. So based on your feedback I think what we can agree with at this point would be - The feature can be merged once a real hardware is available and the code is tested with it - Setting up 3rd party CI is not a strict blocker if the following items are provided - A developer guide to reproduce the setup is provided so that cores can set up a virtual environment with devstack + tempest to try/test the feature - A documentation which clearly states that the feature is "experimental" due to its limited testing but is required to mark the feature full-support. but let me know if you misunderstand your intention. Thank you, Takashi On 6/20/25 4:13 AM, Sean Mooney wrote:
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