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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
