The Beauty Of Partitioning

Developing for multicore often asks for new approaches to architecting embedded systems. A low-core-count multicore processor, say a 2 or 4 core processor, could be configured to use a single operating system in a SMP configuration. This would give one single OS control over both cores and is often a valid configuation. The OS should have features such as core affinity and core reservation. The former will lock a process to a core, but will allow other processes to use the core as well, the latter reserves a core for the exclusive use of a single process.

There are three main challenges with this:

1. Performance. System calls in an SMP operating systems are often slower than in an OS running on a single core. This may not seem like a lot, but keep in mind that serialization is the enemy of parallelization. Say that 5% of the application and/or the application's use of the operating system is serialized, then this has a significant impact on scalability. See Amdahls Law at Wikipedia for more details
2. Separation. A single operating system means a single point of failure. A reboot of the OS would reset the entire system, which is in many systems unacceptable. An OS could need a reboot because of a bad driver, bad hardware, software updates, or sometimes even if a process crashes badly.
3. Different OSes. Being able to run different operating systems for different tasks, such as realtime and graphical user interfaces, or networking.

Being able to partition that multicore system in multiple different virtual machines, each running it's own operating system instance, allows the system designer to utilize the multicore chip in a different fashion. This partitioning is done by a hypervisor that owns the hardware and assigns resources (cores, memory, devices) to the different virtual machines. The hypervisor can partition the hardware multiple different ways into multiple virtual machines, the developer can allocate many virtual machines to a single core, or allocate multiple cores to a single virtual machine.

However, this partitioning presents us with new challenges: how to get access to the different virtual boards. There could be N virtual machines on the physical processor and we need to get console and debug access to all of these.

One way to do debugging is through a JTAG probe as explained in this video.

Another way to do debugging and get access to the different virtual machines is by virtualizing devices. The video below shows how to split an Intel Core2 Quad into two virtual machines. One running on 2 cores and running Linux in an SMP fashion, the other virtual machine utilizing only a single core. The serial and ethernet devices have been shared, so console and network access to the second VM is available even though the second VM does not have access to the physical devices.