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

[Xen-devel] [xen-4.4-testing test] 25751: regressions - FAIL



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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pv           13 guest-saverestore.2       fail REGR. vs. 25661
 test-amd64-i386-freebsd10-amd64  8 guest-start            fail REGR. vs. 25661
 test-amd64-amd64-pv          11 guest-saverestore         fail REGR. vs. 25661
 test-amd64-i386-freebsd10-i386 11 guest-localmigrate      fail REGR. vs. 25661
 test-amd64-i386-xl-credit2   13 guest-saverestore.2       fail REGR. vs. 25661
 test-amd64-amd64-xl-winxpsp3 10 guest-localmigrate        fail REGR. vs. 25661
 test-amd64-amd64-xl-win7-amd64 10 guest-localmigrate      fail REGR. vs. 25661
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install   fail REGR. vs. 25661

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  7 debian-install               fail   like 25661

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl          10 migrate-support-check        fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemuu-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-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xend-winxpsp3 17 leak-check/check             fail  never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass

version targeted for testing:
 xen                  be5c793b143825bca6f231f0c648982ac1afef0c
baseline version:
 xen                  babcef372ae2ca9c4f4212398803015eb250f764

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@xxxxxxxx>
  Keir Fraser <keir@xxxxxxx>
  Kevin Tian <kevin.tian@xxxxxxxxx>
  Matthew Daley <mattd@xxxxxxxxxxx>
  Mukesh Rathor <mukesh.rathor@xxxxxxxxxx>
  Xiantao Zhang <xiantao.zhang@xxxxxxxxx>
------------------------------------------------------------

jobs:
 build-amd64-xend                                             pass    
 build-i386-xend                                              pass    
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 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                              fail    
 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                                   fail    
 test-amd64-i386-freebsd10-i386                               fail    
 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                                 fail    
 test-amd64-amd64-pv                                          fail    
 test-amd64-i386-pv                                           fail    
 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 osstest.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 be5c793b143825bca6f231f0c648982ac1afef0c
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Fri Apr 4 10:46:13 2014 +0200

    VMX: fix PAT value seen by guest
    
    The XSA-60 fixes introduced a window during which the guest PAT gets
    forced to all zeros. This shouldn't be visible to the guest. Therefore
    we need to intercept PAT MSR accesses during that time period.
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Liu Jinsong <jinsong.liu@xxxxxxxxx>
    master commit: fce79f8ce91dc45f3a4d699ee67c49e6cbeb1197
    master date: 2014-04-01 16:49:18 +0200

commit 4a4a1d457bc9264b4399728348a2bb84c739e253
Author: Matthew Daley <mattd@xxxxxxxxxxx>
Date:   Fri Apr 4 10:45:31 2014 +0200

    kexec: propagate ENOMEM result in error handling
    
    ...otherwise if kimage_alloc_control_page fails (presumably due to
    out-of-memory; see the invocation just before this one), the caller of
    do_kimage_alloc will think the call was successful.
    
    Signed-off-by: Matthew Daley <mattd@xxxxxxxxxxx>
    Reviewed-by: David Vrabel <david.vrabel@xxxxxxxxxx>
    master commit: 66c6349265d6536d0b77cd958ee3e5074e86233a
    master date: 2014-04-01 16:48:02 +0200

commit aa538fe0fcede95b17fa11bc008395159aa87a89
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Fri Apr 4 10:44:56 2014 +0200

    x86/EPT: relax treatment of APIC MFN
    
    There's no point in this being mapped UC by the guest due to using a
    respective PAT index - set the ignore-PAT flag to true.
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Tim Deegan <tim@xxxxxxx>
    master commit: 1f8b57779785bf9f55c16312bb1ec679929c314b
    master date: 2014-03-28 13:43:25 +0100

commit dc9b9e6d987ba825660f35634639e95559174a22
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Fri Apr 4 10:44:09 2014 +0200

    x86/HVM: correct CPUID leaf 80000008 handling
    
    CPUID[80000008].EAX[23:16] have been given the meaning of the guest
    physical address restriction (in case it needs to be smaller than the
    host's), hence we need to mirror that into vCPUID[80000008].EAX[7:0].
    
    Enforce a lower limit at the same time, as well as a fixed value for
    the virtual address bits, and zero for the guest physical address ones.
    
    In order for the vMTRR code to see these overrides we need to make it
    call hvm_cpuid() instead of domain_cpuid(), which in turn requires
    special casing (and relaxing) the controlling domain.
    
    This additionally should hide an ordering problem in the tools: Both
    xend and xl appear to be restoring a guest from its image before
    setting up the CPUID policy in the hypervisor, resulting in
    domain_cpuid() returning all zeros and hence the check in
    mtrr_var_range_msr_set() failing if the guest previously had more than
    the minimum 36 physical address bits.
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Tim Deegan <tim@xxxxxxx>
    master commit: ef437690af8b75e6758dce77af75a22b63982883
    master date: 2014-03-28 13:33:34 +0100

commit 6e399a5006dbbba68817307cbf4edbb2bde530f1
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Fri Apr 4 10:43:07 2014 +0200

    x86: fix determination of bit count for struct domain allocations
    
    We can't just add in the hole shift value, as the hole may be at or
    above the 44-bit boundary. Instead we need to determine the total bit
    count until reaching 32 significant (not squashed out) bits in PFN
    representations.
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Acked-by: Keir Fraser <keir@xxxxxxx>
    master commit: b3d2f8b2cba9fce5bc8995612d0d13fcefec7769
    master date: 2014-03-24 10:48:03 +0100

commit 46e32001165a2d85cc6cda41240e6fbe9103bf07
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Fri Apr 4 10:42:18 2014 +0200

    x86/Intel: work around Xeon 7400 series erratum AAI65
    
    Linux commit 40e2d7f9b5dae048789c64672bf3027fbb663ffa ("x86 idle:
    Repair large-server 50-watt idle-power regression") tells us that this
    applies not just to the named Xeon 7400 series, but also NHM-EX and
    WSM-EX; sadly Intel's documentation is so badly searchable that I
    wasn't able to locate the respective errata (and hence can't quote
    their numbers here).
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Acked-by: Kevin Tian <kevin.tian@xxxxxxxxx>
    master commit: 96d1b237ae9b2f2718bb1c59820701f17d3d86e0
    master date: 2014-03-17 16:47:22 +0100

commit 3ef7b3a64473fae523ef84398eb00c7ab3ff1c1a
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Fri Apr 4 10:41:23 2014 +0200

    VT-d: fix RMRR handling
    
    Removing mapped RMRR tracking structures in dma_pte_clear_one() is
    wrong for two reasons: First, these regions may cover more than a
    single page. And second, multiple devices (and hence multiple devices
    assigned to any particular guest) may share a single RMRR (whether
    assigning such devices to distinct guests is a safe thing to do is
    another question).
    
    Therefore move the removal of the tracking structures into the
    counterpart function to the one doing the insertion -
    intel_iommu_remove_device(), and add a reference count to the tracking
    structure.
    
    Further, for the handling of the mappings of the respective memory
    regions to be correct, RMRRs must not overlap. Add a respective check
    to acpi_parse_one_rmrr().
    
    And finally, with all of this being VT-d specific, move the cleanup
    of the list as well as the structure type definition where it belongs -
    in VT-d specific rather than IOMMU generic code.
    
    Note that this doesn't address yet another issue associated with RMRR
    handling: The purpose of the RMRRs as well as the way the respective
    IOMMU page table mappings get inserted both suggest that these regions
    would need to be marked E820_RESERVED in all (HVM?) guests' memory
    maps, yet nothing like this is being done in hvmloader. (For PV guests
    this would also seem to be necessary, but may conflict with PV guests
    possibly assuming there to be just a single E820 entry representing all
    of its RAM.)
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Acked-by: Xiantao Zhang <xiantao.zhang@xxxxxxxxx>
    master commit: dd527061770789d8152b1dea68056987b202d87a
    master date: 2014-03-17 16:45:04 +0100

commit a2dba07f50af42863be0d50fc1a520950531527d
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Fri Apr 4 10:40:37 2014 +0200

    x86: make hypercall preemption checks consistent
    
    - never preempt on the first iteration (ensure forward progress)
    - never preempt on the last iteration (pointless/wasteful)
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Reviewed-by: Tim Deegan <tim@xxxxxxx>
    Acked-by: Keir Fraser <keir@xxxxxxx>
    master commit: fd7bfce0395ace266159760e35dc49f7af3b90ce
    master date: 2014-03-13 14:27:51 +0100

commit e83aed98cb04de03d272f4679da93d0bc73e619f
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Fri Apr 4 10:40:05 2014 +0200

    common: make hypercall preemption checks consistent
    
    - never preempt on the first iteration (ensure forward progress)
    - do cheap checks first
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Reviewed-by: Tim Deegan <tim@xxxxxxx>
    Acked-by: Keir Fraser <keir@xxxxxxx>
    master commit: 8c0eed2cc8d8a2ccccdffe4c386b625b672dc12a
    master date: 2014-03-13 14:26:35 +0100

commit 1e83fa5ee8064cc81e25f2a04cd47aeb5104413c
Author: Mukesh Rathor <mukesh.rathor@xxxxxxxxxx>
Date:   Fri Apr 4 10:38:52 2014 +0200

    x86/pvh: disallow PHYSDEVOP_pirq_eoi_gmfn_v2/v1
    
    A call to do_physdev_op with PHYSDEVOP_pirq_eoi_gmfn_v2/v1 will corrupt
    struct hvm_domain when it writes to domain->arch.pv_domain.pirq_eoi_map.
    Disallow that. Currently, such a path exists for linux dom0 pvh.
    
    Signed-off-by: Mukesh Rathor <mukesh.rathor@xxxxxxxxxx>
    master commit: a7ca5c402e8cf61c5e8dd6e6797a627863f5a243
    master date: 2014-03-24 09:47:59 +0100

commit b44b5d2fe0ae1546a14d0800e094535aa3359334
Author: Mukesh Rathor <mukesh.rathor@xxxxxxxxxx>
Date:   Fri Apr 4 10:37:57 2014 +0200

    x86: fix pirq path for pvh
    
    Just like hvm, pirq eoi shared page is not there for pvh. pvh should
    not touch any pv_domain fields.
    
    Signed-off-by: Mukesh Rathor <mukesh.rathor@xxxxxxxxxx>
    master commit: bea8ee1a5ff2bbe04fcc6297db45fac178a5abc9
    master date: 2014-03-13 14:24:19 +0100

commit 3a148e0a7ee0ae56a498be5ba973314ec50cd999
Author: Mukesh Rathor <mukesh.rathor@xxxxxxxxxx>
Date:   Fri Apr 4 10:36:29 2014 +0200

    x86: call pit_init for pvh also
    
    During halt of a pvh guest, the guest may do speaker shutdown. This
    results in call to handle_speaker_io in xen. It will hang on the vpit
    spin lock because it has not been initialized.
    Since, pit_init is also called for both pv and hvm, the call is
    moved to a more generic place.
    
    Signed-off-by: Mukesh Rathor <mukesh.rathor@xxxxxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
    master commit: c30c544b199f70eada597c7352cdcb44648f6dcd
    master date: 2014-03-11 13:56:50 +0100
(qemu changes not included)

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


 


Rackspace

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