Hypervisors in Mobile

I received a bunch of emails today pointing to this blog from Jason Perlow. Jason has an interesting thought with regards to the Apple and HTC lawsuit that is brewing. Let me first say that I understand that companies have to protect their IP and that there are clearly important and enforceable patents out there, say Coca Cola's formula for well, Coca Cola. Apple certainly has a lot of valuable IP as well and they are spending a lot of dollars in making the user experience better. Some of these patents are vague at best, so I have mixed feelings on this and since I am not a lawyer I am going to leave it at that.

Jason's blog evolves around hypervisors and his fantasy world in which they can change the way we build mobile phones. This is not a fantasy world, in the fact that what Jason wants is technically very possible. However, it would also require alliances between some of the fiercest competitors in one of the biggest markets in the world. Unlikely to happen, however, allow me to dream with him.

Virtualization can be used separate the nuts (the piece that makes a phone talk over the network) from the glory (the piece that makes it looks pretty and provides applications), no nuts no glory, they are both needed, but they need to be kept separate. The nuts would be real-time, need to be kept secure and are proprietary to the hand-set, it contains drivers and logic to make the phone talk 3G, or 4G, whatever. The nuts is very hardware specific, it would use an RTOS.

The glory would be the user-interface, it could be any OS, it could use Java, Flash, be built by Apple, Google, Wind River (yes, we do that too), Microsoft, a hobbyist. What the glory needs is a well-defined API to talk to the nuts. Unlikely to be standardized as I mentioned above, but possible. The glory is the part that you could install as per Jason's story.

The important part is the separation, many mobile operating systems currently have nuts and glory combined into one (Android for example), but to make Jason's blog a reality, would require to split them.

Mobile is only one of the markets that can benefit from a story like the one Jason mentions. Generalizing the solution here, what we are really doing is enabling multi-OS on a single piece of hardware. That hardware can be multicore or single core, we have customers with both.

The enabling technology for Multi-OS is virtualization through a hypervisor. A hypervisor allows one to run multiple different operating systems, strongly partitioned, fairly scheduled. It is a breakthrough technology for the embedded market and it enables new thinking.

To give another example in industrial control: Many industrial control devices currently consists of 2 separate boxes, talking together over ethernet to provide a single solution, one box handles real-time (VxWorks), the other the UI (Windows, Linux). Ethernet is notoriously not real-time, but if your timing requirements are in the milliseconds, then ethernet is ok.

Moving to a single multi-OS solution on a single chip (single- or multicore) would remove the need for ethernet and replace it with communication over shared memory. All of a sudden the latency for communication improves dramatically. It goes from milliseconds to microseconds and this drastically changes what this particular device could do, giving the manufacturer (one of Wind River's customers) a strong leg up over the competition.

These types of examples exist for virtually every industry that uses embedded systems and I spend my days talking to customer explaining how they need to get on the virtualization band wagon or they will miss the next revolution in embedded systems.

The revolution is happening now, thanks Jason for your views on this this and thanks for calling my video 'geeky', that was kind of the intent :)


1 Comment

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>