[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[xen-4.3-testing test] 64434: regressions - FAIL



flight 64434 xen-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/64434/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-migrupgrade 21 guest-migrate/src_host/dst_host fail REGR. vs. 
63212

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail pass in 
64287

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop    fail in 64287 like 63212

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)               blocked n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  9 debian-hvm-install     fail never pass
 build-i386-rumpuserxen        6 xen-build                    fail   never pass
 build-amd64-rumpuserxen       6 xen-build                    fail   never pass
 test-amd64-i386-migrupgrade 21 guest-migrate/src_host/dst_host fail never pass
 test-armhf-armhf-libvirt-qcow2  6 xen-boot                     fail never pass
 test-armhf-armhf-libvirt      6 xen-boot                     fail   never pass
 test-amd64-i386-libvirt      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2   6 xen-boot                     fail   never pass
 test-armhf-armhf-libvirt-raw  6 xen-boot                     fail   never pass
 test-armhf-armhf-xl-arndale   6 xen-boot                     fail   never pass
 test-armhf-armhf-xl           6 xen-boot                     fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop              fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-multivcpu  6 xen-boot                     fail  never pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  9 debian-hvm-install      fail never pass
 test-armhf-armhf-xl-cubietruck  6 xen-boot                     fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop              fail never pass
 test-armhf-armhf-xl-vhd       6 xen-boot                     fail   never pass
 test-amd64-amd64-libvirt     12 migrate-support-check        fail   never pass
 test-amd64-i386-xend-qemut-winxpsp3 21 leak-check/check        fail never pass

version targeted for testing:
 xen                  fd1e4cc4d1d100337931b6f6dc50ed0b9766968a
baseline version:
 xen                  85ca813ec23c5a60680e4a13777dad530065902b

Last test of basis    63212  2015-10-22 10:03:01 Z   25 days
Failing since         63360  2015-10-29 13:39:04 Z   18 days   13 attempts
Testing same since    64090  2015-11-10 18:01:42 Z    6 days    4 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  Ian Campbell <ian.campbell@xxxxxxxxxx>
  Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
  Jan Beulich <jbeulich@xxxxxxxx>

jobs:
 build-amd64                                                  pass
 build-armhf                                                  pass
 build-i386                                                   pass
 build-amd64-libvirt                                          pass
 build-armhf-libvirt                                          pass
 build-i386-libvirt                                           pass
 build-amd64-prev                                             pass
 build-i386-prev                                              pass
 build-amd64-pvops                                            pass
 build-armhf-pvops                                            pass
 build-i386-pvops                                             pass
 build-amd64-rumpuserxen                                      fail
 build-i386-rumpuserxen                                       fail
 test-amd64-amd64-xl                                          pass
 test-armhf-armhf-xl                                          fail
 test-amd64-i386-xl                                           pass
 test-amd64-i386-qemut-rhel6hvm-amd                           pass
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass
 test-amd64-i386-freebsd10-amd64                              pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         fail
 test-amd64-i386-xl-qemuu-ovmf-amd64                          fail
 test-amd64-amd64-rumpuserxen-amd64                           blocked
 test-amd64-amd64-xl-qemut-win7-amd64                         fail
 test-amd64-i386-xl-qemut-win7-amd64                          fail
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail
 test-amd64-i386-xl-qemuu-win7-amd64                          fail
 test-armhf-armhf-xl-arndale                                  fail
 test-amd64-amd64-xl-credit2                                  pass
 test-armhf-armhf-xl-credit2                                  fail
 test-armhf-armhf-xl-cubietruck                               fail
 test-amd64-i386-freebsd10-i386                               pass
 test-amd64-i386-rumpuserxen-i386                             blocked
 test-amd64-i386-qemut-rhel6hvm-intel                         pass
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass
 test-amd64-amd64-libvirt                                     pass
 test-armhf-armhf-libvirt                                     fail
 test-amd64-i386-libvirt                                      pass
 test-amd64-amd64-migrupgrade                                 fail
 test-amd64-i386-migrupgrade                                  fail
 test-amd64-amd64-xl-multivcpu                                pass
 test-armhf-armhf-xl-multivcpu                                fail
 test-amd64-amd64-pair                                        pass
 test-amd64-i386-pair                                         pass
 test-amd64-amd64-pv                                          pass
 test-amd64-i386-pv                                           pass
 test-amd64-amd64-amd64-pvgrub                                pass
 test-amd64-amd64-i386-pvgrub                                 pass
 test-amd64-amd64-pygrub                                      pass
 test-armhf-armhf-libvirt-qcow2                               fail
 test-amd64-amd64-xl-qcow2                                    pass
 test-armhf-armhf-libvirt-raw                                 fail
 test-amd64-i386-xl-raw                                       pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     pass
 test-amd64-amd64-libvirt-vhd                                 pass
 test-armhf-armhf-xl-vhd                                      fail
 test-amd64-i386-xend-qemut-winxpsp3                          fail
 test-amd64-amd64-xl-qemut-winxpsp3                           pass
 test-amd64-amd64-xl-qemuu-winxpsp3                           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 fd1e4cc4d1d100337931b6f6dc50ed0b9766968a
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Tue Nov 10 12:23:43 2015 +0100

    x86/HVM: always intercept #AC and #DB

    Both being benign exceptions, and both being possible to get triggered
    by exception delivery, this is required to prevent a guest from locking
    up a CPU (resulting from no other VM exits occurring once getting into
    such a loop).

    The specific scenarios:

    1) #AC may be raised during exception delivery if the handler is set to
    be a ring-3 one by a 32-bit guest, and the stack is misaligned.

    This is CVE-2015-5307 / XSA-156.

    Reported-by: Benjamin Serebrin <serebrin@xxxxxxxxxx>

    2) #DB may be raised during exception delivery when a breakpoint got
    placed on a data structure involved in delivering the exception. This
    can result in an endless loop when a 64-bit guest uses a non-zero IST
    for the vector 1 IDT entry, but even without use of IST the time it
    takes until a contributory fault would get raised (results depending
    on the handler) may be quite long.

    This is CVE-2015-8104 / XSA-156.

    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Tested-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    master commit: bd2239d9fa975a1ee5bcd27c218ae042cd0a57bc
    master date: 2015-11-10 12:03:08 +0100

commit e875e0e5fcc5912f71422b53674a97e5c0ae77be
Author: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
Date:   Wed Oct 21 16:18:30 2015 +0100

    libxl: adjust PoD target by memory fudge, too

    PoD guests need to balloon at least as far as required by PoD, or risk
    crashing.  Currently they don't necessarily know what the right value
    is, because our memory accounting is (at the very least) confusing.

    Apply the memory limit fudge factor to the in-hypervisor PoD memory
    target, too.  This will increase the size of the guest's PoD cache by
    the fudge factor LIBXL_MAXMEM_CONSTANT (currently 1Mby).  This ensures
    that even with a slightly-off balloon driver, the guest will be
    stable even under memory pressure.

    There are two call sites of xc_domain_set_pod_target that need fixing:

    The one in libxl_set_memory_target is straightforward.

    The one in xc_hvm_build_x86.c:setup_guest is more awkward.  Simply
    setting the PoD target differently does not work because the various
    amounts of memory during domain construction no longer match up.
    Instead, we adjust the guest memory target in xenstore (but only for
    PoD guests).

    This introduces a 1Mby discrepancy between the balloon target of a PoD
    guest at boot, and the target set by an apparently-equivalent `xl
    mem-set' (or similar) later.  This approach is low-risk for a security
    fix but we need to fix this up properly in xen.git#staging and
    probably also in stable trees.

    This is XSA-153.

    Signed-off-by: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>
    (cherry picked from commit 56fb5fd62320eb40a7517206f9706aa9188d6f7b)
    (cherry picked from commit 423d2cd814e8460d5ea8bd191a770f3c48b3947c)

    Conflicts:
        tools/libxl/libxl_dom.c
    Signed-off-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
    (cherry picked from commit 73b70e3c5d59e63126c890068ee0cbf8a2a3b640)

commit 9f359c61e3927f94bb280ffb200155dd20465fda
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Thu Oct 29 14:28:33 2015 +0100

    x86: rate-limit logging in do_xen{oprof,pmu}_op()

    Some of the sub-ops are acessible to all guests, and hence should be
    rate-limited. In the xenoprof case, just like for XSA-146, include them
    only in debug builds. Since the vPMU code is rather new, allow them to
    be always present, but downgrade them to (rate limited) guest messages.

    This is CVE-2015-7971 / XSA-152.

    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
    master commit: 95e7415843b94c346e5ba8682665f508f220e04b
    master date: 2015-10-29 13:37:19 +0100

commit 7f28d311a80e9d33d8270d6fb7b949dd4eef37f0
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Thu Oct 29 14:28:06 2015 +0100

    xenoprof: free domain's vcpu array

    This was overlooked in fb442e2171 ("x86_64: allow more vCPU-s per
    guest").

    This is CVE-2015-7969 / XSA-151.

    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
    master commit: 6e97c4b37386c2d09e09e9b5d5d232e37728b960
    master date: 2015-10-29 13:36:52 +0100

commit 2d330c121eff67f4828dc8536180986e0dfdf14b
Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Date:   Thu Oct 29 14:27:44 2015 +0100

    x86/PoD: Eager sweep for zeroed pages

    Based on the contents of a guests physical address space,
    p2m_pod_emergency_sweep() could degrade into a linear memcmp() from 0 to
    max_gfn, which runs non-preemptibly.

    As p2m_pod_emergency_sweep() runs behind the scenes in a number of contexts,
    making it preemptible is not feasible.

    Instead, a different approach is taken.  Recently-populated pages are 
eagerly
    checked for reclaimation, which amortises the p2m_pod_emergency_sweep()
    operation across each p2m_pod_demand_populate() operation.

    Note that in the case that a 2M superpage can't be reclaimed as a superpage,
    it is shattered if 4K pages of zeros can be reclaimed.  This is unfortunate
    but matches the previous behaviour, and is required to avoid regressions
    (domain crash from PoD exhaustion) with VMs configured close to the limit.

    This is CVE-2015-7970 / XSA-150.

    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: George Dunlap <george.dunlap@xxxxxxxxxx>
    master commit: 101ce53266866144e724ed593173bc4098b300b9
    master date: 2015-10-29 13:36:25 +0100

commit d7f7c5c6559ac3fa52dba5d8fe952b2c00f962db
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Thu Oct 29 14:27:02 2015 +0100

    free domain's vcpu array

    This was overlooked in fb442e2171 ("x86_64: allow more vCPU-s per
    guest").

    This is CVE-2015-7969 / XSA-149.

    Reported-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
    master commit: d46896ebbb23f3a9fef2eb6066ae614fd1acfd96
    master date: 2015-10-29 13:35:40 +0100

commit 3be91e6c200af155a1badefc5945008c8da12ce7
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Thu Oct 29 14:24:40 2015 +0100

    x86: guard against undue super page PTE creation

    When optional super page support got added (commit bd1cd81d64 "x86: PV
    support for hugepages"), two adjustments were missed: mod_l2_entry()
    needs to consider the PSE and RW bits when deciding whether to use the
    fast path, and the PSE bit must not be removed from L2_DISALLOW_MASK
    unconditionally.

    This is CVE-2015-7835 / XSA-148.

    Reported-by: "栾��(好�)" <shangcong.lsc@xxxxxxxxxxxxxxx>
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Tim Deegan <tim@xxxxxxx>
    master commit: fe360c90ea13f309ef78810f1a2b92f2ae3b30b8
    master date: 2015-10-29 13:35:07 +0100

commit fb02dec2d06a2dd104682973a21375795e344e25
Author: Ian Campbell <ian.campbell@xxxxxxxxxx>
Date:   Thu Oct 29 14:24:17 2015 +0100

    arm: handle races between relinquish_memory and free_domheap_pages

    Primarily this means XENMEM_decrease_reservation from a toolstack
    domain.

    Unlike x86 we have no requirement right now to queue such pages onto
    a separate list, if we hit this race then the other code has already
    fully accepted responsibility for freeing this page and therefore
    there is no more for relinquish_memory to do.

    This is CVE-2015-7814 / XSA-147.

    Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
    Reviewed-by: Julien Grall <julien.grall@xxxxxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
    master commit: 1ef01396fdff88b1c3331a09ca5c69619b90f4ea
    master date: 2015-10-29 13:34:17 +0100

commit e06f1c36d36260b7d82f8563f1a6f226160d4b23
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Thu Oct 29 14:23:35 2015 +0100

    AMD Vi: fix HPET ID check

    Cherry picked from commit 2ca9fbd739 ("AMD IOMMU: allocate IRTE entries
    instead of using a static mapping") mainly to fix build with gcc 5.x.

    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>

commit 39698f92e4185afdd956e9af6888923c27728875
Author: Ian Campbell <ian.campbell@xxxxxxxxxx>
Date:   Thu Oct 29 14:10:31 2015 +0100

    xen: common: Use unbounded array for symbols_offset.

    Using a singleton array causes gcc5 to report:
    symbols.c: In function 'symbols_lookup':
    symbols.c:128:359: error: array subscript is above array bounds 
[-Werror=array-bounds]
    symbols.c:136:176: error: array subscript is above array bounds 
[-Werror=array-bounds]

    Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
    Acked-by: Jan Beulich <jbeulich@xxxxxxxx>
    master commit: 3f82ea62826d4eb06002d8dba475bafcc454b845
    master date: 2015-03-20 12:02:03 +0000
========================================

_______________________________________________
osstest-output mailing list
osstest-output@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/osstest-output

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.