1. Patchew
  2. Xen
  3. View series

[PATCH] CI: Extend eclair-*-allcode to enable as much as possible

Andrew Cooper posted 1 patch 1 day, 19 hours ago 
automation/gitlab-ci/analyze.yaml | 45 +++++++++++++++++++++++++++++++
1 file changed, 45 insertions(+)
[PATCH] CI: Extend eclair-*-allcode to enable as much as possible
Posted by Andrew Cooper 1 day, 19 hours ago 
On x86, this is basically everything.

For ARM, CONFIG_MPU and CONFIG_MMU are mutually exclusive (with
CONFIG_STATIC_MEMORY in the mix), as well as CONFIG_NEW_VGIC being mutually
exclusive with the other VGIC infrastructure.

No functional change, but a lot of new Eclair reports (non-blocking).

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Stefano Stabellini <sstabellini@kernel.org>
CC: consulting@bugseng.com <consulting@bugseng.com>
CC: Nicola Vetrini <nicola.vetrini@bugseng.com>
CC: Jan Beulich <JBeulich@suse.com>
CC: Roger Pau Monné <roger.pau@citrix.com>
CC: Julien Grall <julien@xen.org>
CC: Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
CC: Bertrand Marquis <bertrand.marquis@arm.com>
CC: Michal Orzel <michal.orzel@amd.com>

https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/2245142422

Maintaining these lists is going to be a nightmare.  I think we really do need
to implement CONFIG_COMPILE_TEST
---
 automation/gitlab-ci/analyze.yaml | 45 +++++++++++++++++++++++++++++++
 1 file changed, 45 insertions(+)

diff --git a/automation/gitlab-ci/analyze.yaml b/automation/gitlab-ci/analyze.yaml
index a472692fcb31..7a2c0bfa77d1 100644
--- a/automation/gitlab-ci/analyze.yaml
+++ b/automation/gitlab-ci/analyze.yaml
@@ -44,6 +44,24 @@ eclair-x86_64-allcode:
     LOGFILE: "eclair-x86_64.log"
     VARIANT: "X86_64"
     RULESET: "monitored"
+    EXTRA_XEN_CONFIG: |
+      CONFIG_ARGO=y
+      CONFIG_DEBUG_LOCK_PROFILE=y
+      CONFIG_DEBUG_TRACE=y
+      CONFIG_EFI_SET_VIRTUAL_ADDRESS_MAP=y
+      CONFIG_EXPERT=y
+      CONFIG_HYPERV_GUEST=y
+      CONFIG_LATE_HWDOM=y
+      CONFIG_MEM_PAGING=y
+      CONFIG_MEM_SHARING=y
+      CONFIG_PERF_ARRAYS=y
+      CONFIG_PERF_COUNTERS=y
+      CONFIG_PV32=y
+      CONFIG_UNSUPPORTED=y
+      CONFIG_XENOPROF=y
+      CONFIG_XEN_GUEST=y
+      CONFIG_XHCI=y
+      CONFIG_XSM=y
   allow_failure: true
 
 eclair-x86_64-testing:
@@ -104,6 +122,33 @@ eclair-ARM64-allcode:
     LOGFILE: "eclair-ARM64.log"
     VARIANT: "ARM64"
     RULESET: "monitored"
+    EXTRA_XEN_CONFIG: |
+      CONFIG_ACPI=y
+      CONFIG_ARGO=y
+      CONFIG_ARM64_SVE=y
+      CONFIG_ARM_SMMU_V3=y
+      CONFIG_BOOT_TIME_CPUPOOLS=y
+      CONFIG_DEBUG_LOCK_PROFILE=y
+      CONFIG_DEBUG_TRACE=y
+      CONFIG_DEVICE_TREE_DEBUG=y
+      CONFIG_EFI_SET_VIRTUAL_ADDRESS_MAP=y
+      CONFIG_EXPERT=y
+      CONFIG_FFA=y
+      CONFIG_FFA_VM_TO_VM=y
+      CONFIG_GICV3_ESPI=y
+      CONFIG_HAS_ITS=y
+      CONFIG_IOREQ_SERVER=y
+      CONFIG_IPMMU_VMSA=y
+      CONFIG_LIVEPATCH=y
+      CONFIG_LLC_COLORING=y
+      CONFIG_OPTEE=y
+      CONFIG_OVERLAY_DTB=y
+      CONFIG_PCI_PASSTHROUGH=y
+      CONFIG_PERF_ARRAYS=y
+      CONFIG_PERF_COUNTERS=y
+      CONFIG_STACK_PROTECTOR=y
+      CONFIG_UNSUPPORTED=y
+      CONFIG_VM_EVENT=y
   allow_failure: true
 
 eclair-ARM64-testing:
-- 
2.39.5
Re: [PATCH] CI: Extend eclair-*-allcode to enable as much as possible
Posted by Jan Beulich 1 day, 17 hours ago 
On 05.01.2026 13:24, Andrew Cooper wrote:
> On x86, this is basically everything.
> 
> For ARM, CONFIG_MPU and CONFIG_MMU are mutually exclusive (with
> CONFIG_STATIC_MEMORY in the mix), as well as CONFIG_NEW_VGIC being mutually
> exclusive with the other VGIC infrastructure.
> 
> No functional change, but a lot of new Eclair reports (non-blocking).
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

What I would have wished to be clarified here is why allyesconfig isn't suitable
to use. After all that would address ...

> Maintaining these lists is going to be a nightmare.

... e.g. this concern.

Jan

>  I think we really do need
> to implement CONFIG_COMPILE_TEST
> ---
>  automation/gitlab-ci/analyze.yaml | 45 +++++++++++++++++++++++++++++++
>  1 file changed, 45 insertions(+)
> 
> diff --git a/automation/gitlab-ci/analyze.yaml b/automation/gitlab-ci/analyze.yaml
> index a472692fcb31..7a2c0bfa77d1 100644
> --- a/automation/gitlab-ci/analyze.yaml
> +++ b/automation/gitlab-ci/analyze.yaml
> @@ -44,6 +44,24 @@ eclair-x86_64-allcode:
>      LOGFILE: "eclair-x86_64.log"
>      VARIANT: "X86_64"
>      RULESET: "monitored"
> +    EXTRA_XEN_CONFIG: |
> +      CONFIG_ARGO=y
> +      CONFIG_DEBUG_LOCK_PROFILE=y
> +      CONFIG_DEBUG_TRACE=y
> +      CONFIG_EFI_SET_VIRTUAL_ADDRESS_MAP=y
> +      CONFIG_EXPERT=y
> +      CONFIG_HYPERV_GUEST=y
> +      CONFIG_LATE_HWDOM=y
> +      CONFIG_MEM_PAGING=y
> +      CONFIG_MEM_SHARING=y
> +      CONFIG_PERF_ARRAYS=y
> +      CONFIG_PERF_COUNTERS=y
> +      CONFIG_PV32=y
> +      CONFIG_UNSUPPORTED=y
> +      CONFIG_XENOPROF=y
> +      CONFIG_XEN_GUEST=y
> +      CONFIG_XHCI=y
> +      CONFIG_XSM=y
>    allow_failure: true
>  
>  eclair-x86_64-testing:
> @@ -104,6 +122,33 @@ eclair-ARM64-allcode:
>      LOGFILE: "eclair-ARM64.log"
>      VARIANT: "ARM64"
>      RULESET: "monitored"
> +    EXTRA_XEN_CONFIG: |
> +      CONFIG_ACPI=y
> +      CONFIG_ARGO=y
> +      CONFIG_ARM64_SVE=y
> +      CONFIG_ARM_SMMU_V3=y
> +      CONFIG_BOOT_TIME_CPUPOOLS=y
> +      CONFIG_DEBUG_LOCK_PROFILE=y
> +      CONFIG_DEBUG_TRACE=y
> +      CONFIG_DEVICE_TREE_DEBUG=y
> +      CONFIG_EFI_SET_VIRTUAL_ADDRESS_MAP=y
> +      CONFIG_EXPERT=y
> +      CONFIG_FFA=y
> +      CONFIG_FFA_VM_TO_VM=y
> +      CONFIG_GICV3_ESPI=y
> +      CONFIG_HAS_ITS=y
> +      CONFIG_IOREQ_SERVER=y
> +      CONFIG_IPMMU_VMSA=y
> +      CONFIG_LIVEPATCH=y
> +      CONFIG_LLC_COLORING=y
> +      CONFIG_OPTEE=y
> +      CONFIG_OVERLAY_DTB=y
> +      CONFIG_PCI_PASSTHROUGH=y
> +      CONFIG_PERF_ARRAYS=y
> +      CONFIG_PERF_COUNTERS=y
> +      CONFIG_STACK_PROTECTOR=y
> +      CONFIG_UNSUPPORTED=y
> +      CONFIG_VM_EVENT=y
>    allow_failure: true
>  
>  eclair-ARM64-testing:
ARM64 notes: Re: [PATCH] CI: Extend eclair-*-allcode to enable as much as possible
Posted by Andrew Cooper 1 day, 14 hours ago 
On 05/01/2026 12:24 pm, Andrew Cooper wrote:
>  eclair-x86_64-testing:
> @@ -104,6 +122,33 @@ eclair-ARM64-allcode:
>      LOGFILE: "eclair-ARM64.log"
>      VARIANT: "ARM64"
>      RULESET: "monitored"
> +    EXTRA_XEN_CONFIG: |
> +      CONFIG_ACPI=y
> +      CONFIG_ARGO=y
> +      CONFIG_ARM64_SVE=y
> +      CONFIG_ARM_SMMU_V3=y
> +      CONFIG_BOOT_TIME_CPUPOOLS=y
> +      CONFIG_DEBUG_LOCK_PROFILE=y
> +      CONFIG_DEBUG_TRACE=y
> +      CONFIG_DEVICE_TREE_DEBUG=y
> +      CONFIG_EFI_SET_VIRTUAL_ADDRESS_MAP=y
> +      CONFIG_EXPERT=y
> +      CONFIG_FFA=y
> +      CONFIG_FFA_VM_TO_VM=y
> +      CONFIG_GICV3_ESPI=y
> +      CONFIG_HAS_ITS=y
> +      CONFIG_IOREQ_SERVER=y
> +      CONFIG_IPMMU_VMSA=y
> +      CONFIG_LIVEPATCH=y
> +      CONFIG_LLC_COLORING=y
> +      CONFIG_OPTEE=y
> +      CONFIG_OVERLAY_DTB=y
> +      CONFIG_PCI_PASSTHROUGH=y
> +      CONFIG_PERF_ARRAYS=y
> +      CONFIG_PERF_COUNTERS=y
> +      CONFIG_STACK_PROTECTOR=y
> +      CONFIG_UNSUPPORTED=y
> +      CONFIG_VM_EVENT=y
>    allow_failure: true

https://gitlab.com/xen-project/hardware/xen-staging/-/jobs/12604499722
shows 122 failures in otherwise-clean guidelines.  Some observations:

llc-colouring.c uses binary literals.  These are safe to use now since
4.21 with the updated toolchain baseline, but the Eclair config wants
updating to allow this language extension.

ipmmu-vmsa.c has a git:// url inside a block comment, which is
considered to be a Rule 3.1 violation.  In principle this ought to fix it:

diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl b/automation/eclair_analysis/ECLAIR/deviations.ecl
index 7dee4a488d45..8f5fc6c93bc5 100644
--- a/automation/eclair_analysis/ECLAIR/deviations.ecl
+++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
@@ -60,7 +60,7 @@ removed by the compiler, the resulting slowdown is negligible."
 
 -doc_begin="Comments starting with '/*' and containing hyperlinks are safe as
 they are not instances of commented-out code."
--config=MC3A2.R3.1,reports+={safe, "first_area(text(^.*https?://.*$))"}
+-config=MC3A2.R3.1,reports+={safe, "first_area(text(^.*(https?|git)://.*$))"}
 -doc_end
 
 #


but I've not tried it yet.

There's a R8.4 violation against __stack_chk_guard.  I think this wants
deviating locally, because it's a fairly magic construct.

Other than that, there's a smattering of violations.  Some will be fixed
by some work I've got pending for the x86 side of things, but most are
specific to arch/arm/.

~Andrew
Re: ARM64 notes: Re: [PATCH] CI: Extend eclair-*-allcode to enable as much as possible
Posted by Bertrand Marquis 1 day ago 
Hi Andrew,

> On 5 Jan 2026, at 19:14, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> 
> On 05/01/2026 12:24 pm, Andrew Cooper wrote:
>> eclair-x86_64-testing:
>> @@ -104,6 +122,33 @@ eclair-ARM64-allcode:
>>     LOGFILE: "eclair-ARM64.log"
>>     VARIANT: "ARM64"
>>     RULESET: "monitored"
>> +    EXTRA_XEN_CONFIG: |
>> +      CONFIG_ACPI=y
>> +      CONFIG_ARGO=y
>> +      CONFIG_ARM64_SVE=y
>> +      CONFIG_ARM_SMMU_V3=y
>> +      CONFIG_BOOT_TIME_CPUPOOLS=y
>> +      CONFIG_DEBUG_LOCK_PROFILE=y
>> +      CONFIG_DEBUG_TRACE=y
>> +      CONFIG_DEVICE_TREE_DEBUG=y
>> +      CONFIG_EFI_SET_VIRTUAL_ADDRESS_MAP=y
>> +      CONFIG_EXPERT=y
>> +      CONFIG_FFA=y
>> +      CONFIG_FFA_VM_TO_VM=y
>> +      CONFIG_GICV3_ESPI=y
>> +      CONFIG_HAS_ITS=y
>> +      CONFIG_IOREQ_SERVER=y
>> +      CONFIG_IPMMU_VMSA=y
>> +      CONFIG_LIVEPATCH=y
>> +      CONFIG_LLC_COLORING=y
>> +      CONFIG_OPTEE=y
>> +      CONFIG_OVERLAY_DTB=y
>> +      CONFIG_PCI_PASSTHROUGH=y
>> +      CONFIG_PERF_ARRAYS=y
>> +      CONFIG_PERF_COUNTERS=y
>> +      CONFIG_STACK_PROTECTOR=y
>> +      CONFIG_UNSUPPORTED=y
>> +      CONFIG_VM_EVENT=y
>>   allow_failure: true
> 
> https://gitlab.com/xen-project/hardware/xen-staging/-/jobs/12604499722
> shows 122 failures in otherwise-clean guidelines.  Some observations:
> 
> llc-colouring.c uses binary literals.  These are safe to use now since
> 4.21 with the updated toolchain baseline, but the Eclair config wants
> updating to allow this language extension.
> 
> ipmmu-vmsa.c has a git:// url inside a block comment, which is
> considered to be a Rule 3.1 violation.  In principle this ought to fix it:
> 
> diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl b/automation/eclair_analysis/ECLAIR/deviations.ecl
> index 7dee4a488d45..8f5fc6c93bc5 100644
> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
> @@ -60,7 +60,7 @@ removed by the compiler, the resulting slowdown is negligible."
>  
>  -doc_begin="Comments starting with '/*' and containing hyperlinks are safe as
>  they are not instances of commented-out code."
> --config=MC3A2.R3.1,reports+={safe, "first_area(text(^.*https?://.*$))"}
> +-config=MC3A2.R3.1,reports+={safe, "first_area(text(^.*(https?|git)://.*$))"}
>  -doc_end
>  
>  #
> 
> 
> but I've not tried it yet.
> 
> There's a R8.4 violation against __stack_chk_guard.  I think this wants
> deviating locally, because it's a fairly magic construct.
> 
> Other than that, there's a smattering of violations.  Some will be fixed
> by some work I've got pending for the x86 side of things, but most are
> specific to arch/arm/.
> 

They are quite a lot of violations coming from ffa.
I have a pending serie on FF-A waiting to be reviewed/committed.
I can push something to fix the findings after it, if that is ok for you ?

I will retrigger the CI from the branch corresponding to my serie and work
from there.

In any case, very good thing to activate all those and check with the CI, thanks a lot :-)

Cheers
Bertrand

> ~Andrew
Re: ARM64 notes: Re: [PATCH] CI: Extend eclair-*-allcode to enable as much as possible
Posted by Bertrand Marquis 23 hours ago 
Hi Nicolas,

On this subject, could you help me understand what the following error mean and how I should fix that:
https://eclair-analysis-logs.xenproject.org/fs/space/verdesse0/XEN.ecdf/xen-project/hardware/xen-staging/ECLAIR_normal/andrew/eclair/ARM64/12604499722/PROJECT.ecd;/by_service/MC3A2.R20.12.html

Thanks
Bertrand

> On 6 Jan 2026, at 08:33, Bertrand Marquis <Bertrand.Marquis@arm.com> wrote:
> 
> Hi Andrew,
> 
>> On 5 Jan 2026, at 19:14, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> 
>> On 05/01/2026 12:24 pm, Andrew Cooper wrote:
>>> eclair-x86_64-testing:
>>> @@ -104,6 +122,33 @@ eclair-ARM64-allcode:
>>>    LOGFILE: "eclair-ARM64.log"
>>>    VARIANT: "ARM64"
>>>    RULESET: "monitored"
>>> +    EXTRA_XEN_CONFIG: |
>>> +      CONFIG_ACPI=y
>>> +      CONFIG_ARGO=y
>>> +      CONFIG_ARM64_SVE=y
>>> +      CONFIG_ARM_SMMU_V3=y
>>> +      CONFIG_BOOT_TIME_CPUPOOLS=y
>>> +      CONFIG_DEBUG_LOCK_PROFILE=y
>>> +      CONFIG_DEBUG_TRACE=y
>>> +      CONFIG_DEVICE_TREE_DEBUG=y
>>> +      CONFIG_EFI_SET_VIRTUAL_ADDRESS_MAP=y
>>> +      CONFIG_EXPERT=y
>>> +      CONFIG_FFA=y
>>> +      CONFIG_FFA_VM_TO_VM=y
>>> +      CONFIG_GICV3_ESPI=y
>>> +      CONFIG_HAS_ITS=y
>>> +      CONFIG_IOREQ_SERVER=y
>>> +      CONFIG_IPMMU_VMSA=y
>>> +      CONFIG_LIVEPATCH=y
>>> +      CONFIG_LLC_COLORING=y
>>> +      CONFIG_OPTEE=y
>>> +      CONFIG_OVERLAY_DTB=y
>>> +      CONFIG_PCI_PASSTHROUGH=y
>>> +      CONFIG_PERF_ARRAYS=y
>>> +      CONFIG_PERF_COUNTERS=y
>>> +      CONFIG_STACK_PROTECTOR=y
>>> +      CONFIG_UNSUPPORTED=y
>>> +      CONFIG_VM_EVENT=y
>>>  allow_failure: true
>> 
>> https://gitlab.com/xen-project/hardware/xen-staging/-/jobs/12604499722
>> shows 122 failures in otherwise-clean guidelines.  Some observations:
>> 
>> llc-colouring.c uses binary literals.  These are safe to use now since
>> 4.21 with the updated toolchain baseline, but the Eclair config wants
>> updating to allow this language extension.
>> 
>> ipmmu-vmsa.c has a git:// url inside a block comment, which is
>> considered to be a Rule 3.1 violation.  In principle this ought to fix it:
>> 
>> diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl b/automation/eclair_analysis/ECLAIR/deviations.ecl
>> index 7dee4a488d45..8f5fc6c93bc5 100644
>> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
>> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
>> @@ -60,7 +60,7 @@ removed by the compiler, the resulting slowdown is negligible."
>> 
>> -doc_begin="Comments starting with '/*' and containing hyperlinks are safe as
>> they are not instances of commented-out code."
>> --config=MC3A2.R3.1,reports+={safe, "first_area(text(^.*https?://.*$))"}
>> +-config=MC3A2.R3.1,reports+={safe, "first_area(text(^.*(https?|git)://.*$))"}
>> -doc_end
>> 
>> #
>> 
>> 
>> but I've not tried it yet.
>> 
>> There's a R8.4 violation against __stack_chk_guard.  I think this wants
>> deviating locally, because it's a fairly magic construct.
>> 
>> Other than that, there's a smattering of violations.  Some will be fixed
>> by some work I've got pending for the x86 side of things, but most are
>> specific to arch/arm/.
>> 
> 
> They are quite a lot of violations coming from ffa.
> I have a pending serie on FF-A waiting to be reviewed/committed.
> I can push something to fix the findings after it, if that is ok for you ?
> 
> I will retrigger the CI from the branch corresponding to my serie and work
> from there.
> 
> In any case, very good thing to activate all those and check with the CI, thanks a lot :-)
> 
> Cheers
> Bertrand
> 
>> ~Andrew
Re: ARM64 notes: Re: [PATCH] CI: Extend eclair-*-allcode to enable as much as possible
Posted by Nicola Vetrini 23 hours ago 
On 2026-01-06 09:26, Bertrand Marquis wrote:
> Hi Nicolas,
> 
> On this subject, could you help me understand what the following error 
> mean and how I should fix that:
> https://eclair-analysis-logs.xenproject.org/fs/space/verdesse0/XEN.ecdf/xen-project/hardware/xen-staging/ECLAIR_normal/andrew/eclair/ARM64/12604499722/PROJECT.ecd;/by_service/MC3A2.R20.12.html
> 

Hi Bertrand,

the point here is that the macro parameter 'FFA_VERSION' is itself a 
macro. This means that inside 'FW_ABI' and similar macros one occurrence 
of the 'abi' macro parameter will be further expanded to the value of 
'FFA_VERSION', while the one used for stringification will not. This is 
potentially confusing for some programmers that do not know well the 
semantics of the preprocessor, which is why MISRA discourages it, but in 
these cases I would say it's very much intentional. There are already a 
few deviations for special cases (e.g. BUILD_BUG_ON uses the same 
pattern to print the condition), so I would suggest adding the macro 
FW_ABI to the deviation.

> Thanks
> Bertrand
> 
>> On 6 Jan 2026, at 08:33, Bertrand Marquis <Bertrand.Marquis@arm.com> 
>> wrote:
>> 
>> Hi Andrew,
>> 
>>> On 5 Jan 2026, at 19:14, Andrew Cooper <andrew.cooper3@citrix.com> 
>>> wrote:
>>> 
>>> On 05/01/2026 12:24 pm, Andrew Cooper wrote:
>>>> eclair-x86_64-testing:
>>>> @@ -104,6 +122,33 @@ eclair-ARM64-allcode:
>>>>    LOGFILE: "eclair-ARM64.log"
>>>>    VARIANT: "ARM64"
>>>>    RULESET: "monitored"
>>>> +    EXTRA_XEN_CONFIG: |
>>>> +      CONFIG_ACPI=y
>>>> +      CONFIG_ARGO=y
>>>> +      CONFIG_ARM64_SVE=y
>>>> +      CONFIG_ARM_SMMU_V3=y
>>>> +      CONFIG_BOOT_TIME_CPUPOOLS=y
>>>> +      CONFIG_DEBUG_LOCK_PROFILE=y
>>>> +      CONFIG_DEBUG_TRACE=y
>>>> +      CONFIG_DEVICE_TREE_DEBUG=y
>>>> +      CONFIG_EFI_SET_VIRTUAL_ADDRESS_MAP=y
>>>> +      CONFIG_EXPERT=y
>>>> +      CONFIG_FFA=y
>>>> +      CONFIG_FFA_VM_TO_VM=y
>>>> +      CONFIG_GICV3_ESPI=y
>>>> +      CONFIG_HAS_ITS=y
>>>> +      CONFIG_IOREQ_SERVER=y
>>>> +      CONFIG_IPMMU_VMSA=y
>>>> +      CONFIG_LIVEPATCH=y
>>>> +      CONFIG_LLC_COLORING=y
>>>> +      CONFIG_OPTEE=y
>>>> +      CONFIG_OVERLAY_DTB=y
>>>> +      CONFIG_PCI_PASSTHROUGH=y
>>>> +      CONFIG_PERF_ARRAYS=y
>>>> +      CONFIG_PERF_COUNTERS=y
>>>> +      CONFIG_STACK_PROTECTOR=y
>>>> +      CONFIG_UNSUPPORTED=y
>>>> +      CONFIG_VM_EVENT=y
>>>>  allow_failure: true
>>> 
>>> https://gitlab.com/xen-project/hardware/xen-staging/-/jobs/12604499722
>>> shows 122 failures in otherwise-clean guidelines.  Some observations:
>>> 
>>> llc-colouring.c uses binary literals.  These are safe to use now 
>>> since
>>> 4.21 with the updated toolchain baseline, but the Eclair config wants
>>> updating to allow this language extension.
>>> 
>>> ipmmu-vmsa.c has a git:// url inside a block comment, which is
>>> considered to be a Rule 3.1 violation.  In principle this ought to 
>>> fix it:
>>> 
>>> diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl 
>>> b/automation/eclair_analysis/ECLAIR/deviations.ecl
>>> index 7dee4a488d45..8f5fc6c93bc5 100644
>>> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
>>> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
>>> @@ -60,7 +60,7 @@ removed by the compiler, the resulting slowdown is 
>>> negligible."
>>> 
>>> -doc_begin="Comments starting with '/*' and containing hyperlinks are 
>>> safe as
>>> they are not instances of commented-out code."
>>> --config=MC3A2.R3.1,reports+={safe, 
>>> "first_area(text(^.*https?://.*$))"}
>>> +-config=MC3A2.R3.1,reports+={safe, 
>>> "first_area(text(^.*(https?|git)://.*$))"}
>>> -doc_end
>>> 
>>> #
>>> 
>>> 
>>> but I've not tried it yet.
>>> 
>>> There's a R8.4 violation against __stack_chk_guard.  I think this 
>>> wants
>>> deviating locally, because it's a fairly magic construct.
>>> 
>>> Other than that, there's a smattering of violations.  Some will be 
>>> fixed
>>> by some work I've got pending for the x86 side of things, but most 
>>> are
>>> specific to arch/arm/.
>>> 
>> 
>> They are quite a lot of violations coming from ffa.
>> I have a pending serie on FF-A waiting to be reviewed/committed.
>> I can push something to fix the findings after it, if that is ok for 
>> you ?
>> 
>> I will retrigger the CI from the branch corresponding to my serie and 
>> work
>> from there.
>> 
>> In any case, very good thing to activate all those and check with the 
>> CI, thanks a lot :-)
>> 
>> Cheers
>> Bertrand
>> 
>>> ~Andrew

-- 
Nicola Vetrini, B.Sc.
Software Engineer
BUGSENG (https://bugseng.com)
LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253
Re: ARM64 notes: Re: [PATCH] CI: Extend eclair-*-allcode to enable as much as possible
Posted by Andrew Cooper 21 hours ago 
On 06/01/2026 8:40 am, Nicola Vetrini wrote:
> On 2026-01-06 09:26, Bertrand Marquis wrote:
>> Hi Nicolas,
>>
>> On this subject, could you help me understand what the following
>> error mean and how I should fix that:
>> https://eclair-analysis-logs.xenproject.org/fs/space/verdesse0/XEN.ecdf/xen-project/hardware/xen-staging/ECLAIR_normal/andrew/eclair/ARM64/12604499722/PROJECT.ecd;/by_service/MC3A2.R20.12.html
>>
>>
>
> Hi Bertrand,
>
> the point here is that the macro parameter 'FFA_VERSION' is itself a
> macro. This means that inside 'FW_ABI' and similar macros one
> occurrence of the 'abi' macro parameter will be further expanded to
> the value of 'FFA_VERSION', while the one used for stringification
> will not. This is potentially confusing for some programmers that do
> not know well the semantics of the preprocessor, which is why MISRA
> discourages it, but in these cases I would say it's very much
> intentional. There are already a few deviations for special cases
> (e.g. BUILD_BUG_ON uses the same pattern to print the condition), so I
> would suggest adding the macro FW_ABI to the deviation.

We have a bunch of those on the x86 side too.

https://eclair-analysis-logs.xenproject.org/fs/space/verdesse0/XEN.ecdf/xen-project/hardware/xen-staging/ECLAIR_normal/andrew/eclair/X86_64/12611734537/PROJECT.ecd;/by_service/MC3A2.R20.12.html

Here, we're using the numeric value for making a hypercall, but
rendering the textural name for failure messages as it's more helpful
than just the param number.

~Andrew
Re: ARM64 notes: Re: [PATCH] CI: Extend eclair-*-allcode to enable as much as possible
Posted by Bertrand Marquis 1 day ago 

> On 6 Jan 2026, at 08:33, Bertrand Marquis <Bertrand.Marquis@arm.com> wrote:
> 
> Hi Andrew,
> 
>> On 5 Jan 2026, at 19:14, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> 
>> On 05/01/2026 12:24 pm, Andrew Cooper wrote:
>>> eclair-x86_64-testing:
>>> @@ -104,6 +122,33 @@ eclair-ARM64-allcode:
>>>    LOGFILE: "eclair-ARM64.log"
>>>    VARIANT: "ARM64"
>>>    RULESET: "monitored"
>>> +    EXTRA_XEN_CONFIG: |
>>> +      CONFIG_ACPI=y
>>> +      CONFIG_ARGO=y
>>> +      CONFIG_ARM64_SVE=y
>>> +      CONFIG_ARM_SMMU_V3=y
>>> +      CONFIG_BOOT_TIME_CPUPOOLS=y
>>> +      CONFIG_DEBUG_LOCK_PROFILE=y
>>> +      CONFIG_DEBUG_TRACE=y
>>> +      CONFIG_DEVICE_TREE_DEBUG=y
>>> +      CONFIG_EFI_SET_VIRTUAL_ADDRESS_MAP=y
>>> +      CONFIG_EXPERT=y
>>> +      CONFIG_FFA=y
>>> +      CONFIG_FFA_VM_TO_VM=y
>>> +      CONFIG_GICV3_ESPI=y
>>> +      CONFIG_HAS_ITS=y
>>> +      CONFIG_IOREQ_SERVER=y
>>> +      CONFIG_IPMMU_VMSA=y
>>> +      CONFIG_LIVEPATCH=y
>>> +      CONFIG_LLC_COLORING=y
>>> +      CONFIG_OPTEE=y
>>> +      CONFIG_OVERLAY_DTB=y
>>> +      CONFIG_PCI_PASSTHROUGH=y
>>> +      CONFIG_PERF_ARRAYS=y
>>> +      CONFIG_PERF_COUNTERS=y
>>> +      CONFIG_STACK_PROTECTOR=y
>>> +      CONFIG_UNSUPPORTED=y
>>> +      CONFIG_VM_EVENT=y
>>>  allow_failure: true
>> 
>> https://gitlab.com/xen-project/hardware/xen-staging/-/jobs/12604499722
>> shows 122 failures in otherwise-clean guidelines.  Some observations:
>> 
>> llc-colouring.c uses binary literals.  These are safe to use now since
>> 4.21 with the updated toolchain baseline, but the Eclair config wants
>> updating to allow this language extension.
>> 
>> ipmmu-vmsa.c has a git:// url inside a block comment, which is
>> considered to be a Rule 3.1 violation.  In principle this ought to fix it:
>> 
>> diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl b/automation/eclair_analysis/ECLAIR/deviations.ecl
>> index 7dee4a488d45..8f5fc6c93bc5 100644
>> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
>> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
>> @@ -60,7 +60,7 @@ removed by the compiler, the resulting slowdown is negligible."
>> 
>> -doc_begin="Comments starting with '/*' and containing hyperlinks are safe as
>> they are not instances of commented-out code."
>> --config=MC3A2.R3.1,reports+={safe, "first_area(text(^.*https?://.*$))"}
>> +-config=MC3A2.R3.1,reports+={safe, "first_area(text(^.*(https?|git)://.*$))"}
>> -doc_end
>> 
>> #
>> 
>> 
>> but I've not tried it yet.
>> 
>> There's a R8.4 violation against __stack_chk_guard.  I think this wants
>> deviating locally, because it's a fairly magic construct.
>> 
>> Other than that, there's a smattering of violations.  Some will be fixed
>> by some work I've got pending for the x86 side of things, but most are
>> specific to arch/arm/.
>> 
> 
> They are quite a lot of violations coming from ffa.
> I have a pending serie on FF-A waiting to be reviewed/committed.
> I can push something to fix the findings after it, if that is ok for you ?
> 
> I will retrigger the CI from the branch corresponding to my serie and work
> from there.
> 
> In any case, very good thing to activate all those and check with the CI, thanks a lot :-)

There are also a bunch of optee ones that i can handle in a patch.

Cheers
Bertrand

> 
> Cheers
> Bertrand
> 
>> ~Andrew
Re: ARM64 notes: Re: [PATCH] CI: Extend eclair-*-allcode to enable as much as possible
Posted by Andrew Cooper 21 hours ago 
On 06/01/2026 7:37 am, Bertrand Marquis wrote:
>
>> On 6 Jan 2026, at 08:33, Bertrand Marquis <Bertrand.Marquis@arm.com> wrote:
>>
>> Hi Andrew,
>>
>>> On 5 Jan 2026, at 19:14, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>>>
>>> On 05/01/2026 12:24 pm, Andrew Cooper wrote:
>>>> eclair-x86_64-testing:
>>>> @@ -104,6 +122,33 @@ eclair-ARM64-allcode:
>>>>    LOGFILE: "eclair-ARM64.log"
>>>>    VARIANT: "ARM64"
>>>>    RULESET: "monitored"
>>>> +    EXTRA_XEN_CONFIG: |
>>>> +      CONFIG_ACPI=y
>>>> +      CONFIG_ARGO=y
>>>> +      CONFIG_ARM64_SVE=y
>>>> +      CONFIG_ARM_SMMU_V3=y
>>>> +      CONFIG_BOOT_TIME_CPUPOOLS=y
>>>> +      CONFIG_DEBUG_LOCK_PROFILE=y
>>>> +      CONFIG_DEBUG_TRACE=y
>>>> +      CONFIG_DEVICE_TREE_DEBUG=y
>>>> +      CONFIG_EFI_SET_VIRTUAL_ADDRESS_MAP=y
>>>> +      CONFIG_EXPERT=y
>>>> +      CONFIG_FFA=y
>>>> +      CONFIG_FFA_VM_TO_VM=y
>>>> +      CONFIG_GICV3_ESPI=y
>>>> +      CONFIG_HAS_ITS=y
>>>> +      CONFIG_IOREQ_SERVER=y
>>>> +      CONFIG_IPMMU_VMSA=y
>>>> +      CONFIG_LIVEPATCH=y
>>>> +      CONFIG_LLC_COLORING=y
>>>> +      CONFIG_OPTEE=y
>>>> +      CONFIG_OVERLAY_DTB=y
>>>> +      CONFIG_PCI_PASSTHROUGH=y
>>>> +      CONFIG_PERF_ARRAYS=y
>>>> +      CONFIG_PERF_COUNTERS=y
>>>> +      CONFIG_STACK_PROTECTOR=y
>>>> +      CONFIG_UNSUPPORTED=y
>>>> +      CONFIG_VM_EVENT=y
>>>>  allow_failure: true
>>> https://gitlab.com/xen-project/hardware/xen-staging/-/jobs/12604499722
>>> shows 122 failures in otherwise-clean guidelines.  Some observations:
>>>
>>> llc-colouring.c uses binary literals.  These are safe to use now since
>>> 4.21 with the updated toolchain baseline, but the Eclair config wants
>>> updating to allow this language extension.
>>>
>>> ipmmu-vmsa.c has a git:// url inside a block comment, which is
>>> considered to be a Rule 3.1 violation.  In principle this ought to fix it:
>>>
>>> diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl b/automation/eclair_analysis/ECLAIR/deviations.ecl
>>> index 7dee4a488d45..8f5fc6c93bc5 100644
>>> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
>>> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
>>> @@ -60,7 +60,7 @@ removed by the compiler, the resulting slowdown is negligible."
>>>
>>> -doc_begin="Comments starting with '/*' and containing hyperlinks are safe as
>>> they are not instances of commented-out code."
>>> --config=MC3A2.R3.1,reports+={safe, "first_area(text(^.*https?://.*$))"}
>>> +-config=MC3A2.R3.1,reports+={safe, "first_area(text(^.*(https?|git)://.*$))"}
>>> -doc_end
>>>
>>> #
>>>
>>>
>>> but I've not tried it yet.
>>>
>>> There's a R8.4 violation against __stack_chk_guard.  I think this wants
>>> deviating locally, because it's a fairly magic construct.
>>>
>>> Other than that, there's a smattering of violations.  Some will be fixed
>>> by some work I've got pending for the x86 side of things, but most are
>>> specific to arch/arm/.
>>>
>> They are quite a lot of violations coming from ffa.
>> I have a pending serie on FF-A waiting to be reviewed/committed.
>> I can push something to fix the findings after it, if that is ok for you ?
>>
>> I will retrigger the CI from the branch corresponding to my serie and work
>> from there.
>>
>> In any case, very good thing to activate all those and check with the CI, thanks a lot :-)
> There are also a bunch of optee ones that i can handle in a patch.

These failures are non-blocking in Gitlab CI right now.  Therefore,
fixes can come independently of this patch.

Once all the code is being actively scanned, I'd like to see about
creating a new blocking ruleset so the rules we've cleaned fully across
the codebase are enforced.


One point that was only in the cover letter of the original email and
needs discussing.

In ARM, MPU and MMU are mutually exclusive, as are VGIC and NEW_VGIC, so
I can't find a way of getting ARM64-allcode to really match up with its
name.

I strongly recommend deleting NEW_VGIC.  It's had 0 development on it
since it's introduction in 2018, is causing problems that Oleksii has
had to work around to improve domain/vcpu allocation in common code
(done now, series pending), and it has corruption problems when
destroying domains (noticed during the review of Oleksii's series).

MMU vs MPU is harder.  I'm not sure if it's even feasible to make a
build that contains both.

~Andrew
Re: ARM64 notes: Re: [PATCH] CI: Extend eclair-*-allcode to enable as much as possible
Posted by Bertrand Marquis 20 hours ago 
Hi Andrew,

> On 6 Jan 2026, at 12:20, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> 
> On 06/01/2026 7:37 am, Bertrand Marquis wrote:
>> 
>>> On 6 Jan 2026, at 08:33, Bertrand Marquis <Bertrand.Marquis@arm.com> wrote:
>>> 
>>> Hi Andrew,
>>> 
>>>> On 5 Jan 2026, at 19:14, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>>>> 
>>>> On 05/01/2026 12:24 pm, Andrew Cooper wrote:
>>>>> eclair-x86_64-testing:
>>>>> @@ -104,6 +122,33 @@ eclair-ARM64-allcode:
>>>>>   LOGFILE: "eclair-ARM64.log"
>>>>>   VARIANT: "ARM64"
>>>>>   RULESET: "monitored"
>>>>> +    EXTRA_XEN_CONFIG: |
>>>>> +      CONFIG_ACPI=y
>>>>> +      CONFIG_ARGO=y
>>>>> +      CONFIG_ARM64_SVE=y
>>>>> +      CONFIG_ARM_SMMU_V3=y
>>>>> +      CONFIG_BOOT_TIME_CPUPOOLS=y
>>>>> +      CONFIG_DEBUG_LOCK_PROFILE=y
>>>>> +      CONFIG_DEBUG_TRACE=y
>>>>> +      CONFIG_DEVICE_TREE_DEBUG=y
>>>>> +      CONFIG_EFI_SET_VIRTUAL_ADDRESS_MAP=y
>>>>> +      CONFIG_EXPERT=y
>>>>> +      CONFIG_FFA=y
>>>>> +      CONFIG_FFA_VM_TO_VM=y
>>>>> +      CONFIG_GICV3_ESPI=y
>>>>> +      CONFIG_HAS_ITS=y
>>>>> +      CONFIG_IOREQ_SERVER=y
>>>>> +      CONFIG_IPMMU_VMSA=y
>>>>> +      CONFIG_LIVEPATCH=y
>>>>> +      CONFIG_LLC_COLORING=y
>>>>> +      CONFIG_OPTEE=y
>>>>> +      CONFIG_OVERLAY_DTB=y
>>>>> +      CONFIG_PCI_PASSTHROUGH=y
>>>>> +      CONFIG_PERF_ARRAYS=y
>>>>> +      CONFIG_PERF_COUNTERS=y
>>>>> +      CONFIG_STACK_PROTECTOR=y
>>>>> +      CONFIG_UNSUPPORTED=y
>>>>> +      CONFIG_VM_EVENT=y
>>>>> allow_failure: true
>>>> https://gitlab.com/xen-project/hardware/xen-staging/-/jobs/12604499722
>>>> shows 122 failures in otherwise-clean guidelines.  Some observations:
>>>> 
>>>> llc-colouring.c uses binary literals.  These are safe to use now since
>>>> 4.21 with the updated toolchain baseline, but the Eclair config wants
>>>> updating to allow this language extension.
>>>> 
>>>> ipmmu-vmsa.c has a git:// url inside a block comment, which is
>>>> considered to be a Rule 3.1 violation.  In principle this ought to fix it:
>>>> 
>>>> diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl b/automation/eclair_analysis/ECLAIR/deviations.ecl
>>>> index 7dee4a488d45..8f5fc6c93bc5 100644
>>>> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
>>>> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
>>>> @@ -60,7 +60,7 @@ removed by the compiler, the resulting slowdown is negligible."
>>>> 
>>>> -doc_begin="Comments starting with '/*' and containing hyperlinks are safe as
>>>> they are not instances of commented-out code."
>>>> --config=MC3A2.R3.1,reports+={safe, "first_area(text(^.*https?://.*$))"}
>>>> +-config=MC3A2.R3.1,reports+={safe, "first_area(text(^.*(https?|git)://.*$))"}
>>>> -doc_end
>>>> 
>>>> #
>>>> 
>>>> 
>>>> but I've not tried it yet.
>>>> 
>>>> There's a R8.4 violation against __stack_chk_guard.  I think this wants
>>>> deviating locally, because it's a fairly magic construct.
>>>> 
>>>> Other than that, there's a smattering of violations.  Some will be fixed
>>>> by some work I've got pending for the x86 side of things, but most are
>>>> specific to arch/arm/.
>>>> 
>>> They are quite a lot of violations coming from ffa.
>>> I have a pending serie on FF-A waiting to be reviewed/committed.
>>> I can push something to fix the findings after it, if that is ok for you ?
>>> 
>>> I will retrigger the CI from the branch corresponding to my serie and work
>>> from there.
>>> 
>>> In any case, very good thing to activate all those and check with the CI, thanks a lot :-)
>> There are also a bunch of optee ones that i can handle in a patch.
> 
> These failures are non-blocking in Gitlab CI right now.  Therefore,
> fixes can come independently of this patch.
> 
> Once all the code is being actively scanned, I'd like to see about
> creating a new blocking ruleset so the rules we've cleaned fully across
> the codebase are enforced.
> 
> 
> One point that was only in the cover letter of the original email and
> needs discussing.
> 
> In ARM, MPU and MMU are mutually exclusive, as are VGIC and NEW_VGIC, so
> I can't find a way of getting ARM64-allcode to really match up with its
> name.
> 
> I strongly recommend deleting NEW_VGIC.  It's had 0 development on it
> since it's introduction in 2018, is causing problems that Oleksii has
> had to work around to improve domain/vcpu allocation in common code
> (done now, series pending), and it has corruption problems when
> destroying domains (noticed during the review of Oleksii's series).
> 
> MMU vs MPU is harder.  I'm not sure if it's even feasible to make a
> build that contains both.

MMU and MPU are definitely not possible to select together and will never
be. The allcode should definitely select GIC and MMU, for the new vgic
I think there was some people still using that for some reason a while ago
but not sure this is still the case, Julien is a lot more aware.

For MPU, at some point we will need to validate the code but I think we
can do something like a virtual "arm64-mpu" allcode config when that
is needed. At this stage, development is still in process so we do not need
to check that part of the code.

Cheers
Bertrand

> 
> ~Andrew
Re: ARM64 notes: Re: [PATCH] CI: Extend eclair-*-allcode to enable as much as possible
Posted by Nicola Vetrini 1 day, 11 hours ago 
On 2026-01-05 19:14, Andrew Cooper wrote:
> On 05/01/2026 12:24 pm, Andrew Cooper wrote:
>>  eclair-x86_64-testing:
>> @@ -104,6 +122,33 @@ eclair-ARM64-allcode:
>>      LOGFILE: "eclair-ARM64.log"
>>      VARIANT: "ARM64"
>>      RULESET: "monitored"
>> +    EXTRA_XEN_CONFIG: |
>> +      CONFIG_ACPI=y
>> +      CONFIG_ARGO=y
>> +      CONFIG_ARM64_SVE=y
>> +      CONFIG_ARM_SMMU_V3=y
>> +      CONFIG_BOOT_TIME_CPUPOOLS=y
>> +      CONFIG_DEBUG_LOCK_PROFILE=y
>> +      CONFIG_DEBUG_TRACE=y
>> +      CONFIG_DEVICE_TREE_DEBUG=y
>> +      CONFIG_EFI_SET_VIRTUAL_ADDRESS_MAP=y
>> +      CONFIG_EXPERT=y
>> +      CONFIG_FFA=y
>> +      CONFIG_FFA_VM_TO_VM=y
>> +      CONFIG_GICV3_ESPI=y
>> +      CONFIG_HAS_ITS=y
>> +      CONFIG_IOREQ_SERVER=y
>> +      CONFIG_IPMMU_VMSA=y
>> +      CONFIG_LIVEPATCH=y
>> +      CONFIG_LLC_COLORING=y
>> +      CONFIG_OPTEE=y
>> +      CONFIG_OVERLAY_DTB=y
>> +      CONFIG_PCI_PASSTHROUGH=y
>> +      CONFIG_PERF_ARRAYS=y
>> +      CONFIG_PERF_COUNTERS=y
>> +      CONFIG_STACK_PROTECTOR=y
>> +      CONFIG_UNSUPPORTED=y
>> +      CONFIG_VM_EVENT=y
>>    allow_failure: true
> 
> https://gitlab.com/xen-project/hardware/xen-staging/-/jobs/12604499722
> shows 122 failures in otherwise-clean guidelines.  Some observations:
> 
> llc-colouring.c uses binary literals.  These are safe to use now since
> 4.21 with the updated toolchain baseline, but the Eclair config wants
> updating to allow this language extension.
> 

Yeah (though I don't see a strong reason to do so, for a single 
literal); I can write the patch.

Also xen/arch/arm/acpi/boot.c could use __func__ as almost everywhere 
else in xen/

> ipmmu-vmsa.c has a git:// url inside a block comment, which is
> considered to be a Rule 3.1 violation.  In principle this ought to fix 
> it:
> 

Indeed it should.

> diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl 
> b/automation/eclair_analysis/ECLAIR/deviations.ecl
> index 7dee4a488d45..8f5fc6c93bc5 100644
> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
> @@ -60,7 +60,7 @@ removed by the compiler, the resulting slowdown is 
> negligible."
>  
>  -doc_begin="Comments starting with '/*' and containing hyperlinks are 
> safe as
>  they are not instances of commented-out code."
> --config=MC3A2.R3.1,reports+={safe, 
> "first_area(text(^.*https?://.*$))"}
> +-config=MC3A2.R3.1,reports+={safe, 
> "first_area(text(^.*(https?|git)://.*$))"}
>  -doc_end
>  
>  #
> 
> 
> but I've not tried it yet.
> 
> There's a R8.4 violation against __stack_chk_guard.  I think this wants
> deviating locally, because it's a fairly magic construct.
> 

ack.

> Other than that, there's a smattering of violations.  Some will be 
> fixed
> by some work I've got pending for the x86 side of things, but most are
> specific to arch/arm/.
> 
> ~Andrew

-- 
Nicola Vetrini, B.Sc.
Software Engineer
BUGSENG (https://bugseng.com)
LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253
Re: ARM64 notes: Re: [PATCH] CI: Extend eclair-*-allcode to enable as much as possible
Posted by Andrew Cooper 1 day, 10 hours ago 
On 05/01/2026 9:12 pm, Nicola Vetrini wrote:
> On 2026-01-05 19:14, Andrew Cooper wrote:
>>
>> llc-colouring.c uses binary literals.  These are safe to use now since
>> 4.21 with the updated toolchain baseline, but the Eclair config wants
>> updating to allow this language extension.
>>
>
> Yeah (though I don't see a strong reason to do so, for a single
> literal); I can write the patch.

A separate discussion happened about starting to use binary literals
more widely.  It's a capability we'd like to be able to use.

>
> Also xen/arch/arm/acpi/boot.c could use __func__ as almost everywhere
> else in xen/

Yeah (although I considered that not interesting enough to discuss.)

>
>> ipmmu-vmsa.c has a git:// url inside a block comment, which is
>> considered to be a Rule 3.1 violation.  In principle this ought to
>> fix it:
>>
>
> Indeed it should.
>
>> diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl
>> b/automation/eclair_analysis/ECLAIR/deviations.ecl
>> index 7dee4a488d45..8f5fc6c93bc5 100644
>> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
>> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
>> @@ -60,7 +60,7 @@ removed by the compiler, the resulting slowdown is
>> negligible."
>>  
>>  -doc_begin="Comments starting with '/*' and containing hyperlinks
>> are safe as
>>  they are not instances of commented-out code."
>> --config=MC3A2.R3.1,reports+={safe, "first_area(text(^.*https?://.*$))"}
>> +-config=MC3A2.R3.1,reports+={safe,
>> "first_area(text(^.*(https?|git)://.*$))"}
>>  -doc_end
>>  
>>  #
>>
>>
>> but I've not tried it yet.
>>
>> There's a R8.4 violation against __stack_chk_guard.  I think this wants
>> deviating locally, because it's a fairly magic construct.
>>
>
> ack.

For the x86 side,
https://eclair-analysis-logs.xenproject.org/fs/space/verdesse0/XEN.ecdf/xen-project/hardware/xen-staging/ECLAIR_normal/andrew/eclair/X86_64/12595699289/PROJECT.ecd;/by_service/MC3A2.R8.4.html
shows that we've got the same problem with pvh_start_info_pa and
early_hypercall_insn.

Like __stack_chk_guard, these are external because they're accessed by
assembly, but don't need/want to be declared anywhere else in C.  What's
the recommended way of handling these issues?

~Andrew

Patchew 2.1-devel-b67e4c2

© 2016 - 2026 Red Hat, Inc.