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

[Nicola Vetrini <nicola.vetrini@xxxxxxxxxxx>]

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@xxxxxxx> 
> > wrote:
> > Hi Andrew,
> >
> > > On 5 Jan 2026, at 19:14, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> 
> > > 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