[Xen-devel] [xen-unstable-smoke test] 141778: regressions - FAIL

[osstest service owner <osstest-admin@xxxxxxxxxxxxxx>]

flight 141778 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141778/

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. 141763
 build-armhf                   6 xen-build                fail REGR. vs. 141763

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

version targeted for testing:
 xen                  d07bdb43f253da6ecf79f77cc66c9f232eb9d673
baseline version:
 xen                  df29d03f1d97bdde1bc0cea8ef8538d4f524b3ec

Last test of basis   141763  2019-09-24 13:01:57 Z    0 days
Testing same since   141778  2019-09-24 17:01:08 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Dario Faggioli <dfaggioli@xxxxxxxx>
  Juergen Gross <jgross@xxxxxxxx>

jobs:
 build-arm64-xsm                                              fail    
 build-amd64                                                  pass    
 build-armhf                                                  fail    
 build-amd64-libvirt                                          pass    
 test-armhf-armhf-xl                                          blocked 
 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 d07bdb43f253da6ecf79f77cc66c9f232eb9d673
Author: Juergen Gross <jgross@xxxxxxxx>
Date:   Tue Sep 24 17:11:38 2019 +0200

    sched: switch to debugtrace in cpupool handling
    
    Instead of having a cpupool_dprintk() define just use debugtrace.
    
    Signed-off-by: Juergen Gross <jgross@xxxxxxxx>
    Acked-by: Dario Faggioli <dfaggioli@xxxxxxxx>

commit f855dd962523b6cb47a92037bdd28b1485141abe
Author: Juergen Gross <jgross@xxxxxxxx>
Date:   Tue Sep 24 17:11:02 2019 +0200

    sched: add minimalistic idle scheduler for free cpus
    
    Instead of having a full blown scheduler running for the free cpus
    add a very minimalistic scheduler for that purpose only ever scheduling
    the related idle vcpu. This has the big advantage of not needing any
    per-cpu, per-domain or per-scheduling unit data for free cpus and in
    turn simplifying moving cpus to and from cpupools a lot.
    
    Right now, CPUs that are not in any pool, still belong to Pool-0's
    scheduler. This forces us to make, within the scheduler, extra effort
    to avoid actually running vCPUs on those.
    
    In the case of Credit1, this also cause issue to weights
    (re)distribution, as the number of CPUs available to the scheduler is
    wrong.
    
    This is described in the changelog of commit e7191920261d ("xen:
    credit2: never consider CPUs outside of our cpupool").
    
    This new scheduler will just use a common lock for all free cpus.
    
    As this new scheduler is not user selectable don't register it as an
    official scheduler, but just include it in schedule.c.
    
    Signed-off-by: Juergen Gross <jgross@xxxxxxxx>
    Acked-by: Dario Faggioli <dfaggioli@xxxxxxxx>

commit 73d1d61fa9de31575d7631a3390d70ba154d151b
Author: Juergen Gross <jgross@xxxxxxxx>
Date:   Tue Sep 24 17:10:06 2019 +0200

    sched: remove cpu from pool0 before removing it
    
    Today a cpu which is removed from the system is taken directly from
    Pool0 to the offline state. This will conflict with the new idle
    scheduler, so remove it from Pool0 first. Additionally accept removing
    a free cpu instead of requiring it to be in Pool0.
    
    For the resume failed case we need to call the scheduler code for that
    situation after the cpupool handling, so move the scheduler code into
    a function and call it from cpupool_cpu_remove_forced() and remove the
    CPU_RESUME_FAILED case from cpu_schedule_callback().
    
    Note that we are calling now schedule_cpu_switch() in stop_machine
    context so we need to switch from spinlock_irq to spinlock_irqsave.
    
    Signed-off-by: Juergen Gross <jgross@xxxxxxxx>
    Reviewed-by: Dario Faggioli <dfaggioli@xxxxxxxx>
    Tested-by: Dario Faggioli <dfaggioli@xxxxxxxx>
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel