From: Juergen Gross <jgross@suse.com>
To: Dario Faggioli <dario.faggioli@citrix.com>,
xen-devel@lists.xenproject.org
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
Jan Beulich <JBeulich@suse.com>
Subject: Re: [PATCH 2/4] xen: x86 / cpupool: clear the proper cpu_valid bit on pCPU teardown
Date: Fri, 26 Jun 2015 15:54:05 +0200 [thread overview]
Message-ID: <558D597D.3080301@suse.com> (raw)
In-Reply-To: <20150625121520.3353.30808.stgit@Solace.station>
On 06/25/2015 02:15 PM, Dario Faggioli wrote:
> In fact, if a pCPU belonging to some other pool than
> cpupool0 goes down, we want to clear the relevant bit
> from its actual pool, rather than always from cpupool0.
>
> Before this commit, all the pCPUs in the non-default
> pool(s) will be considered immediately valid, during
> system resume, even the one that have not been brought
> up yet. As a result, the (Credit1) scheduler will attempt
> to run its load balancing logic on them, causing the
> following Oops:
>
> # xl cpupool-cpu-remove Pool-0 8-15
> # xl cpupool-create name=\"Pool-1\"
> # xl cpupool-cpu-add Pool-1 8-15
> --> suspend
> --> resume
> (XEN) ----[ Xen-4.6-unstable x86_64 debug=y Tainted: C ]----
> (XEN) CPU: 8
> (XEN) RIP: e008:[<ffff82d080123078>] csched_schedule+0x4be/0xb97
> (XEN) RFLAGS: 0000000000010087 CONTEXT: hypervisor
> (XEN) rax: 80007d2f7fccb780 rbx: 0000000000000009 rcx: 0000000000000000
> (XEN) rdx: ffff82d08031ed40 rsi: ffff82d080334980 rdi: 0000000000000000
> (XEN) rbp: ffff83010000fe20 rsp: ffff83010000fd40 r8: 0000000000000004
> (XEN) r9: 0000ffff0000ffff r10: 00ff00ff00ff00ff r11: 0f0f0f0f0f0f0f0f
> (XEN) r12: ffff8303191ea870 r13: ffff8303226aadf0 r14: 0000000000000009
> (XEN) r15: 0000000000000008 cr0: 000000008005003b cr4: 00000000000026f0
> (XEN) cr3: 00000000dba9d000 cr2: 0000000000000000
> (XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: 0000 cs: e008
> (XEN) ... ... ...
> (XEN) Xen call trace:
> (XEN) [<ffff82d080123078>] csched_schedule+0x4be/0xb97
> (XEN) [<ffff82d08012c732>] schedule+0x12a/0x63c
> (XEN) [<ffff82d08012f8c8>] __do_softirq+0x82/0x8d
> (XEN) [<ffff82d08012f920>] do_softirq+0x13/0x15
> (XEN) [<ffff82d080164791>] idle_loop+0x5b/0x6b
> (XEN)
> (XEN) ****************************************
> (XEN) Panic on CPU 8:
> (XEN) GENERAL PROTECTION FAULT
> (XEN) [error_code=0000]
> (XEN) ****************************************
>
> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Acked-by: Juergen Gross <jgross@suse.com>
> ---
> Cc: Juergen Gross <jgross@suse.com>
> Cc: Jan Beulich <JBeulich@suse.com>
> Cc: Andrew Cooper <andrew.cooper3@citrix.com>
> ---
> xen/arch/x86/smpboot.c | 1 -
> xen/common/cpupool.c | 2 ++
> 2 files changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/xen/arch/x86/smpboot.c b/xen/arch/x86/smpboot.c
> index 2289284..a4ec396 100644
> --- a/xen/arch/x86/smpboot.c
> +++ b/xen/arch/x86/smpboot.c
> @@ -887,7 +887,6 @@ void __cpu_disable(void)
> remove_siblinginfo(cpu);
>
> /* It's now safe to remove this processor from the online map */
> - cpumask_clear_cpu(cpu, cpupool0->cpu_valid);
> cpumask_clear_cpu(cpu, &cpu_online_map);
> fixup_irqs();
>
> diff --git a/xen/common/cpupool.c b/xen/common/cpupool.c
> index 5471f93..b48ae17 100644
> --- a/xen/common/cpupool.c
> +++ b/xen/common/cpupool.c
> @@ -530,6 +530,7 @@ static int cpupool_cpu_remove(unsigned int cpu)
> if ( cpumask_test_cpu(cpu, (*c)->cpu_valid ) )
> {
> cpumask_set_cpu(cpu, (*c)->cpu_suspended);
> + cpumask_clear_cpu(cpu, (*c)->cpu_valid);
> break;
> }
> }
> @@ -552,6 +553,7 @@ static int cpupool_cpu_remove(unsigned int cpu)
> * If we are not suspending, we are hot-unplugging cpu, and that is
> * allowed only for CPUs in pool0.
> */
> + cpumask_clear_cpu(cpu, cpupool0->cpu_valid);
> ret = 0;
> }
>
>
>
next prev parent reply other threads:[~2015-06-26 13:54 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-25 12:15 [PATCH 0/4] xen: sched / cpupool: fixes and improvements, mostly for when suspend/resume is involved Dario Faggioli
2015-06-25 12:15 ` [PATCH 1/4] xen: sched: avoid dumping duplicate information Dario Faggioli
2015-06-26 13:43 ` Juergen Gross
2015-07-02 11:18 ` George Dunlap
2015-06-25 12:15 ` [PATCH 2/4] xen: x86 / cpupool: clear the proper cpu_valid bit on pCPU teardown Dario Faggioli
2015-06-25 14:20 ` Andrew Cooper
2015-06-25 15:04 ` Dario Faggioli
2015-06-25 15:52 ` Andrew Cooper
2015-06-25 16:13 ` Dario Faggioli
2015-06-25 16:39 ` Andrew Cooper
2015-06-26 13:54 ` Juergen Gross [this message]
2015-06-25 12:15 ` [PATCH 3/4] xen: credit1: properly deal with pCPUs not in any cpupool Dario Faggioli
2015-06-26 14:05 ` Juergen Gross
2015-07-02 15:24 ` George Dunlap
2015-07-02 16:01 ` Dario Faggioli
2015-07-02 16:14 ` George Dunlap
2015-06-25 12:15 ` [PATCH 4/4] xen: sched: get rid of cpupool_scheduler_cpumask() Dario Faggioli
2015-06-26 14:08 ` Juergen Gross
2015-06-26 14:57 ` Joshua Whitehead
2015-06-27 19:21 ` Meng Xu
2015-07-02 15:39 ` George Dunlap
2015-07-03 7:48 ` Dario Faggioli
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=558D597D.3080301@suse.com \
--to=jgross@suse.com \
--cc=JBeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=dario.faggioli@citrix.com \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.