From mboxrd@z Thu Jan 1 00:00:00 1970 From: Juergen Gross Subject: Re: [PATCH 3/4] xen: sched: reorganize cpu_disable_scheduler() Date: Wed, 15 Jul 2015 17:07:14 +0200 Message-ID: <55A67722.90309@suse.com> References: <20150703152743.23194.15530.stgit@Solace.station> <20150703154930.23194.20319.stgit@Solace.station> <559BB4FC.1070106@suse.com> <1436368416.22672.220.camel@citrix.com> <1436437493.22672.308.camel@citrix.com> <559E50B1.9070406@suse.com> <1436972062.13522.209.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZFOHF-00007E-Qy for xen-devel@lists.xenproject.org; Wed, 15 Jul 2015 15:07:17 +0000 In-Reply-To: <1436972062.13522.209.camel@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Dario Faggioli Cc: George Dunlap , xen-devel@lists.xenproject.org List-Id: xen-devel@lists.xenproject.org On 07/15/2015 04:54 PM, Dario Faggioli wrote: > On Thu, 2015-07-09 at 12:45 +0200, Juergen Gross wrote: >> On 07/09/2015 12:24 PM, Dario Faggioli wrote: >>> On Wed, 2015-07-08 at 17:13 +0200, Dario Faggioli wrote: >>>> On Tue, 2015-07-07 at 13:16 +0200, Juergen Gross wrote: >>>>>> + /* >>>>>> + * In case of shutdown/suspend, it is not necessary to ask the >>>>>> + * scheduler to chime in. In fact: >>>>>> + * * there is no reason for it: the end result we are after is >>>>>> + * just 'all the vcpus on the boot pcpu, and no vcpu anywhere >>>>>> + * else', so let's just go for it; >>>>>> + * * it's wrong, when dealing a cpupool with only non-boot pcpus, >>>>>> + * as the scheduler will always fail to send the vcpus away >>>>>> + * from the last online (non boot) pcpu! >>>>> >>>>> I'd add a comment that in shutdown/suspend case all domains are being >>>>> paused, so we can be active in dom0/Pool-0 only. >>>>> >>>> Sure, I'll add this. >>>> >>> ...while putting such a comment together, I'm realizing that I'm not >>> sure about what you meant, or what you wanted the comment itself to >>> express. >>> >>> I mean, it is certainly true that all domains are being paused (they've >>> been paused already, actually), but that include Dom0 too. Also, we are >>> in Xen, in stop_machine context, so I'm not sure what you meant either >>> with "we can be active in dom0/Pool-0 only". >> >> We are running on the vcpu which issued the hypercall resulting in >> pausing the domains. A vcpu can't pause itself. >> > Hey, sorry it took me a bit to reply. > > Actually, I'm still not getting the "we are running on the vcpu" part. > Perhaps it's all a terminology issue that we have, and it may not be > that much worthwhile to spend a lot of time on it. > > However, the hypercall to suspend/shutdown the system has indeed been > issued by a dom0 vcpu. The call chain is this: > > XENPF_enter_acpi_sleep: > acpi_enter_sleep() > continue_hypercall_on_cpu(0, enter_state_helper) Interesting. I managed to miss this one. I'm rather sure this was handled differently when I initially wrote the cpupool stuff. So please forget my comment about Pool-0/dom0, it was from memory and is no longer or was never correct. Juergen