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

Michal Orzel posted 2 patches 5 days, 10 hours ago
Patches applied successfully (tree, apply log)
git fetch https://gitlab.com/xen-project/patchew/xen tags/patchew/20260407103434.90838-1-michal.orzel@amd.com
xen/drivers/passthrough/arm/ipmmu-vmsa.c | 6 ++----
xen/drivers/passthrough/arm/smmu.c       | 7 +++----
2 files changed, 5 insertions(+), 8 deletions(-)
[PATCH 0/2] Final series to make Arm MISRA allcode green
Posted by Michal Orzel 5 days, 10 hours ago
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(-)

-- 
2.43.0
Re: [PATCH 0/2] Final series to make Arm MISRA allcode green
Posted by Andrew Cooper 4 days, 11 hours ago
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
Re: [PATCH 0/2] Final series to make Arm MISRA allcode green
Posted by Nicola Vetrini 4 days, 11 hours ago
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?

-- 
Nicola Vetrini, B.Sc.
Software Engineer
BUGSENG (https://bugseng.com)
LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253
Re: [PATCH 0/2] Final series to make Arm MISRA allcode green
Posted by Andrew Cooper 4 days, 11 hours ago
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

Re: [PATCH 0/2] Final series to make Arm MISRA allcode green
Posted by Nicola Vetrini 4 days, 10 hours ago
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

-- 
Nicola Vetrini, B.Sc.
Software Engineer
BUGSENG (https://bugseng.com)
LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253

Re: [PATCH 0/2] Final series to make Arm MISRA allcode green
Posted by Orzel, Michal 4 days, 10 hours ago

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?

~Michal


Re: [PATCH 0/2] Final series to make Arm MISRA allcode green
Posted by Andrew Cooper 4 days, 10 hours ago
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.

~Andrew

Re: [PATCH 0/2] Final series to make Arm MISRA allcode green
Posted by Orzel, Michal 4 days, 10 hours ago

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