Re: [PATCH v2 1/2] xen: sched: don't call hooks of the wrong scheduler via VCPU2OP

[George Dunlap <george.dunlap@citrix.com>]

On 17/03/17 18:19, Dario Faggioli wrote:
> Within context_saved(), we call the context_saved hook,
> and we use VCPU2OP() to determine from what scheduler.
> VCPU2OP uses DOM2OP, which uses d->cpupool, which is
> NULL when d is the idle domain. And in that case,
> DOM2OP just returns ops, the scheduler of cpupool0.
> 
> Therefore, if:
> - cpupool0's scheduler defines context_saved (like
>   Credit2 and RTDS do),
> - we are not in cpupool0 (i.e., our scheduler is
>   not ops),
> - we are context switching from idle,
> 
> we call VCPU2OP(idle_vcpu), which means
> DOM2OP(idle->cpupool), which is ops.
> 
> Therefore, we both:
> - check if context_saved is defined in the wrong
>   scheduler;
> - if yes, call the wrong one.
> 
> When using Credit2 at boot, and also Credit2 in
> the other cpupool, this is wrong but innocuous,
> because it only involves the idle vcpus.
> 
> When using Credit2 at boot, and Credit1 in the
> other cpupool, this is *totally* wrong, and
> it's by chance it does not explode!
> 
> When using Credit2 and other schedulers I'm
> developping, I hit the following assert (in
> sched_credit2.c, on a CPU inside a cpupool that
> does not use Credit2):
> 
> csched2_context_saved()
> {
>  ...
>  ASSERT(!vcpu_on_runq(svc));
>  ...
> }
> 
> Fix this by dealing explicitly, in VCPU2OP, with
> idle vcpus, returning the scheduler of the pCPU
> they (always) run on.
> 
> While there, rename VCPU2OP itself to something
> that makes it easier to understand what it does.

This seems to have been moved into patch 2/2 -- I'll remove this
paragraph on commit if that's OK with you.

 -George


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel