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

[Xen-devel] [xen-4.3-testing test] 34153: regressions - FAIL

flight 34153 xen-4.3-testing real [real]

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-win7-amd64  7 windows-install          fail REGR. vs. 33687

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install          fail like 33687

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)               blocked n/a
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 debian-hvm-install      fail never pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64  7 debian-hvm-install     fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-armhf-armhf-xl-sedf      5 xen-boot                     fail   never pass
 test-armhf-armhf-xl-credit2   5 xen-boot                     fail   never pass
 build-amd64-rumpuserxen       6 xen-build                    fail   never pass
 test-armhf-armhf-xl-midway    5 xen-boot                     fail   never pass
 test-armhf-armhf-xl-sedf-pin  5 xen-boot                     fail   never pass
 test-armhf-armhf-xl           5 xen-boot                     fail   never pass
 test-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-armhf-armhf-xl-multivcpu  5 xen-boot                     fail  never pass
 build-i386-rumpuserxen        6 xen-build                    fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 17 leak-check/check        fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xend-winxpsp3 17 leak-check/check             fail  never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass

version targeted for testing:
 xen                  ef73de2a84a3042c3481c9a521e8e0c756b793f2
baseline version:
 xen                  f70c066bb55ed967a8e98bf30a50cf0a7a6155f9

People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>
  Dan Carpenter <dan.carpenter@xxxxxxxxxx>
  Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>
  Ian Campbell <ian.campbell@xxxxxxxxxx>
  Jan Beulich <jbeulich@xxxxxxxx>
  Kevin Tian <kevin.tian@xxxxxxxxx>
  Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
  Tim Deegan <tim@xxxxxxx>

 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           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-rhel6hvm-amd                                 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-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-amd64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  fail    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 test-armhf-armhf-xl-midway                                   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-xl-sedf-pin                                 pass    
 test-armhf-armhf-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-armhf-armhf-xl-sedf                                     fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    

sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at

Test harness code can be found at

Not pushing.

commit ef73de2a84a3042c3481c9a521e8e0c756b793f2
Author: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
Date:   Tue Feb 3 15:30:13 2015 +0100

    bunzip2: off by one in get_next_block()
    "origPtr" is used as an offset into the bd->dbuf[] array.  That array is
    allocated in start_bunzip() and has "bd->dbufSize" number of elements so
    the test here should be >= instead of >.
    Later we check "origPtr" again before using it as an offset so I don't
    know if this bug can be triggered in real life.
    Signed-off-by: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
    Trivial adjustments to make the respective Linux commit
    b5c8afe5be51078a979d86ae5ae78c4ac948063d apply to Xen.
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Acked-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
    master commit: 39798e95a954eec660a3f5f21489c30ef78daf6d
    master date: 2015-01-28 16:50:08 +0100

commit 47266d66b35572b7d2f7b7a5f53d6eab05604cd2
Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Date:   Tue Feb 3 15:29:41 2015 +0100

    docs/commandline: correct information for 'x2apic_phys' parameter
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    master commit: 89c381c30b46ec714f2d5bef4b0cb6d759abc7e4
    master date: 2015-01-28 16:31:07 +0100

commit 22d7558fbd22d68221234f0d03c2a042e554ed28
Author: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Date:   Tue Feb 3 15:28:58 2015 +0100

    x86: vcpu_destroy_pagetables() must not return -EINTR
    .. otherwise it has the side effect that: domain_relinquish_resources
    will stop and will return to user-space with -EINTR which it is not
    equipped to deal with that error code; or vcpu_reset - which will
    ignore it and convert the error to -ENOMEM..
    The preemption mechanism we have for domain destruction is to return
    -EAGAIN (and then user-space calls the hypercall again) and as such we need
    to catch the case of:
        -> put_page_and_type_preemptible
           -> __put_page_type
               returns -EINTR
    and convert it to the proper type. For:
     -> vcpu_reset
       -> vcpu_destroy_pagetables
    we need to return -ERESTART otherwise we end up returning -ENOMEM.
    There are also other callers of vcpu_destroy_pagetables: arch_vcpu_reset
    (vcpu_reset) are:
     - hvm_s3_suspend (asserts on any return code),
     - vlapic_init_sipi_one (asserts on any return code),
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    master commit: de4f284b3d7b47d3b9807f354552ecf3e0fff56b
    master date: 2015-01-26 12:51:09 +0100

commit 1c81b665b5bb7b57abeeea0e004fdc2c80c97608
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Tue Feb 3 15:28:29 2015 +0100

    x86: correctly check for sub-leaf zero of leaf 7 in pv_cpuid()
    Only the low 32 bits are relevant.
    For consistency also change a cast on regs->eax to regs->_eax.
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    master commit: ae1edef1ae33f3bcff2580116ae2b7c9ffef42f2
    master date: 2015-01-22 12:48:40 +0100

commit 28f44faed97a3c935cfaf3737828deb5f9c1dad1
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Tue Feb 3 15:27:56 2015 +0100

    x86: don't expose XSAVES capability to PV guests
    As done by the recent Linux commit b65d6e17fe ("kvm: x86: mask out
    XSAVES") for KVM, we should also mask out XSAVES from what PV guests
    get to see as long as we don't emulate accesses to MSR_IA32_XSS.
    Actually, go beyond that: Just like for leaf 7, switch from
    blacklisting to whitelisting, i.e. only allow XSAVEOPT and XSAVEC for
    the time being. And do these overrides consistently for both Dom0 and
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    master commit: 8d050ed1097ce5f4bf6a1d6806fb1e3471976adb
    master date: 2015-01-22 12:47:56 +0100

commit 461a8d3916a77695b4137c6b27e7c434e03035ff
Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Date:   Tue Feb 3 15:27:18 2015 +0100

    xsm/evtchn: never pretend to have successfully created a Xen event channel
    Xen event channels are not internal resources.  They still have one end in a
    domain, and are created at the request of privileged domains.  This logic
    which "successfully" creates a Xen event channel opens up undesirable 
    cases with ill-specified XSM policies.
    If a domain is permitted to create ioreq servers or memevent listeners, but
    not to create event channels, the ioreq/memevent creation will succeed but
    attempting to bind the returned event channel will fail without any 
    of a permission error.
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Acked-by: Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>
    master commit: 09aa4759faa29c1fe735266de4c79f17329bd67b
    master date: 2015-01-20 10:42:26 +0100

commit dd971e41820dc33e1da1c429dfc3c7ee32b4795e
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Tue Feb 3 15:26:48 2015 +0100

    common/memory: fix an XSM error path
    XENMEM_{in,de}crease_reservation as well as XENMEM_populate_physmap
    return the extent at which failure was detected, not error indicators.
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Acked-by: Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>
    Acked-by: Tim Deegan <tim@xxxxxxx>
    master commit: 76d4ff26d9647088353acaf4a56388a354a5d6e9
    master date: 2015-01-19 11:59:05 +0100

commit 5bea1d935e48097c1725bc4162e72fb4f313adf8
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Tue Feb 3 15:26:16 2015 +0100

    x86emul: tighten CLFLUSH emulation
    While for us it's not as bad as it was for Linux, their commit
    13e457e0ee ("KVM: x86: Emulator does not decode clflush well", by
    Nadav Amit <namit@xxxxxxxxxxxxxxxxx>) nevertheless points out two
    shortcomings in our code: opcode 0F AE /7 is clflush only when it uses
    a memory mode (otherwise it's SFENCE) and when there's no REP prefix
    (an operand size prefix is fine, as that's CLFLUSHOPT).
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Acked-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    master commit: 9d03db6b81d1880bf3aa4fc83a60346bf02be251
    master date: 2015-01-12 15:41:12 +0100

commit 4de472720da0fc56e2a073e2ac94132455c7a1cb
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Tue Feb 3 15:24:45 2015 +0100

    VT-d: don't crash when PTE bits 52 and up are non-zero
    This can (and will) be legitimately the case when sharing page tables
    with EPT (more of a problem before p2m_access_rwx became zero, but
    still possible even now when other than that is the default for a
    guest), leading to an unconditional crash (in print_vtd_entries())
    when a DMA remapping fault occurs.
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Kevin Tian <kevin.tian@xxxxxxxxx>
    master commit: 46e0baf59105200d43612cf0c59de216958b008d
    master date: 2015-01-07 11:13:58 +0100

commit 34effcd03d682e3a264ead2fe7a2a67cb4fe6a35
Author: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>
Date:   Tue Feb 3 15:23:38 2015 +0100

    x86/VPMU: Clear last_vcpu when destroying VPMU
    We need to make sure that last_vcpu is not pointing to VCPU whose
    VPMU is being destroyed. Otherwise we may try to dereference it in
    the future, when VCPU is gone.
    We have to do this via IPI since otherwise there is a (somewheat
    theoretical) chance that between test and subsequent clearing
    of last_vcpu the remote processor (i.e. vpmu->last_pcpu) might do
    both vpmu_load() and then vpmu_save() for another VCPU. The former
    will clear last_vcpu and the latter will set it to something else.
    Performing this operation via IPI will guarantee that nothing can
    happen on the remote processor between testing and clearing of
    We should also check for VPMU_CONTEXT_ALLOCATED in vpmu_destroy() to
    avoid unnecessary percpu tests and arch-specific destroy ops. Thus
    checks in AMD and Intel routines are no longer needed.
    Signed-off-by: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>
    Acked-by: Kevin Tian <kevin.tian@xxxxxxxxx>
    master commit: ed8017155607db1bbe1f6ca41eac696b7ef8082b
    master date: 2015-01-07 11:12:27 +0100

commit 0f5a611cb586d5109bf7a3ecee9a71202c93126d
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Tue Feb 3 15:22:32 2015 +0100

    domctl: fix IRQ permission granting/revocation
    Commit 545607eb3c ("x86: fix various issues with handling guest IRQs")
    wasn't really consistent in one respect: The granting of access to an
    IRQ shouldn't assume the pIRQ->IRQ translation to be the same in both
    domains. In fact it is wrong to assume that a translation is already/
    still in place at the time access is being granted/revoked.
    What is wanted is to translate the incoming pIRQ to an IRQ for
    the invoking domain (as the pIRQ is the only notion the invoking
    domain has of the IRQ), and grant the subject domain access to
    the resulting IRQ.
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reported-by: Sander Eikelenboom <linux@xxxxxxxxxxxxxx>
    Acked-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
    master commit: 6fb3a07bc0ad656b5f76eb9fc961bcd1d3cace58
    master date: 2015-01-05 10:20:24 -0500
(qemu changes not included)

Xen-devel mailing list



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