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

[xen.org <ian.jackson@xxxxxxxxxxxxx>]

flight 24684 xen-4.3-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/24684/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-oldkern            4 xen-build                 fail REGR. vs. 24591

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-win7-amd64  7 windows-install           fail pass in 24676
 test-amd64-amd64-pair        16 guest-start        fail in 24676 pass in 24684

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

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemuu-win7-amd64 13 guest-stop              fail never pass
 test-armhf-armhf-xl           5 xen-boot                     fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop             fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop          fail in 24676 never pass

version targeted for testing:
 xen                  c450908dc9168c3f20787aab268fcc295feaed7d
baseline version:
 xen                  0ac5c121734c5055ba2b500b7f515a71800c7b20

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  Don Slutz <dslutz@xxxxxxxxxxx>
  Frediano Ziglio <frediano.ziglio@xxxxxxxxxx>
  Jan Beulich <jbeulich@xxxxxxxx>
  Jun Nakajima <jun.nakajima@xxxxxxxxx>
  Keir Fraser <keir@xxxxxxx>
  Mukesh Rathor <mukesh.rathor@xxxxxxxxxx>
  Tim Deegan <tim@xxxxxxx>
  Yang Zhang <yang.z.zhang@xxxxxxxxx>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 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-i386-freebsd10-amd64                              pass    
 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-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 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-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     pass    
 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 woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

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


Not pushing.

------------------------------------------------------------
commit c450908dc9168c3f20787aab268fcc295feaed7d
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Wed Jan 29 11:56:17 2014 +0100

    x86: don't drop guest visible state updates when 64-bit PV guest is in user 
mode
    
    Since 64-bit PV uses separate kernel and user mode page tables, kernel
    addresses (as usually provided via VCPUOP_register_runstate_memory_area
    and possibly via VCPUOP_register_vcpu_time_memory_area) aren't
    necessarily accessible when the respective updating occurs. Add logic
    for toggle_guest_mode() to take care of this (if necessary) the next
    time the vCPU switches to kernel mode.
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    master commit: 231d7f4098c8ac9cdb78f18fcb820d8618c8b0c2
    master date: 2014-01-23 10:30:08 +0100

commit affb7e6bc3d3db4880613cf012b8f6cee0fd9c07
Author: Yang Zhang <yang.z.zhang@xxxxxxxxx>
Date:   Wed Jan 29 11:55:41 2014 +0100

    Nested VMX: prohibit virtual vmentry/vmexit during IO emulation
    
    Sometimes, L0 needs to decode L2's instruction to handle IO access directly.
    And L0 may get X86EMUL_RETRY when handling this IO request. At same time, if
    there is a virtual vmexit pending (for example, an interrupt pending to 
inject
    to L1) and hypervisor will switch the VCPU context from L2 to L1. Now we
    already are in L1's context, but since we got a X86EMUL_RETRY just now and
    this means hypervisor will retry to handle the IO request later and
    unfortunately, the retry will happen in L1's context. And it will cause the
    problem. The fixing is that if there is a pending IO request, no virtual
    vmexit/vmentry is allowed.
    
    Signed-off-by: Yang Zhang <yang.z.zhang@xxxxxxxxx>
    Acked-by: Jun Nakajima <jun.nakajima@xxxxxxxxx>
    master commit: 09bb434748af9bfe3f7fca4b6eef721a7d5042a4
    master date: 2014-01-23 10:27:34 +0100

commit a4c215abc86dad8ccca4992f14f62550e5c02cf6
Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Date:   Wed Jan 29 11:54:32 2014 +0100

    common/sysctl: Don't leak status in SYSCTL_page_offline_op
    
    In addition, 'copyback' should be cleared even in the error case.
    
    Also fix the indentation of the arguments to copy_to_guest() to help clarify
    that the 'ret = -EFAULT' is not part of the condition.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
    Acked-by: Keir Fraser <keir@xxxxxxx>
    master commit: efd8ff0a04740a698b2b8b2b9adccd639e0fa6c9
    master date: 2014-01-20 09:48:11 +0100

commit f7d6d69edc9c98d25c2b2300eb925bec637d0b2e
Author: Yang Zhang <yang.z.zhang@xxxxxxxxx>
Date:   Wed Jan 29 11:54:02 2014 +0100

    nested EPT: fixing wrong handling for L2 guest's direct mmio access
    
    L2 guest will access the physical device directly(nested VT-d). For such 
access,
    Shadow EPT table should point to device's MMIO. But in current logic, L0 
doesn't
    distinguish the MMIO whether from qemu or physical device when building 
shadow EPT table.
    This is wrong. This patch will setup the correct shadow EPT table for such 
MMIO ranges.
    
    Signed-off-by: Yang Zhang <yang.z.zhang@xxxxxxxxx>
    Acked-by: Tim Deegan <tim@xxxxxxx>
    master commit: 0b988ba711171b39aed9851cfe90fded50f775c5
    master date: 2014-01-17 16:00:21 +0100

commit 9c5b7fb63a79570e4bc14fcbe2d15a23a0f1b433
Author: Frediano Ziglio <frediano.ziglio@xxxxxxxxxx>
Date:   Wed Jan 29 11:53:22 2014 +0100

    mce: fix race condition in mctelem_xchg_head
    
    The function (mctelem_xchg_head()) used to exchange mce telemetry
    list heads is racy.  It may write to the head twice, with the second
    write linking to an element in the wrong state.
    
    If there are two threads, T1 inserting on committed list; and T2
    trying to consume it.
    
    1. T1 starts inserting an element (A), sets prev pointer (mcte_prev).
    2. T1 is interrupted after the cmpxchg succeeded.
    3. T2 gets the list and changes element A and updates the commit list
       head.
    4. T1 resumes, reads pointer to prev again and compare with result
       from the cmpxchg which succeeded but in the meantime prev changed
       in memory.
    5. T1 thinks the cmpxchg failed and goes around the loop again,
       linking head to A again.
    
    To solve the race use temporary variable for prev pointer.
    
    *linkp (which point to a field in the element) must be updated before
    the cmpxchg() as after a successful cmpxchg the element might be
    immediately removed and reinitialized.
    
    The wmb() prior to the cmpchgptr() call is not necessary since it is
    already a full memory barrier.  This wmb() is thus removed.
    
    Signed-off-by: Frediano Ziglio <frediano.ziglio@xxxxxxxxxx>
    Reviewed-by: Liu Jinsong <jinsong.liu@xxxxxxxxx>
    master commit: e9af61b969906976188609379183cb304935f448
    master date: 2014-01-17 15:58:27 +0100

commit df75a2685c21158817092e34ee20cbf7ca770e75
Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Date:   Wed Jan 29 11:52:14 2014 +0100

    dbg_rw_guest_mem: need to call put_gfn in error path
    
    Using a 1G hvm domU (in grub) and gdbsx:
    
    (gdb) set arch i8086
    warning: A handler for the OS ABI "GNU/Linux" is not built into this 
configuration
    of GDB.  Attempting to continue with the default i8086 settings.
    
    The target architecture is assumed to be i8086
    (gdb) target remote localhost:9999
    Remote debugging using localhost:9999
    Remote debugging from host 127.0.0.1
    0x0000d475 in ?? ()
    (gdb) x/1xh 0x6ae9168b
    
    Will reproduce this bug.
    
    With a debug=y build you will get:
    
    Assertion '!preempt_count()' failed at preempt.c:37
    
    For a debug=n build you will get a dom0 VCPU hung (at some point) in:
    
             [ffff82c4c0126eec] _write_lock+0x3c/0x50
              ffff82c4c01e43a0  __get_gfn_type_access+0x150/0x230
              ffff82c4c0158885  dbg_rw_mem+0x115/0x360
              ffff82c4c0158fc8  arch_do_domctl+0x4b8/0x22f0
              ffff82c4c01709ed  get_page+0x2d/0x100
              ffff82c4c01031aa  do_domctl+0x2ba/0x11e0
              ffff82c4c0179662  do_mmuext_op+0x8d2/0x1b20
              ffff82c4c0183598  __update_vcpu_system_time+0x288/0x340
              ffff82c4c015c719  continue_nonidle_domain+0x9/0x30
              ffff82c4c012938b  add_entry+0x4b/0xb0
              ffff82c4c02223f9  syscall_enter+0xa9/0xae
    
    And gdb output:
    
    (gdb) x/1xh 0x6ae9168b
    0x6ae9168b:     0x3024
    (gdb) x/1xh 0x6ae9168b
    0x6ae9168b:     Ignoring packet error, continuing...
    Reply contains invalid hex digit 116
    
    The 1st one worked because the p2m.lock is recursive and the PCPU
    had not yet changed.
    
    crash reports (for example):
    
    crash> mm_rwlock_t 0xffff83083f913010
    struct mm_rwlock_t {
      lock = {
        raw = {
          lock = 2147483647
        },
        debug = {<No data fields>}
      },
      unlock_level = 0,
      recurse_count = 1,
      locker = 1,
      locker_function = 0xffff82c4c022c640 <__func__.13514> 
"__get_gfn_type_access"
    }
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Signed-off-by: Don Slutz <dslutz@xxxxxxxxxxx>
    Acked-by: Mukesh Rathor <mukesh.rathor@xxxxxxxxxx>
    master commit: 3dbab7a8bf4bef1bb2967cb3a8c7ed2146482ab3
    master date: 2014-01-10 17:45:01 +0100
(qemu changes not included)

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