On Wed, Aug 15, 2012 at 10:24:39PM +0800, Lei Wen wrote:
Hi Linaro,
I get confused when reading the switcher reference code recently: http://git.linaro.org/git/arm/big.LITTLE/switcher.git
What I cannot understand is in bootwrapper, that code would be running on all cpus, and then only cpu_id=0 and with BOOT_CLUSTER would be survive to go to the next stage of booting kernel, while the others would be kept in wfi to wait till FLAGS_SET gotten updated.
In this reference implementation, the switching is done by stand-alone code which acts as a hypervisor.
The hypervisor code gets booted on each CPU via this call in c_start():
enter_nonsecure_world((unsigned)bl_image);
... before they go to sleep in secondary_main().
I believe that the code assumes that the secondary cluster is initially held in reset (this is the default behaviour of the ARM fast model).
After booting, an OS can migrate logical CPUs from one cluster to another by using an HVC call to send a request to the hypervisor code.
The HVC dispatcher is in big-little/virtualisor/virt_handle.c. The HVC_SWITCHER_CLUSTER_SWITCH call is routed to big-little/switcher/ async_switchover.c:signal_switchover(), which is responsible for the whole cluster switch, including any power-up or power-down of CPUs and clusters.
So my question is how could the bootwrapper hind another cpu in one cluster from the kernel's view? I mean how bootwrapper make another cpu in the same cluster as outbound, so that when switch happen, it could take into inbound?
In my understand for kernel's SMP, it would bring up all cores later, so I cannot see where kernel could power down another cluster.
I'm not sure that I understand your question fully.
In this kind of implementation, the hypervisor would be responsible for most aspects of power handling. The virtualisation support in the CPU allows CPUs to be hidden from Linux, and also allows CPU IDs and interrupt routing to be "faked" so that Linux does not see any change when it is migrated onto a different physical CPU by the hypervisor.
Linaro is currently working on a different implementation which gives Linux much more control over the whole process, and avoids the over- heads associated with using virtualisation for this purpose, but the code is not ready to be published yet.
Does this answer your questions?
---Dave