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

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

[osstest service owner]

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

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm       1 build-check(1)               blocked  n/a
 test-amd64-amd64-libvirt     15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          16 saverestore-support-check    fail   never pass

version targeted for testing:
 xen                  b726541d94bd0a80b5864d17a2cd2e6d73a3fe0a
baseline version:
 xen                  211d8419ef8d8a237ff914fd8304b8fefc3ff2cc

Last test of basis   173347  2022-09-28 05:07:54 Z    1 days
Testing same since   173362  2022-09-29 13:03:03 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Anthony PERARD <anthony.perard@citrix.com>
  Dmytro Semenets <dmytro_semenets@epam.com>
  Jan Beulich <jbeulich@suse.com>
  Nathan Studer <nathan.studer@dornerworks.com>
  Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
  Roger Pau Monné <roger.pau@citrix.com>
  Stewart Hildebrand <stewart.hildebrand@dornerworks.com>

jobs:
 build-arm64-xsm                                              fail    
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-amd64-libvirt                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-arm64-arm64-xl-xsm                                      blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-amd64-libvirt                                     pass    


------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
    http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
    http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
commit b726541d94bd0a80b5864d17a2cd2e6d73a3fe0a
Author: Jan Beulich <jbeulich@suse.com>
Date:   Thu Sep 29 14:47:45 2022 +0200

    x86: wire up VCPUOP_register_vcpu_time_memory_area for 32-bit guests
    
    Forever sinced its introduction VCPUOP_register_vcpu_time_memory_area
    was available only to native domains. Linux, for example, would attempt
    to use it irrespective of guest bitness (including in its so called
    PVHVM mode) as long as it finds XEN_PVCLOCK_TSC_STABLE_BIT set (which we
    set only for clocksource=tsc, which in turn needs engaging via command
    line option).
    
    Fixes: a5d39947cb89 ("Allow guests to register secondary vcpu_time_info")
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Roger Pau Monné <roger.pau@citrix.com>
    Release-acked-by: Henry Wang <Henry.Wang@arm.com>

commit 9214da34a3cb017ff0417900250bd6d18ca89e15
Author: Jan Beulich <jbeulich@suse.com>
Date:   Thu Sep 29 14:46:50 2022 +0200

    x86: re-connect VCPUOP_send_nmi for 32-bit guests
    
    With the "inversion" of VCPUOP handling, processing arch-specific ones
    first, the forwarding of this sub-op from the (common) compat handler to
    (common) non-compat one did no longer have the intended effect. It now
    needs forwarding between the arch-specific handlers.
    
    Fixes: 8a96c0ea7999 ("xen: move do_vcpu_op() to arch specific code")
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
    Release-acked-by: Henry Wang <Henry.Wang@arm.com>

commit c4e5cc2ccc5b8274d02f7855c4769839989bb349
Author: Roger Pau Monné <roger.pau@citrix.com>
Date:   Thu Sep 29 14:44:10 2022 +0200

    x86/ept: limit calls to memory_type_changed()
    
    memory_type_changed() is currently only implemented for Intel EPT, and
    results in the invalidation of EMT attributes on all the entries in
    the EPT page tables.  Such invalidation causes EPT_MISCONFIG vmexits
    when the guest tries to access any gfns for the first time, which
    results in the recalculation of the EMT for the accessed page.  The
    vmexit and the recalculations are expensive, and as such should be
    avoided when possible.
    
    Remove the call to memory_type_changed() from
    XEN_DOMCTL_memory_mapping: there are no modifications of the
    iomem_caps ranges anymore that could alter the return of
    cache_flush_permitted() from that domctl.
    
    Encapsulate calls to memory_type_changed() resulting from changes to
    the domain iomem_caps or ioport_caps ranges in the helpers themselves
    (io{ports,mem}_{permit,deny}_access()), and add a note in
    epte_get_entry_emt() to remind that changes to the logic there likely
    need to be propagaed to the IO capabilities helpers.
    
    Note changes to the IO ports or memory ranges are not very common
    during guest runtime, but Citrix Hypervisor has an use case for them
    related to device passthrough.
    
    Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
    Reviewed-by: Jan Beulich <jbeulich@suse.com>

commit 9982fe275ba4ee1a749b6dde5602a5a79e42b543
Author: Roger Pau Monné <roger.pau@citrix.com>
Date:   Thu Sep 29 14:41:13 2022 +0200

    arm/vgic: drop const attribute from gic_iomem_deny_access()
    
    While correct from a code point of view, the usage of the const
    attribute for the domain parameter of gic_iomem_deny_access() is at
    least partially bogus.  Contents of the domain structure (the iomem
    rangeset) is modified by the function.  Such modifications succeed
    because right now the iomem rangeset is allocated separately from
    struct domain, and hence is not subject to the constness of struct
    domain.
    
    Amend this by dropping the const attribute from the function
    parameter.
    
    This is required by further changes that will convert
    iomem_{permit,deny}_access into a function.
    
    Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
    Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>

commit 0db195c1a9947240b354abbefd2afac6c73ad6a8
Author: Jan Beulich <jbeulich@suse.com>
Date:   Thu Sep 29 14:39:52 2022 +0200

    x86/NUMA: correct memnode_shift calculation for single node system
    
    SRAT may describe even a single node system (including such with
    multiple nodes, but only one having any memory) using multiple ranges.
    Hence simply counting the number of ranges (note that function
    parameters are mis-named) is not an indication of the number of nodes in
    use. Since we only care about knowing whether we're on a single node
    system, accounting for this is easy: Increment the local variable only
    when adjacent ranges are for different nodes. That way the count may
    still end up larger than the number of nodes in use, but it won't be
    larger than 1 when only a single node has any memory.
    
    To compensate populate_memnodemap() now needs to be prepared to find
    the correct node ID already in place for a range. (This could of course
    also happen when there's more than one node with memory, while at least
    one node has multiple adjacent ranges, provided extract_lsb_from_nodes()
    would also know to recognize this case.)
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Roger Pau Monné <roger.pau@citrix.com>

commit e1de23b7c1bfa02447a79733e64184b3635e0587
Author: Stewart Hildebrand <stewart.hildebrand@dornerworks.com>
Date:   Thu Sep 29 14:38:22 2022 +0200

    MAINTAINERS: ARINC 653 scheduler maintainer updates
    
    Add Nathan Studer as co-maintainer.
    
    I am departing DornerWorks. I will still be working with Xen in my next
    role, and I still have an interest in co-maintaining the ARINC 653
    scheduler, so change to my personal email address.
    
    Signed-off-by: Stewart Hildebrand <stewart.hildebrand@dornerworks.com>
    Acked-by: Nathan Studer <nathan.studer@dornerworks.com>

commit 3ab6ea992b0e5e1a332bdbc8ae56d72f1b66fcbd
Author: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
Date:   Thu Sep 29 14:38:02 2022 +0200

    tools: remove xenstore entries on vchan server closure
    
    vchan server creates XenStore entries to advertise its event channel and
    ring, but those are not removed after the server quits.
    Add additional cleanup step, so those are removed, so clients do not try
    to connect to a non-existing server.
    
    Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
    Signed-off-by: Dmytro Semenets <dmytro_semenets@epam.com>
    Reviewed-by: Juergen Gross <jgross@suse.com>
    Acked-by: Anthony PERARD <anthony.perard@citrix.com>
(qemu changes not included)

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

[Andrew Cooper]

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


Bug in 9982fe275ba4ee1a749b6dde5602a5a79e42b543.

~Andrew

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

[Jan Beulich]

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.

Jan

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

[Anthony PERARD]

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

https://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=ts-xen-build;h=c294a51eafc26e53b5417529b943224902870acf;hb=HEAD#l131

> 
> Jan
> 

-- 
Anthony PERARD

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

[Jan Beulich]

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)?

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).

Jan

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

[Roger Pau Monné]

On Thu, Sep 29, 2022 at 05:25:29PM +0100, 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

Hm, sorry.  I've tested on gitlab but seems like I didn't hit that
combination.

Roger.

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

[Stefano Stabellini]

[-- Attachment #1: Type: text/plain, Size: 2741 bytes --]

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.