From patchwork Thu Mar 16 21:30:54 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Dario Faggioli X-Patchwork-Id: 9629347 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 2182760132 for ; Thu, 16 Mar 2017 21:33:38 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 10C972868D for ; Thu, 16 Mar 2017 21:33:38 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 03D9A28691; Thu, 16 Mar 2017 21:33:38 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.6 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_MED,RCVD_IN_SORBS_SPAM,T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 27AB12868D for ; Thu, 16 Mar 2017 21:33:36 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cocz7-0004Nd-Pd; Thu, 16 Mar 2017 21:31:01 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cocz6-0004NX-CI for xen-devel@lists.xenproject.org; Thu, 16 Mar 2017 21:31:00 +0000 Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id 42/CD-03705-3140BC85; Thu, 16 Mar 2017 21:30:59 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrKIsWRWlGSWpSXmKPExsVyMbThkK4Qy+k Ig0/bVC2+b5nM5MDocfjDFZYAxijWzLyk/IoE1oz+jc8YC84JV7R93szcwDhXoIuRk0NIYAaj xPwvVV2MXBwsAlNZJS7uXsEG4kgIbGSVONtxlRGkSkIgRuL4+mlsEHa1xI5Zz9kgulUkbm5fx QTSICTwh1FizpJnTCAJYQE9iSNHf7BD2IESv07vAWtgEzCQeLNjLyuILSKgJHFv1WSwemaBfI lVE/rA4iwCqhILNh0Hi/MK+Ens//MEbI6ogJzEysstrBBxQYmTM5+wdDFyAPVqSqzfpQ8xRl5 i+9s5zBMYhWYhqZqFUDULSdUCRuZVjOrFqUVlqUW6RnpJRZnpGSW5iZk5uoYGxnq5qcXFiemp OYlJxXrJ+bmbGIHBXM/AwLiD8VSz8yFGSQ4mJVFeFcETEUJ8SfkplRmJxRnxRaU5qcWHGGU4O JQkeCOzgHKCRanpqRVpmTnAuIJJS3DwKInwxoGkeYsLEnOLM9MhUqcYLTkenNr1honjVsMeIP mp//AbJiGWvPy8VClx3kCQBgGQhozSPLhxsNi/xCgrJczLyMDAIMRTkFqUm1mCKv+KUZyDUUm YVxlkCk9mXgnc1ldABzEBHZT48wjIQSWJCCmpBsa9a7sFZq5Wnjjf5v8f0ac3zr31PHpJpCqb VWua4YnH1w7/0fX3TD9oebN2o/DCuiIpNZNl76LPVi68ufPlzYRr6rP3dD9LmZAWtCy1/8Ovw mhJF91v70Xbp5a/nXDH/5G7U9n6Xy8jH2fvyPk493+F/vSXbssPnl/3/9NzH58FG5Y7OaWLJM 5IU2Ipzkg01GIuKk4EAMnkUJr4AgAA X-Env-Sender: raistlin.df@gmail.com X-Msg-Ref: server-15.tower-31.messagelabs.com!1489699858!86638881!1 X-Originating-IP: [209.85.128.194] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 9.2.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29087 invoked from network); 16 Mar 2017 21:30:58 -0000 Received: from mail-wr0-f194.google.com (HELO mail-wr0-f194.google.com) (209.85.128.194) by server-15.tower-31.messagelabs.com with AES128-GCM-SHA256 encrypted SMTP; 16 Mar 2017 21:30:58 -0000 Received: by mail-wr0-f194.google.com with SMTP id l37so7413142wrc.3 for ; Thu, 16 Mar 2017 14:30:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:from:to:cc:date:message-id:user-agent:mime-version :content-transfer-encoding; bh=A8/6kOn60wwGmIkF3KCMTgFiDgMqZ+qoLtX1lqylWwg=; b=PmgDnUqoLD/H9yXZj+cS7ge5IX09EAjQel0u4OpQgggAwlcNmtjHG61veDDbsh72IC /GuXcOQ/6h9Xlychv41YAG7epdSIRoIaRRgMdkmE4qTC0vy2L3ZQ/I4H2NuwQUjjSKZr KlThrMyuX80thf8z3g5oXHxiDpgwggdkZHsGU6i1G92cqV0rf2PA7CVaNPqynbMOyCgs fB0CzXw4mPMSzfWrfxzgB70Q2tTX1rC53RNgPlzVIAzj+PPj7YdZAzyBI7no1j8yV9cI n+PdLWEKMkW46E7vU1kX8dPCK7TznLRVuXVqO9/voARB92/1AcZI04HdQI1UUWploXk2 qHPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:from:to:cc:date:message-id :user-agent:mime-version:content-transfer-encoding; bh=A8/6kOn60wwGmIkF3KCMTgFiDgMqZ+qoLtX1lqylWwg=; b=oXtPujG8K/eG6qDqZCYTn59kNX6oKJnNfWOyDaYWYaZZ6cV6wGDiMSBxF9VAEys+ew gRE2qwkRzg7ney9ALk0y6q5bc7XsW3b0q7EHrmH2ZTqmB1MTxUdyBMZ+1XguLAESldlC 3jfdf/S36T/acuYIFJV1ryZsjapW5auwKh+cIFSr5/mNyx+lkZrKCWD7MfBYg8XYDwtP aPpvYJZcNys7nxcLYmso/b7bIAU0Ha0ga1AeyaKOXjA4ZSbBVOh8W3HCKH5TYmb8cTXa XIFLJb9jW+KNt+3DZ6jcvrHNhC57chUhE55VimMQ33DBRu/HrltJR2KZl4jBL+C26Uke JEjw== X-Gm-Message-State: AFeK/H2Uw+TVAxXBa5TphD15o0Ufs15SDLV/QpHn+4mHObjPpO2pzIbOwVyPsMlOwY3nRw== X-Received: by 10.223.140.25 with SMTP id z25mr10227271wra.101.1489699858161; Thu, 16 Mar 2017 14:30:58 -0700 (PDT) Received: from Palanthas.fritz.box ([80.66.223.93]) by smtp.gmail.com with ESMTPSA id u184sm285221wmb.29.2017.03.16.14.30.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Mar 2017 14:30:56 -0700 (PDT) From: Dario Faggioli To: xen-devel@lists.xenproject.org Date: Thu, 16 Mar 2017 22:30:54 +0100 Message-ID: <148969985491.18518.5789656764002800021.stgit@Palanthas.fritz.box> User-Agent: StGit/0.17.1-dirty MIME-Version: 1.0 Cc: Juergen Gross , George Dunlap , Jan Beulich Subject: [Xen-devel] [PATCH] xen: sched: don't call hooks of the wrong scheduler via VCPU2OP X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" X-Virus-Scanned: ClamAV using ClamSMTP Within context_saved(), we call the context_saved hook, and we use VCPU2OP() to determine from what scheduler. VCPU2OP uses DOM2OP, which uses d->cpupool, which is NULL when d is the idle domain. And in that case, DOM2OP just returns ops, the scheduler of cpupool0. Therefore, if: - cpupool0's scheduler defines context_saved (like Credit2 and RTDS do), - we are not in cpupool0 (i.e., our scheduler is not ops), - we are context switching from idle, we call VCPU2OP(idle_vcpu), which means DOM2OP(idle->cpupool), which is ops. Therefore, we both: - check if context_saved is defined in the wrong scheduler; - if yes, call the wrong one. When using Credit2 at boot, and also Credit2 in the other cpupool, this is wrong but innocuous, because it only involves the idle vcpus. When using Credit2 at boot, and Credit1 in the other cpupool, this is *totally* wrong, and it's by chance it does not explode! When using Credit2 and other schedulers I'm developping, I hit the following assert (in sched_credit2.c, on a CPU inside a cpupool that does not use Credit2): csched2_context_saved() { ... ASSERT(!vcpu_on_runq(svc)); ... } Fix this by taking care, in VCPU2OP, of the case when the vcpu is an idle one. Signed-off-by: Dario Faggioli Reviewed-by: Juergen Gross --- Cc: George Dunlap Cc: Juergen Gross Cc: Jan Beulich --- Cc-ing Jan, as this should be backported at least to 4.8, but, IMO, as back as possible. --- xen/common/schedule.c | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/xen/common/schedule.c b/xen/common/schedule.c index 223a120..d12f346 100644 --- a/xen/common/schedule.c +++ b/xen/common/schedule.c @@ -78,7 +78,19 @@ static struct scheduler __read_mostly ops; : (typeof((opsptr)->fn(opsptr, ##__VA_ARGS__)))0 ) #define DOM2OP(_d) (((_d)->cpupool == NULL) ? &ops : ((_d)->cpupool->sched)) -#define VCPU2OP(_v) (DOM2OP((_v)->domain)) +static inline struct scheduler* VCPU2OP(const struct vcpu *v) +{ + struct domain *d = v->domain; + + if ( likely(d->cpupool != NULL) ) + return d->cpupool->sched; + + /* v->processor never changes for idle vcpus, so using it here is safe */ + if ( likely(is_idle_domain(d)) ) + return per_cpu(scheduler, v->processor); + else + return &ops; +} #define VCPU2ONLINE(_v) cpupool_domain_cpumask((_v)->domain) static inline void trace_runstate_change(struct vcpu *v, int new_state)