Hi Andrew, > On 6 Jan 2026, at 12:20, Andrew Cooper <[email protected]> wrote: > > On 06/01/2026 7:37 am, Bertrand Marquis wrote: >> >>> 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. > > 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
