> On 6 Jan 2026, at 08:33, Bertrand Marquis <[email protected]> wrote:
>
> Hi Andrew,
>
>> On 5 Jan 2026, at 19:14, Andrew Cooper <[email protected]> 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
