|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: ARM64 notes: Re: [PATCH] CI: Extend eclair-*-allcode to enable as much as possible
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. ~Andrew
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |