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

[Xen-devel] [xen-unstable test] 25949: regressions - trouble: broken/fail/pass



flight 25949 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/25949/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-ovmf-amd64  3 host-install(3) broken REGR. vs. 25945
 test-amd64-i386-xl-qemut-win7-amd64 13 guest-localmigrate/x10 fail REGR. vs. 
25945
 test-amd64-i386-xl-qemuu-win7-amd64  5 xen-boot           fail REGR. vs. 25945

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-winxpsp3 11 guest-saverestore.2       fail like 25905

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 debian-hvm-install      fail never pass
 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-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass

version targeted for testing:
 xen                  816f6224823320c8452fd3af5d873a2b82f5e1c3
baseline version:
 xen                  01feb234d0cb3bff248694d99397fb63a9757490

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>
  Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>
  Jan Beulich <jbeulich@xxxxxxxx>
  Kevin Tian <kevin.tian@xxxxxxxxx>
------------------------------------------------------------

jobs:
 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                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         broken  
 test-amd64-i386-xl-qemuu-ovmf-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                                   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-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-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-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 816f6224823320c8452fd3af5d873a2b82f5e1c3
Author: Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>
Date:   Tue Apr 22 12:10:13 2014 +0200

    allow hardware domain != dom0
    
    This adds a hypervisor command line option "hardware_dom=" which takes a
    domain ID.  When the domain with this ID is created, it will be used
    as the hardware domain.
    
    This is intended to be used when domain 0 is a dedicated stub domain for
    domain building, allowing the hardware domain to be de-privileged and
    act only as a driver domain.
    
    Signed-off-by: Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>

commit 4d21a95558b9c9007d8b70e63d1449a4a10f535c
Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Date:   Tue Apr 22 12:09:36 2014 +0200

    x86/hap: fix lack of newline in error message
    
    to avoid corrupting the following line.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Acked-by: Jan Beulich <JBeulich@xxxxxxxx>

commit 88e64cb785c1de4f686c1aa1993a0003b7db9e1a
Author: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>
Date:   Tue Apr 22 12:08:56 2014 +0200

    x86/HVM: use fixed TSC value when saving or restoring domain
    
    When a domain is saved each VCPU's TSC value needs to be preserved. To get 
it we
    use hvm_get_guest_tsc(). This routine (either itself or via get_s_time() 
which
    it may call) calculates VCPU's TSC based on current host's TSC value (by 
doing a
    rdtscll()). Since this is performed for each VCPU separately we end up with
    un-synchronized TSCs.
    
    Similarly, during a restore each VCPU is assigned its TSC based on host's 
current
    tick, causing virtual TSCs to diverge further.
    
    With this, we can easily get into situation where a guest may see time going
    backwards.
    
    Instead of reading new TSC value for each VCPU when saving/restoring it we 
should
    use the same value across all VCPUs.
    
    Reported-by: Philippe Coquard <philippe.coquard@xxxxxxxx>
    Signed-off-by: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>

commit b95fd03b5f0b66384bd7c190d5861ae68eb98c85
Author: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>
Date:   Tue Apr 22 12:08:06 2014 +0200

    x86/svm: enable TSC scaling
    
    TSC ratio enabling logic is inverted: we want to use it when we
    are running in native tsc mode, i.e. when d->arch.vtsc is zero.
    
    Also, since now svm_set_tsc_offset()'s calculations depend
    on vtsc's value, we need to call hvm_funcs.set_tsc_offset() after
    vtsc changes in tsc_set_info().
    
    In addition, with TSC ratio enabled, svm_set_tsc_offset() will
    need to do rdtsc. With that we may end up having TSCs on guest's
    processors out of sync. d->arch.hvm_domain.sync_tsc which is set
    by the boot processor can now be used by APs as reference TSC
    value instead of host's current TSC.
    
    Signed-off-by: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>

commit 82713ec8d2b65d17f13e46a131e38bfe5baf8bd6
Author: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>
Date:   Tue Apr 22 12:07:37 2014 +0200

    x86: use native RDTSC(P) execution when guest and host frequencies are the 
same
    
    We should be able to continue using native RDTSC(P) execution on
    HVM/PVH guests after migration if host and guest frequencies are
    equal (this includes the case when the frequencies are made equal
    by TSC scaling feature).
    
    This also allows us to revert main part of commit 4aab59a3 (svm: Do not
    intercept RDTSC(P) when TSC scaling is supported by hardware) which
    was wrong: while RDTSC intercepts were disabled domain's vtsc could
    still be set, leading to inconsistent view of guest's TSC.
    
    Signed-off-by: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>
    Acked-by: Jan Beulich <jbeulich@xxxxxxxx>

commit e681c0408564a2c0d1c6d56d3f683f8db079458c
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Tue Apr 22 12:05:44 2014 +0200

    ACPI/ERST: fix signed/unsigned type conflicts
    
    Error checks exist in the respective code path that expect negative
    values to indicate errors, yet negative values can't be communicated
    through size_t. Thus ssize_t needs to be introduced (also on ARM for
    consistency, even if the code in question isn't currently being used
    on there).
    
    The bug is theoretical only in so far as all the involved code is
    effectively dead. Reflect this by excluding that code from non-debug
    builds.
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Christoph Egger <chegger@xxxxxxxxx>

commit 061eebe0e99ad45c9c3b1a778b06140de4a91f25
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Tue Apr 22 12:04:20 2014 +0200

    x86/MSI: drop workaround for insecure Dom0 kernels
    
    Considering that
    - the workaround is expensive (iterating through the entire P2M space
      of a domain),
    - the planned elimination of the expensiveness (by propagating the type
      change step by step to the individual P2M leaves) wouldn't address
      the IOMMU side of things (as for it to obey to the changed
      permissions the adjustments must be pushed down immediately through
      the entire tree)
    - the proper solution (PHYSDEVOP_msix_prepare) should by now be
      implemented by all security conscious Dom0 kernels
    remove the workaround, killing eventual guests that would be known to
    become a security risk instead.
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Acked-by: Kevin Tian <kevin.tian@xxxxxxxxx>
(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®.