Hi Dave,
[snip here]
We don't use the virtualisation extensions for this in our current code. It just becomes normal kernel code, analogous to subsystems like cpufreq and CPU hotplug.
Virtualisation is only really needed if we want to trick the OS into thinking that it is not really being migrated between different physical CPUs. This approach has the advantage that it can work with any OS, with no need for modifying the OS. But because we can modify Linux so that it understands and controls the switching, virtualisation is not needed.
This also makes it easier to use the virtualisation extensions for running true hypervisors like KVM, because we don't have to work out a way to let KVM and the switcher co-exist in hypervisor space.
In kernel implementation is a very elegant way to handle the coexisting of switching and kvm. :)
While in-kernel implementation is using paired-cpu switching way, I think it is more close to Big.Little MP solution, which also has both A7/A15 alive. The only different here is that paired-cpu allow one cpu in pair alive. I don't know whether I understand it right, system may run with both A7/A15 existed. Correct me if I am wrong. :)
So does this in-kernel implementation take the consideration of load-balance issue which is also faced by the MP solution, since the computing capability difference? Or linaro just did the paired-cpu switching for all A7/A15 pairs, which would mimic the cluster switching in the ARM's reference code?
I am curious to know which implementation linaro finally choose. :) Many appreciations for all the support.
Thanks, Lei