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

[Bertrand Marquis <Bertrand.Marquis@xxxxxxx>]

Hi Andrew,

> On 6 Jan 2026, at 12:20, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> wrote:
> 
> On 06/01/2026 7:37 am, Bertrand Marquis wrote:
>> 
>>> 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 :-)
>> 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