Re: [xen-unstable-smoke test] 173362: regressions - FAIL

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Fri, 30 Sep 2022, Jan Beulich wrote:
> On 30.09.2022 12:22, Anthony PERARD wrote:
> > On Fri, Sep 30, 2022 at 08:31:20AM +0200, Jan Beulich wrote:
> >> On 29.09.2022 18:25, Andrew Cooper wrote:
> >>> On 29/09/2022 17:22, osstest service owner wrote:
> >>>> flight 173362 xen-unstable-smoke real [real]
> >>>> http://logs.test-lab.xenproject.org/osstest/logs/173362/
> >>>>
> >>>> Regressions :-(
> >>>>
> >>>> Tests which did not succeed and are blocking,
> >>>> including tests which could not be run:
> >>>>  build-arm64-xsm               6 xen-build                fail REGR. vs. 
> >>>> 173347
> >>>
> >>> arch/arm/gic-v3-its.c: In function 'gicv3_its_deny_access':
> >>> arch/arm/gic-v3-its.c:905:32: error: passing argument 1 of
> >>> 'iomem_deny_access' discards 'const' qualifier from pointer target type
> >>> [-Werror=discarded-qualifiers]
> >>>          rc = iomem_deny_access(d, mfn, mfn + nr);
> >>>                                 ^
> >>> In file included from arch/arm/gic-v3-its.c:24:
> >>> ./include/xen/iocap.h:32:52: note: expected 'struct domain *' but
> >>> argument is of type 'const struct domain *'
> >>>  static inline int iomem_deny_access(struct domain *d, unsigned long s,
> >>>                                      ~~~~~~~~~~~~~~~^
> >>> cc1: all warnings being treated as errors
> >>
> >> I've sent a patch, but this raises another question: Why does the smoke
> >> test (try to) build an unsupported configuration? HAS_ITS (which is
> >> necessary to be set for the issue to surface) has its prompt depend on
> >> UNSUPPORTED, and (implicitly) defaults to N.
> > 
> > According to osstest sources:
> >     # ITS driver is required to boot the Hardware Domain
> >     # on Xen. For now (Xen 4.10/4.11 at at least),
> >     # will be not built by default and gated by expert mode
> >     echo >>xen/.config CONFIG_HAS_ITS=y
> 
> Hmm, that's been quite a number of revisions back, without things having
> changed. Arm maintainers - what's the plan here? What use is it to test
> an unsupported configuration (for years)?

This issue is non-trivial. On my side, I still don't have easy access to
hardware with ITS in it. This will change in the future, but we are not
there yet. So as of now I couldn't "support" ITS.


> But there's a more general aspect here: EXPERT is forced to Y here as
> well, which is fine by itself. But it implies UNSUPPORTED also getting
> enabled. That latter aspect is what I consider wrong for smoke flights
> at least. Yet (as said) HAS_ITS depends on it (and its setting to Y by
> the script would have no effect if UNSUPPORTED was off).

I agree with you, but I don't have a solution to offer due to the above.