>>> On 29.09.15 at 18:55, <dario.faggi...@citrix.com> wrote: > This happens because, right now, the scheduler of the > target pool remaps the runqueue lock during (rt_)alloc_pdata, > which is called at the very beginning of schedule_cpu_switch(). > Credit2's csched2_free_pdata(), however, wants to find the spin > lock the same way it was put by csched2_alloc_pdata(), and > explodes, it not being the case. > > This patch also fixes this as, now, spin lock remapping > happens in the init_pdata hook of the target scheduler for > the pCPU, which we can easily make sure it is ivoked *after* > the free_pdata hook of the old scheduler (which is exactly > what is done in this patch), without needing to restructure > schedule_cpu_switch().
Hmm, while I can see this to be okay for the cpupool_unassign_cpu_helper() case (due to the call to cpu_disable_scheduler() up front) as well as for the cpupool_cpu_add() one (I take it that the CPU can't be scheduled on in that case), I don't see how this would be safe for the XEN_SYSCTL_CPUPOOL_OP_ADDCPU case: How is scheduling activity being prevented to happen after the new ppriv got installed, but before it gets initialized via the init_pdata hook? Or how would scheduling activity be safe with an allocated but not yet initialized ppriv? Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
