On 26.08.2025 20:07, Dmytro Prokopchuk1 wrote: > The situation with functions gicv3_do_LPI(), > gicv3_its_setup_collection() and config CONFIG_HAS_ITS is little bit > different. > The compiler can do DCE in case when config CONFIG_HAS_ITS is "y", and > Misra R2.1 violation related to these functions also can be resolved. > Actually, no changes in source code need for that. > But Eclair detects these violations because config CONFIG_HAS_ITS is > "n", and source code is really compiled with inline stub functions (with > BUG() macro). > This is because config CONFIG_HAS_ITS is "experimental/unsupported" > > config HAS_ITS > bool "GICv3 ITS MSI controller support (UNSUPPORTED)" if > UNSUPPORTED > depends on GICV3 && !NEW_VGIC && !ARM_32 > > and to enable it need to set additional config: "CONFIG_UNSUPPORTED=y". > > I tried to test it (added "CONFIG_UNSUPPORTED=y" into > automation/gitlab-ci/analyze.yaml file). You can see my CI pipeline: > https://eclair-analysis-logs.xenproject.org/fs/var/local/eclair/xen-project.ecdf/xen-project/people/dimaprkp4k/xen/ECLAIR_normal/rule_2.1_gicv3_its_host_has_its_v2/ARM64/11144854092/PROJECT.ecd;/by_service.html#service&kind > > Unfortunately, I observed +6 new violations with that additional config > "CONFIG_UNSUPPORTED=y". > > I don't know how and why these EXTRA_XEN_CONFIG were selected in the > file 'automation/gitlab-ci/analyze.yaml'. And are we able to add new > configs here ?....
This has been a repeated source for discussion. The present selection, afaict, is pretty arbitrary. However, in your considerations on how to address an issue, imo you should not look at the present config. Whatever the solution would better fit all possible settings. Jan
