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
