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

[Xen-devel] [xen-4.1-testing test] 17748: regressions - FAIL

flight 17748 xen-4.1-testing real [real]

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 11 guest-localmigrate.2 fail REGR. 
vs. 17718

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10    fail REGR. vs. 17718

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

version targeted for testing:
 xen                  c7348a9ff855ba2cdb5412fe3709f1214264b42a
baseline version:
 xen                  f4537b51116009bfb8359681a758ef5860cfd0db

People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
  Jan Beulich <jbeulich@xxxxxxxx>
  Manuel Bouyer <bouyer@xxxxxxxxxxxxxxx>
  Marek Marczykowski <marmarek@xxxxxxxxxxxxxxxxxxxxxx>
  Paul Durrant <paul.durrant@xxxxxxxxxx>
  Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>

 build-amd64                                                  pass    
 build-armhf                                                  fail    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-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-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-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-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-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-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-i386-i386-xl-qemut-winxpsp3                             fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-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

Test harness code can be found at

Not pushing.

commit c7348a9ff855ba2cdb5412fe3709f1214264b42a
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Fri Apr 19 09:17:02 2013 +0200

    libxl: fix build error after 21c31a81
    "libxl: Fix SEGV in network-attach" dropped a necessary &.
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>

commit 21c31a811ca1705b71417fab520d9b39ae2ab3a7
Author: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
Date:   Thu Apr 18 17:44:17 2013 +0100

    libxl: Fix SEGV in network-attach
    When "device/vif" directory exists but is empty l!=NULL, but nb==0, so
    l[nb-1] is invalid.  Add missing check.
    Signed-off-by: Marek Marczykowski <marmarek@xxxxxxxxxxxxxxxxxxxxxx>
    Acked-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
    Signed-off-by: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>
    (cherry picked from commit 9f1a6ff38b8e7bb97a016794115de28553a6559f)
    Signed-off-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>

commit a12ed396652c22988e0e7a3f5bd57c882872da8e
Author: Paul Durrant <paul.durrant@xxxxxxxxxx>
Date:   Thu Apr 18 17:38:17 2013 +0200

    Fix rcu domain locking for transitive grants
    When acquiring a transitive grant for copy then the owning domain
    needs to be locked down as well as the granting domain. This was being
    done, but the unlocking was not. The acquire code now stores the
    struct domain * of the owning domain (rather than the domid) in the
    active entry in the granting domain. The release code then does the
    unlock on the owning domain.  Note that I believe I also fixed a bug
    where, for non-transitive grants the active entry contained a
    reference to the acquiring domain rather than the granting
    domain. From my reading of the code this would stop the release code
    for transitive grants from terminating its recursion correctly.
    Signed-off-by: Paul Durrant <paul.durrant@xxxxxxxxxx>
    master commit: f544bf377ee829e1342abd818ac30478c6f3a134
    master date: 2011-03-08 16:30:30 +0000
    Also, for non-transitive grants we now avoid incorrectly recursing
    in __release_grant_for_copy.
    This is CVE-2013-1964 / XSA-50.
    Reported-by: Manuel Bouyer <bouyer@xxxxxxxxxxxxxxx>
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Tested-by: Manuel Bouyer <bouyer@xxxxxxxxxxxxxxx>

commit d3d1288618ec903ad6a0e994ddfe0975cbac1584
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Thu Apr 18 16:24:08 2013 +0200

    x86: fix various issues with handling guest IRQs
    - properly revoke IRQ access in map_domain_pirq() error path
    - don't permit replacing an in use IRQ
    - don't accept inputs in the GSI range for MAP_PIRQ_TYPE_MSI
    - track IRQ access permission in host IRQ terms, not guest IRQ ones
      (and with that, also disallow Dom0 access to IRQ0)
    This is CVE-2013-1919 / XSA-46.
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Acked-by: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
    master commit: 545607eb3cfeb2abf5742d1bb869734f317fcfe5
    master date: 2013-04-18 16:11:23 +0200

commit 584eb7c15e4c94baaba93468776572dd7373a33c
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Thu Apr 18 16:23:07 2013 +0200

    x86: clear EFLAGS.NT in SYSENTER entry path
    ... as it causes problems if we happen to exit back via IRET: In the
    course of trying to handle the fault, the hypervisor creates a stack
    frame by hand, and uses PUSHFQ to set the respective EFLAGS field, but
    expects to be able to IRET through that stack frame to the second
    portion of the fixup code (which causes a #GP due to the stored EFLAGS
    having NT set).
    And even if this worked (e.g if we cleared NT in that path), it would
    then (through the fail safe callback) cause a #GP in the guest with the
    SYSENTER handler's first instruction as the source, which in turn would
    allow guest user mode code to crash the guest kernel.
    Inject a #GP on the fake (NULL) address of the SYSENTER instruction
    instead, just like in the case where the guest kernel didn't register
    a corresponding entry point.
    On 32-bit we also need to make sure we clear SYSENTER_CS for all CPUs
    (neither #RESET nor #INIT guarantee this).
    This is CVE-2013-1917 / XSA-44.
    Reported-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Tested-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Acked-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    master commit: fdac9515607b757c044e7ef0d61b1453ef999b08
    master date: 2013-04-18 16:00:35 +0200
(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®.