Embedded virtualization: Out-of-the-Box and into-the-fire?
In the light of recent announcement of Mentor Embedded Hypervisor and discussions about embedded hypervisor technology, I am pleased to have another opportunity to host the ramblings [his word] of my colleague Faheem Sheikh. I would question his implying that it is easy to make a perfect cheese omelette from a recipe …
An oft-cited analogy for software working out-of-the-box (OOTB) is that of cooking a recipe. Given the right ingredients (installers, prerequisites etc.) it should be sufficiently easy to follow the steps and try out a dish (use software). By extension, just like a good recipe is flexible enough for the cook to adapt the dish to her taste, so it should be the case for a user to build/configure software according to her requirements. While the context here is an open source embedded virtualization product, there are no points for guessing which part of the analogy is hard to maintain in most software projects.
A type 1 virtualization product for embedded systems typically needs multiple guest operating systems, applications/middleware for a market vertical, a monitor software, virtual and physical drivers in addition to some platform specific code to work on a piece of silicon (like ARM TrustZone support, for example). As usual for an embedded software domain there is a lot of diversity for each of these components. This makes OOTB embedded virtualization a little harder than a cheese omelette recipe. Its like cooking a recipe with too many types of ingredients to chose from and not every combination results in an edible dish. An embedded virtualization product might work well with a selected set of components, but, to really be useful in the wider scheme of things, it has to be able to glue together a variety of platforms and guests. As always, the right set of tools can help – tools that provide a clear workflow and flexible configuration system.
Workflow is important not only for the initial OOTB experience but also for providing a clear path to try out a custom solution. A simple GUI can help verify the installation of virtualization components based on user inputs. For instance the product might support many flavors of Linux, realtime operating systems and AUTOSAR OS on various different platforms, but, given the user’s choice of guest(s) and hardware, a narrowed down list of component is verified. These selections also impact some of the features supported by monitor software. Tools that help setup a build-tree/workspace where only user required components are visible, ready to be patched, configured and built, can reduce the overall complexity. The output of this workflow tool should be able to feed into multiple build/configuration systems.
Typically guest operating systems, their applications and monitor software are all standalone software projects. Most have their own preferred configuration/build tools like auto-tools, custom ‘make’ based systems, bitbake, Scon etc. This leads to an embedded virtualization build tree with a motley collection of configuration tools. One impact is that configuration settings are in distributed places, which can soon become a maintainability and scalability issue. The other extreme of forcing participating virtualization components to a new configuration system is a case of diminishing returns, especially when there is little paravirtualization code to begin with. OOTB can benefit from a centralized configuration tool that can pass information across various build/configure system and make all necessary updates based on user selection of virtualization options.
Another area where well designed interface can hugely improve OOTB experience is the resource assignment to virtual machines. Doing that statically at build/configuration stage makes is easier to setup memory regions and their sizes, list of devices available to guest etc with the help of metadata processing tools. Dynamic resources assignment, on the other hand supports the management of virtual machines at run-time. It promises features such as hot-plugging a virtual device but can increase the monitor footprint.
Without the right tools, operating within well-designed interfaces, a user can quickly be overwhelmed by the number of steps when attempting to deploy a virtualization solution on an embedded target. Out-of-the-box embedded virtualization experience can then quickly turn into a case of putting all the ingredients into a pan and hoping for the best!
—
Plenty of information is available about the Mentor Embedded Hypervisor, which ensures a good OOTB experience.
