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

[Xen-devel] [xen-unstable-smoke test] 101887: regressions - FAIL



flight 101887 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101887/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-debianhvm-i386 9 debian-hvm-install fail REGR. vs. 
101834
 build-armhf                   5 xen-build                fail REGR. vs. 101834

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl           1 build-check(1)               blocked  n/a
 test-amd64-amd64-libvirt     12 migrate-support-check        fail   never pass

version targeted for testing:
 xen                  6723676c2651a40855e37861315569892fa2b923
baseline version:
 xen                  496673a2ada93c201fbe1cc83146c8bd8e79169d

Last test of basis   101834  2016-10-31 22:10:29 Z    2 days
Failing since        101884  2016-11-03 12:02:50 Z    0 days    2 attempts
Testing same since   101887  2016-11-03 14:03:07 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  Dario Faggioli <dario.faggioli@xxxxxxxxxx>
  George Dunlap <george.dunlap@xxxxxxxxxx>
  Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
  Jan Beulich <jbeulich@xxxxxxxx>
  Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
  Roger Pau Monne <roger.pau@xxxxxxxxxx>
  Roger Pau Monné <roger.pau@xxxxxxxxxx>
  Wei Liu <wei.liu2@xxxxxxxxxx>

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  fail    
 build-amd64-libvirt                                          pass    
 test-armhf-armhf-xl                                          blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-i386                     fail    
 test-amd64-amd64-libvirt                                     pass    


------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
    http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

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


Not pushing.

------------------------------------------------------------
commit 6723676c2651a40855e37861315569892fa2b923
Author: Roger Pau Monne <roger.pau@xxxxxxxxxx>
Date:   Thu Nov 3 13:19:03 2016 +0100

    docs: document ACPI usage in PVHv2 guests
    
    It is possible for PVHv2 guests to get the hardware description from ACPI
    tables, add this to the documentation also.
    
    Signed-off-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
    Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Release-acked-by: Wei Liu <wei.liu2@xxxxxxxxxx>

commit 33b79dd04445b3ce289aa821eed8d812157478d6
Author: Roger Pau Monne <roger.pau@xxxxxxxxxx>
Date:   Thu Nov 3 12:29:21 2016 +0100

    docs: fixup PVHv2 documentation regarding AP startup
    
    On PVHv2 guests the local APIC can also be used to start APs if present.
    Amend the documentation in order to reflect this.
    
    Signed-off-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
    Acked-by: Jan Beulich <jbeulich@xxxxxxxx>
    Release-acked-by: Wei Liu <wei.liu2@xxxxxxxxxx>

commit 12bc22f79117dfae5e59382cdda6b8b6b70a7554
Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Date:   Wed Nov 2 14:43:48 2016 +0000

    x86/emul: Reject LGDT/LIDT attempts with non-canonical base addresses
    
    No sane OS would deliberately try this, but make Xen's emulation match real
    hardware by delivering #GP(0), rather than suffering a VMEntry failure.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Reviewed-by: Jan Beulich <JBeulich@xxxxxxxx>
    Release-acked-by: Wei Liu <wei.liu2@xxxxxxxxxx>

commit ff53c65311a32e54dba51f2b8112632e9dd2af3b
Author: Wei Liu <wei.liu2@xxxxxxxxxx>
Date:   Wed Nov 2 14:10:37 2016 +0000

    libxl: disallow enabling PoD and ALTP2M at the same time
    
    That combination would cause Xen to crash.
    
    Note that although this is a security issue, is not XSA-worthy because
    ALTP2M is experimental.
    
    Signed-off-by: Wei Liu <wei.liu2@xxxxxxxxxx>
    Acked-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
    Release-acked-by: Wei Liu <wei.liu2@xxxxxxxxxx>

commit 3c79495579adddee535c2b7f8c332e4517764a0e
Author: Dario Faggioli <dario.faggioli@xxxxxxxxxx>
Date:   Wed Nov 2 16:05:03 2016 +0100

    features: declare the Credit2 scheduler as Supported
    
    Credit2 is available in tree as an "Experimental" scheduler since
    a few years. Recently, effort started for making it production ready
    and, eventually, the new Xen's default scheduler. As a consequence of
    that, it has undergone a great deal of development, testing and
    benchmarking.
    
    In fact, Credit2's much more modern (wrt Credit1) design and cleaner
    code makes it a lot easier to understand what the scheduler is doing,
    fix scheduling issues that may come up, and implement new and more
    advanced features, in future.
    
    In some more details:
    
     - key features that were missing (pinning and context switching
       rate-limiting) have now been implemented, and more (soft affinity,
       caps and reservations) are about to come. The gap wrt Credit1 is
       therefore closing. In particular, with pinning and rate-limiting
       available, the scheduler can be considered usable.
    
     - Credit2 is tested by OSSTest since long time. Furthermore, as a
       part of recent efforts, stress tests and benchmarks have been run
       and shown no bugs or stability issues.
    
     - A number of different benchmarks have been run, most of them
       comparing Credit2 with Credit1. Some of the results were posted on
       xen-devel, some others have been illustrated during a talk at 2016
       edition of Xen-Project Developer Summit. In general, performance
       look promising --if not better than Credit1 already, in some of
       the cases.
    
    It therefore appears that we are ready to mark the Credit2 scheduler
    as a 'Supported' feature, and ask users to look at it and try it, if
    they think it suits their needs.
    
    Of course, declaring something 'Supported' has security implications.
    So here it is how the situation looks like from a security standpoint:
    
    1) Is guest->host privilege escalation possible?
    
    The only interfaces exposed to unprivileged guests are the SCHEDOP
    hypercalls, and timers. None of those hypercalls contain any pointers,
    and they don't look to contain any privilege escalation path. Also,
    they're not specific to Credit2, as they're "used" by all schedulers
    (ingluding the current default, Credit1), so anything about these
    interfaces would be a security concern already.
    
    2) Is guest user->guest kernel escalation possible?
    
    The guest kernel is not really relying on anything from the scheduler
    to protect itself or any data in any way.
    
    3) Is there any information leakage?
    
    The only information which the scheduler exposes to unprivileged
    guests is the timing information.  This may be able to be used for
    side-channel attacks to probabilistically infer things about other
    vcpus running on the same system; but this has not traditionally
    been considered within the security boundary. And, again, this is
    possible with all schedulers.
    
    The control domain can issue DOMCTL_SCHEDOP and SYSCTL_SCHEDOP
    hypercalls, but the involved data structures are handled in a
    way that does not leak information (which would be leaked "only"
    to Dom0 anyway).
    
    4) Can a Denial-of-Service be triggered?
    
    This is a risk, with schedulers, and one that's hard to foresee.
    For instance, it _did_ happen on Credit1, in the past (a vcpu
    could "game the system" by sleeping at particular times to gain
    BOOST priority and monopolize 95% of the cpu). In that case, it
    was possible because of the probabilistic nature of accounting
    in Credit1 (which was then fixed). Well, Credit2:
     - already do accurate, rather than probabilistic, accounting;
     - does not have any BOOST or, in general, any way for a vcpu to
       become 'more important' than the others: they're all subjected
       to the same crediting algorithm.
    
    Also note that, the accounting and the crediting algorithm are a lot
    simpler than in Credit1, and hence a lot easier to understand, debug
    and audit.
    
    Signed-off-by: Dario Faggioli <dario.faggioli@xxxxxxxxxx>
    Acked-by: Jan Beulich <jbeulich@xxxxxxxx>
    Acked-by: Wei Liu <wei.liu2@xxxxxxxxxx>
    Acked-by: George Dunlap <george.dunlap@xxxxxxxxxx>
    Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
    Acked-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
    Release-acked-by: Wei Liu <wei.liu2@xxxxxxxxxx>

commit fecf584294c6b00d95de0ecdb5e02269d8d9b4c9
Author: Wei Liu <wei.liu2@xxxxxxxxxx>
Date:   Mon Oct 31 17:03:04 2016 +0000

    Config.mk: fix comment for debug option
    
    Signed-off-by: Wei Liu <wei.liu2@xxxxxxxxxx>
    Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
    Release-acked-by: Wei Liu <wei.liu2@xxxxxxxxxx>

commit 31d41d7bc87d0d2a24ac965b37793faa40d23dcb
Author: Wei Liu <wei.liu2@xxxxxxxxxx>
Date:   Mon Oct 31 17:42:25 2016 +0000

    build: make debug option affect tools only
    
    The debug option in Config.mk affects hypervisor, tools and stubdom by
    appending different flags to CFLAGS.  Mini-os under extra is not
    affected because it already has its own build system when it is
    separated from xen.git.
    
    It is undesirable because now hypervisor build is affected by both
    Kconfig and debug.
    
    Disentangle the semantics of debug by pushing relevant options to
    individual sub-systems.
    
    For hypervisor, the flags previously added by debug option is now
    controlled by CONFIG_DEBUG.
    
    For tools, flags are moved from config/*.mk into tools/Rules.mk.
    
    For stubdom, because it unilaterally sets debug=y before including
    top-level Config.mk, we only need to move the debug build set of flags
    into stubdom Makefile.
    
    Specifically there are some considerations on what flags are picked:
    
    1. we don't need -fno-optimize-sibling-calls anymore because gcc doc
       indicates that it is not enabled for -O1, which we already set in the
       debug build.
    2. for tools we use -O0 -g3 in Rules.mk because they already take
       precedence over the flags set in config/*.mk.
    3. for hypervisor we don't add -fno-omit-frame-pointer to debug build
       because that's controlled by CONFIG_FRAME_POINTER.
    
    This patch doesn't intend to tune those flags, but to provide identical
    set of effective flags as before.  The debug option in Config.mk will
    only affect tools components after this patch is applied.
    
    Signed-off-by: Wei Liu <wei.liu2@xxxxxxxxxx>
    Acked-by: Jan Beulich <jbeulich@xxxxxxxx>
    Release-acked-by: Wei Liu <wei.liu2@xxxxxxxxxx>

commit e1d1c68ea8a3354ba7474f15303d0a9086ba3287
Author: Wei Liu <wei.liu2@xxxxxxxxxx>
Date:   Mon Oct 31 17:01:12 2016 +0000

    xen: disable debug build
    
    Xen debug build is controlled by Kconfig.
    
    Signed-off-by: Wei Liu <wei.liu2@xxxxxxxxxx>
    Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
    Release-acked-by: Wei Liu <wei.liu2@xxxxxxxxxx>
(qemu changes not included)

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

 


Rackspace

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