Devices! Devices! Devices!

That is what embedded systems is all about: handling devices. An embedded software system has input devices and output devices and some amount of software running on operating systems, running on hardware that turn input into output. The trick is to handle the input in a fast an deterministic way and generate output in a fast and deterministic way. Determinism is important all the way through the system, from the device, to the hardware, to the operating system to the software running on the operating system


Add virtualization to the picture and quickly understand that not all virtualization layers are created equal. Especially in the area of IT-virtualization the focus has been on abstraction of the physical environment, which includes devices. This means that often the software does not have access to the physical device, it has access to a device-driver inside the hypervisor that 'owns' the device.

And abstraction quickly impacts determinism and real-time aspects such as latency. A true embedded Hypervisor gives the system designer full control over how he wants to handle his devices such that the designer can minimize the impact in the areas where determinism is crucial for the embedded device.

A true embedded hypervisor (such as the Wind River Hypervisor) provides a device management infrastructure that provides multiple options as to the handling of devices:

The first and most simple option available is to partition. That is, given a set of devices, partition them between the virtual boards running on the processor. Say your hardware has 2 PCI busses and 2 virtual boards, give one PCI bus directly to each virtual board and assign the devices on the bus to the virtual board. Now you have a nicely partitioned system and the hypervisor does not need to intervene, hence there is absolutely no impact to the determinism in your system.

The second option is to share, assign the device directly to one of the virtual boards and the operating system in that virtual board owns the device. The software in that virtual board has direct access to the device and hence no impact to the determinism. If another virtual board needs access to the device you can export it through a inter-board messaging protocol. The second virtual board has access, but it is slower and non-deterministic. If this is okay, then we have an easy solution.

The third option is to virtualize the driver into the hypervisor. This is where we are starting to add a layer of delegation into the device handling path, so we need to make sure we write the driver carefully, consider core-interaction in the design (driver running on core 1, virtual board that uses it on core 2, hence more inter-core communication) and make sure that we keep our worst-case execution times in check. We also have to consider multiple users (which is why we are using virtualization, if there was only a single user we could use partitioning) and how it impacts our performance.

Give your Wind River representative a call if you are planning your next generation of embedded system and he can help you design a way to include virtualization into your system without impacting the determinism you require.