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

[Xen-changelog] [xen master] features: declare the Credit2 scheduler as Supported



commit 3c79495579adddee535c2b7f8c332e4517764a0e
Author:     Dario Faggioli <dario.faggioli@xxxxxxxxxx>
AuthorDate: Wed Nov 2 16:05:03 2016 +0100
Commit:     Wei Liu <wei.liu2@xxxxxxxxxx>
CommitDate: Thu Nov 3 10:40:48 2016 +0000

    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>
---
 docs/features/sched_credit2.pandoc | 2 +-
 xen/common/Kconfig                 | 2 +-
 xen/common/sched_credit2.c         | 2 --
 3 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/docs/features/sched_credit2.pandoc 
b/docs/features/sched_credit2.pandoc
index 8609d9c..9c8e15b 100644
--- a/docs/features/sched_credit2.pandoc
+++ b/docs/features/sched_credit2.pandoc
@@ -5,7 +5,7 @@
 
 # Basics
 ---------------- ----------------------------------------------------
-         Status: **Experimental**
+         Status: **Supported**
 
       Component: Hypervisor
 ---------------- ----------------------------------------------------
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index d4f10ca..f2ecbc4 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -166,7 +166,7 @@ config SCHED_CREDIT
          The traditional credit scheduler is a general purpose scheduler.
 
 config SCHED_CREDIT2
-       bool "Credit2 scheduler support (EXPERIMENTAL)"
+       bool "Credit2 scheduler support"
        default y
        ---help---
          The credit2 scheduler is a general purpose scheduler that is
diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index fe46e80..1f26553 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -2954,8 +2954,6 @@ csched2_init(struct scheduler *ops)
     struct csched2_private *prv;
 
     printk("Initializing Credit2 scheduler\n");
-    printk(" WARNING: This is experimental software in development.\n" \
-           " Use at your own risk.\n");
 
     printk(XENLOG_INFO " load_precision_shift: %d\n"
            XENLOG_INFO " load_window_shift: %d\n"
--
generated by git-patchbot for /home/xen/git/xen.git#master

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

 


Rackspace

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