On Mon, May 10, 2010 at 11:48 PM, Juergen Gross
> No. It happens when idle vcpus are allocated. At this time there is no
> existing, all physical cpus are marked as "free", e.g. they are in no pool
> Dom0 vcpus are allocated in Pool-0. This pool is created after allocation of
> the idle vcpus.
Yeah, I spent some time tracing through the init code yesterday and
figured that out. So it appears that at init time, regarding cpupools
* init_idle_domain() calls schedule_init(), which calls ops->init()
with a sort of "default" ops pointer. It also calls sched_init_vcpu()
for idle domain's vcpu 0, which will call ops->alloc_pdata for cpu 0.
* smp_prepare_cpus will eventually call do_boot_cpu for each online
cpu. do_boot_cpu will initialize the idle_domain vcpu for that cpu,
which will call ops->alloc_pdata for that cpu (again, with cpu 0
- At this point, all online cpus have had alloc_pdata called, albeit
for the "default" ops structure in the scheduler
* cpupool_create will create cpupool 0, calling sched_init(), which
calls ops->init with the cpupool0 ops structure.
* cpupool0_cpu_assign will then un-assign all online cpus from the
"default" ops structure and re-assign them into cpupool 0.
Re-assigning looks like this:
- First call alloc_pdata and then alloc_vdata for the new cpupool ops
structure, for the physical cpu and idle vcpu respectively.
- Ticks will be disabled on the old ops structure, then resumed on
the new ops structure
- The idle vcpu is added to the new pool
- Calls free_vdata and free_pdata on the old cpupool ops structure
for the idle vcpu and physical cpu, respectively.
Now all online cpus have idle vcpus and pdatas initialized, and set up
for cpupool 0.
Is that a pretty accurate picture?
> BTW: Allocating the percpu data of the scheduler during the allocation of
> first vcpu on this cpu was in sched_credit.c before cpupools were
Yes, I remember that. IIRC it had something to do with the timer
infrastructure not being ready during sched_init, so init_cpu was used
as a hook to set up the per-cpu tick after the timer infrastructure
had been initialized. Although, looking at the code again, it's more
likely that I thought that because when sched_init was called, only
one cpu was online.
Kier, out of curiosity, is there a reason init_idle_domain() (and thus
schedule_init()) is called so early, before all of the cpus are up?
Is it so that adding a cpu dynamically and at boot (which needs to do
in it, add an idle vcpu, &c) all take the same codepath?
> Not yet.
> I'll write something up in the next days.
Xen-devel mailing list