By Jim Trudeau

Multicore processors are the leading edge of the technology wave for a lot of reasons. One of them, as Ken Hansen, Chief Technology Officer at Freescale pointed out at the Freescale Technology Forum, is that “…device physics are dictating that the only way that we can continue to get performance improvement at reasonable power is to go to a multicore approach.”

From a software perspective, as Rob Oshana noted in the Top 3 Keys to Multicore Software Development, the advent of all this processing real estate can be daunting. One of his keys was system virtualization, which hides some of the complexity from the developer and provides flexibility.

Back in the old days of simple 4- and 8-bit processors with limited instruction sets and memory, programming complexity was like the layout of your house. It was conceptually pretty simple.  As processors advanced and memory footprints grew, you metaphorically hit planetary scales of complexity, but with good mapping tools it was still familiar territory. With multicore, you’re going interplanetary and there are Klingons out there!

On the Freescale P4080, for example, there are 8 cores. With all this real estate to play with, a very common use case is running multiple operating systems, or multiple instances of the same operating system on one core or multiple cores. However large the memory map, it is still limited and must be either partitioned or shared. Similarly, all other system resources must be allocated to the running applications. There are any number of ways of slicing up this resource empire, and a virtually infinite number of ways of getting into trouble.

Multicore programming is analogous, only a level more complex. Instead of multiple applications sharing a single processor, think multiple operating systems (and their multi-tasking applications) sharing multiple cores on a single processor. This is called asymmetric multicore processing (AMP) – different OSs or multiple instances of the same OS running different code on different cores simultaneously. My colleague Tom Thompson wrote about this topic in Asymmetric Processing Makes the Most of Multicore Processors not too long ago.

In unsupervised AMP, as developer you must ensure that there are zero resource collisions. You own the entire universe. If any process running on any core breaks the rules, it could take down the entire system. This is difficult, to say the least, and really not necessary. There is an alternative. In the desktop paradigm, applications had user-level authority and a well-designed OS had supervisor authority to prevent one app from taking down the entire system.

In supervised AMP in the multicore environment, there is a higher power, the hypervisor. The hypervisor rules over the highest processor privilege level and controls access to system resources. It does so by isolating each partition in a separate universe, a virtual machine of its own. Of course, the reality is that the OS living inside that virtual machine must occasionally stray outside its virtual world to access global system resources. Those excursions are controlled by the hypervisor, which is responsible for stability and security of the platform as a whole. By analogy, you can think of the hypervisor as a kind of meta-OS.

The Freescale P4 Series processors (PDF) have virtualization support built into the hardware (based on Power ISA 2.06), so software vendors can build hypervisors on this platform. At Freescale, we want to enable you, not limit you. We put the capability in the hardware, and we created our own hypervisor. We also enabled our ecosystem partners to provide hypervisors for the P4080 as well, including ENEA, Green Hills, and Wind River.

Support for hardware-assisted virtualization in the Freescale P4 series means that the overhead involved in running a hypervisor is significantly reduced. For example, in addition to the higher level of privilege instituted at the hardware level in the P4080 there is a new set of registers important to servicing exceptions and interrupts. Performance critical details like these are discussed in great detail in a Freescale technical white paper, Hardware and Software Assists in Virtualization.

A hypervisor allows a developer to securely run one or more operating systems (or multiple instances of the same OS in defined partitions. The hypervisor controls access to memory, peripherals, and other assigned resources to ensure no OS steps outside its bounds. Shared or unique resources like the interrupt controller are strictly managed.

With a hypervisor you can turn the P4080 into two, three, or more different machines at once, all interacting, yet essentially independent, with the hypervisor ensuring that the system stays in order. It’s possible to imagine the P4080 running Linux, a real time OS, and a simple scheduler, each in its own partition. The permutations are limitless.

As developer, you need to know your hypervisor. You’ll need to consider what you want and need from a hypervisor when you consider your software development effort on a multicore platform.

You can do without a hypervisor, but assuming you’ll use one, you have choices to make. You’ll need to configure it. What kind of configuration tool comes with the hypervisor? It might be a simple configuration file, or a fancy user interface. More importantly, what are some of the underlying capabilities of the hypervisor? For example, is it a real hypervisor or does it just manage the boot process and then disappear? How does it handle inter-partition messaging? Can one partition be master, and allowed to launch or kill others? Can I/O devices be shared? What is the performance overhead penalty incurred by using the hypervisor? What are the facilities for debugging guest OSes? How is the management of hardware error conditions handled?  I’m sure you’ll come up with a host of questions.

Like choice of operating system, choice of hypervisor is now part of your universe when it comes to software development for a multicore environment. Welcome to hyperspace.