>>> On 17.03.17 at 19:29, <jgr...@suse.com> wrote:
> On 17/03/17 19: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.
>>
>> Signed-off-by: Dario Faggioli <dario.faggi...@citrix.com>
>
> Reviewed-by: Juergen Gross <jgr...@suse.com>
This came through twice, so I'm now wondering whether one of
them was meant for 2/2, or whether this was just some
infrastructure glitch.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
