From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752905AbcHOP60 convert rfc822-to-8bit (ORCPT ); Mon, 15 Aug 2016 11:58:26 -0400 Received: from aserp1040.oracle.com ([141.146.126.69]:47520 "EHLO aserp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752713AbcHOP6Z (ORCPT ); Mon, 15 Aug 2016 11:58:25 -0400 Subject: Re: [Xen-devel] [PATCH 2/2] xen/events: Convert to hotplug state machine To: David Vrabel , jgross@suse.com References: <1471272407-4292-1-git-send-email-boris.ostrovsky@oracle.com> <1471272407-4292-3-git-send-email-boris.ostrovsky@oracle.com> <57B1DA71.3020806@citrix.com> Cc: xen-devel@lists.xenproject.org, bigeasy@linutronix.de, linux-kernel@vger.kernel.org From: Boris Ostrovsky Message-ID: Date: Mon, 15 Aug 2016 11:58:13 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <57B1DA71.3020806@citrix.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT X-Source-IP: userv0022.oracle.com [156.151.31.74] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 08/15/2016 11:06 AM, David Vrabel wrote: > On 15/08/16 15:46, Boris Ostrovsky wrote: >> From: Sebastian Andrzej Siewior >> >> Install the callbacks via the state machine. > [...] >> +static int xen_evtchn_cpu_dead(unsigned int cpu) >> +{ >> + __evtchn_fifo_handle_events(cpu, true); >> + return 0; >> +} > I'm not familiar with the new state machine. When this is called, what > state is the CPU in? > > In particular, local interrupts must be disabled and all non-percpu irqs > must have been migrated to other CPUs. This (xen_evtchn_cpu_dead()) is called immediately after notify_dead() on the way down. The state machine is walking cpuhp_state list and for each member of the list it calls the callback that has been registered for that member. So when we bring a CPU up first we call xen_evtchn_cpu_prepare() and then in the next iteration of the state machine loop notify_prepare() (because CPUHP_XEN_EVTCHN_PREPARE is immediately before CPUHP_NOTIFY_PREPARE). On the way down it's done in reverse: first notify_dead() and then xen_evtchn_cpu_dead(). In other words, the old notification scheme is part of new state machine: CPUHP_RCUTREE_PREP, CPUHP_XEN_PREPARE, + CPUHP_XEN_EVTCHN_PREPARE, CPUHP_NOTIFY_PREPARE, <=== CPU notifiers callback CPUHP_TIMERS_DEAD, CPUHP_BRINGUP_CPU, -boris > > >> int __init xen_evtchn_fifo_init(void) >> { >> @@ -456,7 +444,9 @@ int __init xen_evtchn_fifo_init(void) >> >> evtchn_ops = &evtchn_ops_fifo; >> >> - register_cpu_notifier(&evtchn_fifo_cpu_notifier); >> + cpuhp_setup_state_nocalls(CPUHP_XEN_EVTCHN_PREPARE, >> + "CPUHP_XEN_EVTCHN_PREPARE", >> + xen_evtchn_cpu_prepare, xen_evtchn_cpu_dead); >> out: >> put_cpu(); >> return ret; >> diff --git a/include/linux/cpuhotplug.h b/include/linux/cpuhotplug.h >> index d6beeb9..c60a17c 100644 >> --- a/include/linux/cpuhotplug.h >> +++ b/include/linux/cpuhotplug.h >> @@ -22,6 +22,7 @@ enum cpuhp_state { >> CPUHP_SMPCFD_PREPARE, >> CPUHP_RCUTREE_PREP, >> CPUHP_XEN_PREPARE, >> + CPUHP_XEN_EVTCHN_PREPARE, >> CPUHP_NOTIFY_PREPARE, >> CPUHP_TIMERS_DEAD, >> CPUHP_BRINGUP_CPU, >>