[Nexus S Q&A, Help & Troubleshooting] plaguethenet:
The radio is a real time operating system. I'd imagine that halting the CPU and bringing it back up is too costly for the radio, and therefore would be prevented by the radio. As far as WoL like functionality, I don't see any chip on the board that could provide that for the radio (or indeed anything for that matter). The only thing that has any radio capability is the main Application Processor, which has to be shared.

I get a bit excited and tend to get very technical and often miss things or seem like I'm trying to argue when i'm not. I just wanted to clarify that it wasn't intended as such.

The freezing may only be for android though, You can independenly suspened/halt and resume virtualized applications (Either at their request, or preemptively). So its entirly possible for Deep Idle to behave properly in android, but not have the overall effect that one would think it would have. The processor would have much less to do and as such it likely does have some effect but the allowing an OS to execute such a disruptive instruction defeats the purpose of virtualization, if that makes any sense. Indeed the virtualized machine is halted, and nothing else is executing in the virtualized instance during this time. But the radio and Microvisor are very much alive during this. (You wouldn't be able to get an incoming call if they weren't.)

So in summary my argument is this:

Android cannot completely disable the CPU, this would cause NUMEROUS issues with the underlying radio software. WoL/WoR like functionality would be implemented in the radio software, From a development standpoint the complications FAR outweigh the benefits of such a design, It would not be fiscally responsible to design radio software in this way. If the processor were truly off, the microvisor would be unable to run and it would defeat the purpose of having said microvisor in the first place.

It would appear to android that the CPU Was off, and everything would halt (for android only). This should produce some battery savings (As even when idle an android system as some upkeep to do), but no where near the kind of savings you'd see with a truly halted CPU (that is woken by external interrupts). I will admit I was unaware additional testing was done.

If the system was truly halted for any period of time, When it was woken, the radio would be disconnected and would have to reconnect. You'd lose the ability to get notified of an incoming call or text (and to the cell network, your phone would be offline). You'd know if the cpu was TRULY frozen/halted/suspended.

Now, I'm not saying that the CPU Can't be put into a stopped state, just that android itself cannot make this happen. The microvisor would need permission from the radio, and the microvisor itself, would also need to be set to sleep as well. The radio is unlikely to give permisison, and as long as the microvisor, any of its children, or server processes, require the CPU, it will not actually happen. But the OS that halted itself will enter a fake halted state. (In reality, the hyper/microvisor would replace a HLT with a NOOP and stop executing the child. To the child this seems like being halted, but other things are still at work here.)