Re: [PATCH 0/2] Final series to make Arm MISRA allcode green

["Orzel, Michal" <michal.orzel@xxxxxxx>]

On 08/04/2026 12:42, Andrew Cooper wrote:
> On 08/04/2026 11:36 am, Orzel, Michal wrote:
>>
>> On 08/04/2026 12:21, Nicola Vetrini wrote:
>>> On 2026-04-08 11:51, Andrew Cooper wrote:
>>>> On 08/04/2026 10:46 am, Nicola Vetrini wrote:
>>>>> On 2026-04-08 11:22, Andrew Cooper wrote:
>>>>>> On 07/04/2026 11:34 am, Michal Orzel wrote:
>>>>>>> No more regressions for clean guidelines:
>>>>>>> https://gitlab.com/xen-project/people/morzel/xen/-/pipelines/2433943072
>>>>>>>
>>>>>>> Michal Orzel (2):
>>>>>>>   iommu/arm: smmu: Fix variable shadowing
>>>>>>>   iommu/arm: ipmmu-vmsa: Fix variable shadowing
>>>>>>>
>>>>>>>  xen/drivers/passthrough/arm/ipmmu-vmsa.c | 6 ++----
>>>>>>>  xen/drivers/passthrough/arm/smmu.c       | 7 +++----
>>>>>>>  2 files changed, 5 insertions(+), 8 deletions(-)
>>>>>> If all the violations are fixed, should this test be made blocking?
>>>>>>
>>>>>> ~Andrew
>>>>> Only if they are also clean on x86; otherwise an arm-specific list of
>>>>> clean rules should be made (probably better). @Michal what do you 
>>>>> prefer?
>>>>>
>>>> All I'm suggesting is this:
>>>>
>>>> xen.git/xen$ git diff
>>>> diff --git a/automation/gitlab-ci/analyze.yaml 
>>>> b/automation/gitlab-ci/analyze.yaml
>>>> index 4e9af9d60224..f01798c5dee6 100644
>>>> --- a/automation/gitlab-ci/analyze.yaml
>>>> +++ b/automation/gitlab-ci/analyze.yaml
>>>> @@ -149,7 +149,7 @@ eclair-ARM64-allcode:
>>>>        CONFIG_STACK_PROTECTOR=y
>>>>        CONFIG_UNSUPPORTED=y
>>>>        CONFIG_VM_EVENT=y
>>>> -  allow_failure: true
>>>> +  allow_failure: false
>>>>  
>>>>  eclair-ARM64-testing:
>>>>    extends: eclair-ARM64-allcode
>>>>
>>>>
>>>> so regressions become blocking.
>>>>
>>>> ~Andrew
>>> Ah, yes, indeed. I didn't look at the patches but given the diff it 
>>> makes sense
>> In general that's a good idea and something I had in mind. That said, we will
>> likely be expanding the list of enabled features there as soon as one 
>> arrives.
>> What should we do in that case? Make sure that before adding new =y option, 
>> the
>> allcode passes in our Xen fork?
> 
> New code could be clean as it goes in.  At this point, it's not
> interestingly different from "does it compile" as a prerequisite.
I can see there are some missing features like static memory/shared memory but
they are tested as part of AMD (it would still be good to have all listed in
allcode). Additionally, we could enable early printk with some dummy values to
cover early_printk.c

~Michal