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

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

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl           6 xen-boot                  fail REGR. vs. 85661

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt     12 migrate-support-check        fail   never pass

version targeted for testing:
 xen                  6890e07e483673ec5f946b7c4654275707924d6d
baseline version:
 xen                  0aa1330aac92fd75f185c9b354396014178fe95d

Last test of basis    85661  2016-03-07 18:02:23 Z    1 days
Testing same since    85819  2016-03-09 16:02:00 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  Dario Faggioli <dario.faggioli@xxxxxxxxxx>
  George Dunlap <george.dunlap@xxxxxxxxxxxxx>
  Jan Beulich <jbeulich@xxxxxxxx>
  Juergen Gross <jgross@xxxxxxxx>

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-amd64-libvirt                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-amd64-xl-qemuu-debianhvm-i386                     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 6890e07e483673ec5f946b7c4654275707924d6d
Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Date:   Wed Mar 9 16:52:31 2016 +0100

    mm: fix page_list_* helpers to evaluate all their arguments
    
    If an architecture does not provide a custom page_list_entry, default
    page_list_* helpers are provided, wrapping list_head as an underlying type 
for
    page_list_head.
    
    The two declarations of the page_list_* helpers differ between defines and
    static inline functions, where the defines discard some of their parameters.
    
    This causes a compilation failure if CONFIG_BIGMEM and debug=n in p2m-pod.c:
    
      p2m-pod.c: In function Â?p2m_pod_cache_addÂ?:
      p2m-pod.c:72:20: error: unused variable Â?dÂ? [-Werror=unused-variable]
           struct domain *d = p2m->domain;
                          ^
      cc1: all warnings being treated as errors
    
    because the use of d outside of the !NDEBUG section doesn't get evaluated 
as a
    parameter by page_list_del().
    
    Fix this by turning all #defines into static inline functions, so all
    parameters are evaluated even if they are not used.
    
    While editing this area, correct the return type of page_list_empty from int
    to bool_t.
    
    No functional change.
    
    Reported-by: Doug Goldstein <cardoe@xxxxxxxxxx>
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Reviewed-by: Doug Goldstein <cardoe@xxxxxxxxxx>
    Acked-by: George Dunlap <george.dunlap@xxxxxxxxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>

commit 8979888d2d67ea6976438d392420dbc84f3868e4
Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Date:   Wed Mar 9 16:51:50 2016 +0100

    mm: introduce arch_free_heap_page()
    
    common/page_alloc.c references d->arch.relmem_list, which only exists on 
x86.
    This only compiles on ARM because page_list_del2() discards its second
    argument.
    
    Introduce a new common arch_free_heap_page() which only uses common lists in
    struct domain, and allow an architecture to override this with a custom
    alternative.  x86 then provides a custom arch_free_heap_page() which takes
    care of managing d->arch.relmem_list.
    
    No functional change.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Acked-by: Jan Beulich <jbeulich@xxxxxxxx>

commit cd29140ef0e65a33d62e7f5ee843077e51913f01
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Wed Mar 9 16:51:16 2016 +0100

    x86/alternatives: correct near branch check
    
    Make sure the near JMP/CALL check doesn't consume uninitialized
    data, not even in a benign way. And relax the length check at once.
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>

commit 882b186d56f1b294b57ea95dd1d83bc25def3c60
Author: Juergen Gross <jgross@xxxxxxxx>
Date:   Wed Mar 9 16:50:29 2016 +0100

    domctl: add force flag to xen_domctl_vcpuaffinity for undoing pin override
    
    Add a XEN_VCPUAFFINITY_FORCE flag to xen_domctl_vcpuaffinity structure
    which will allow to undo a SCHEDOP_pin_override in case of a driver
    error of the hardware domain which didn't do the expected
    SCHEDOP_pin_override with cpu < 0 which would have done the undo
    operation.
    
    Signed-off-by: Juergen Gross <jgross@xxxxxxxx>
    Acked-by: Jan Beulich <jbeulich@xxxxxxxx>

commit 8fa0fca9f3fdaac1aead9cf61d678a0d8cce02e2
Author: Juergen Gross <jgross@xxxxxxxx>
Date:   Wed Mar 9 16:49:59 2016 +0100

    sched: add hypercall option to override and restore vcpu affinity
    
    Some hardware (e.g. Dell studio 1555 laptops) require SMIs to be
    called on physical cpu 0 only. Linux drivers like dcdbas or i8k try
    to achieve this by pinning the running thread to cpu 0, but in Dom0
    this is not enough: the vcpu must be pinned to physical cpu 0 via
    Xen, too.
    
    Add a stable hypercall option SCHEDOP_pin_override to the sched_op
    hypercall to achieve this. It is taking a physical cpu number as
    parameter. If pinning is possible (the calling domain has the
    privilege to make the call and the cpu is available in the domain's
    cpupool) the calling vcpu is pinned to the specified cpu. The old
    cpu affinity is saved. To undo the override pinning a negative cpu
    value is specified. This will restore the original cpu affinity of
    the vcpu.
    
    Signed-off-by: Juergen Gross <jgross@xxxxxxxx>
    Acked-by: Dario Faggioli <dario.faggioli@xxxxxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>

commit d62ead2eb23491de50cf65f548d66c2e433de455
Author: Juergen Gross <jgross@xxxxxxxx>
Date:   Wed Mar 9 16:44:04 2016 +0100

    cpupool: correct error handling when removing cpu from cpupool
    
    When schedule_cpu_switch() called from cpupool_unassign_cpu_helper()
    returns an error, the domlist_read_lock isn't released again.
    
    As cpu_disable_scheduler() might have changed affinity of some
    domains domain_update_node_affinity() must be called for all domains
    in the cpupool even in error case.
    
    Even if looking weird it is okay to let the to be removed cpu set in
    cpupool_free_cpus in case of an error returned by
    cpu_disable_scheduler(). Add a comment explaining the reason for this.
    
    Signed-off-by: Juergen Gross <jgross@xxxxxxxx>
    Acked-by: Dario Faggioli <dario.faggioli@xxxxxxxxxx>
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel