moving to the list:
On Jun 20, 2006, at 11:39 PM, Orran Y Krieger wrote:
Jimi, would be good to sit with you one of those times so you can
point me to the first bits of code where I should be looking, and
remind me of what I am trying to do.
In case there is no sitting time and for the benefit of the list...
*** Note: expectations below are criticisms of your time not your
talent. :-) ***
*** Warning! Manager Coding.. 'nuf said :-D ***
In xen/arch/ppc/boot_of.c you will find:
cpu = of_getpeer(cpu);
while (cpu > 0) {
of_start_cpu(cpu, (ulong)spin_start, 0);
cpu = of_getpeer(cpu);
}
of_start_cpu() takes a devtree cpu node and asks OF to start it
executing at the address spin_start, passing the third argument as
spin_start's first (in r3).
*** NOTE: we don't bother to build a function descriptor for spin_start.
you will find spin_start at the bottom of arch/ppc/ppc64/exceptions.S
The first step would be to enumerate all the CPUs by giving each one
a unique number (in r3) and having it set a bit in a shared ulong
then spin on a barrier. When all expected bits are set the booting
cpu continues.
If you are gonna wait, then you can sample time base (mftb() and
timebase_freq is one second) to know how much time goes by, if you
don't get all acks within 2-3 seconds you have a bug.
--- I expect you to get this far, and you can have your yellow belt
back ---
Later, after you have an allocator and are about to run the
"idle_domain" you should release each CPU, (making sure they all have
their own allocated stacks before they go C) and have them all
rendezvous in the idle_domain.
--- I would like you to get this far, here you can have your blue
belt back ---
After that, watch the world crumble and piece it back together.
--- I don't think I could stop you if I wanted to ---
-JX
_______________________________________________
Xen-ppc-devel mailing list
Xen-ppc-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ppc-devel
|