xen/drivers/passthrough/arm/ipmmu-vmsa.c | 6 ++---- xen/drivers/passthrough/arm/smmu.c | 7 +++---- 2 files changed, 5 insertions(+), 8 deletions(-)
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
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
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
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
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
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
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
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
© 2016 - 2026 Red Hat, Inc.