Selection and evaluation of an embedded hypervisor: application to an automotive platform Etienne Hamelin∗, Moha Ait Hmid∗, Amine Najiy, Yves Mouafo-Tchindaz ∗CEA, LIST (email: [email protected]) yJaguar Land Rover (email: [email protected]) zContinental (email: [email protected]) Abstract—This paper presents a methodology for selecting an criteria and then evaluating the candidates, especially when embedded hypervisor for embedded applications consolidation, non-technical and subjective criteria are in balance with based on qualitative and quantitative criteria, then describes technical ones. how this methodology is applied to the construction of an This paper proposes a methodological selection process, automotive hardware and software platform. applicable to many embedded system domains, and presents its successful application to the selection of a hypervisor for 1. Introduction a new automotive computing platform. The advent of multi/many-core SoCs in embedded sys- 2. Related work tems enables the execution of multiple software applica- tions on the same integrated circuit, possibly with very Several works address hypervisor evaluation and com- different requirements in terms of performance, security, parison. We can cite Patel et al [2] who present the open safety criticality, and lifecycle management. The realization source embedded hypervisor Xvisor and compare it against of the full potential of such platforms involves the use of two of the commonly used hypervisors KVM and XEN ac- multiple software computing domains, often managed by cording to factors that affect the whole system performance. different operating systems, on the same physical device. Experimental results on ARM architecture prove Xvisor’s To host a diversity of software computation payload, either lower CPU overhead, higher memory bandwidth, lower lock a hardware or a software solution can be considered. The synchronization latency and lower virtual timer interrupt hardware solution consists in dedicating to each software overhead and thus overall enhanced virtualized embedded computing domain a distinct core or cluster on the platform. system performance. In [3], Shimada et al. have presented While providing a good isolation of domains, it does not an evaluation of their designed hypervisor according to four enable efficient sharing of hardware resources. The software main criteria: boot time, communication overhead, CPU solution is virtualization [1]. It provides a software envi- time overhead for intensive tasks and latency of interrupts. ronment on which programs or complete operating systems We did not find microbenchmarks suitable for embedded can run simultaneously, as if they were running natively on hypervisor evaluation. However, some OS benchmarks such hardware. The software layer providing this environment is as LMBENCH [4], UnixBench [5] and HBench-OS [6], [7] called Virtual Machine (VM). Multiple VMs can thus run provide metrics that can be used for hypervisor evaluation. almost transparently on a single hardware device, managed A common limitation of several of these previous works by a hypervisor which provides an abstraction layer between is that they advocate a specific hypervisor solution, and the physical hardware and the VMs. However, due to shared therefore focus on their specific performance advantage. resources, some interference may occur between virtual Moreover they usually use a very technical evaluation ap- machines. proach with many details (microbenchmarks), which can be Several forms of virtualization may be applicable to far from the realm of a real-world business-driven decision. embedded software consolidation. Virtualization solutions Our methodology proposes a balance technical criteria (al- are usually classified as type-I (bare-metal hypervisor) or though less detailed than several related works) with non- type-II (hypervisor hosted inside a bare-metal, full-featured technical criteria, in a methodological approach. operating system), microkernel-based hypervisors being a hybrid between both, where the VMM (virtual machine 3. Approach manager) runs over a small microkernel or separation kernel. Deciding among the available hypervisors which ones We propose a rational and practical approach to selecting are more suitable is not an easy task as it requires eliciting an embedded hypervisor for a specific domain needs. First, This work was done while all authors were research engineers at CEA, the user needs have to be turned into selection criteria. LIST. Based on user requirements, on knowledge of embedded hypervisors and of applications of the domain, we propose possibility of a long-term relationship between the a set of criteria, both qualitative and quantitative, which integrator and hypervisor editor (or open-source detail specific characteristics, features, or metrics, that can community) needs to be assessed, as well as le- be evaluated for each particular solution. gal/contractual constraints. It however would be prohibitive to evaluate all metrics • Required vs. nice-to-have features: some features on all hypervisors, and approach selection as a maximization are strictly necessary to certain users (e.g. ”support process. Instead, we propose a multi-step filtering process the ARMv8A instruction set”), while some others where at each step the most blocking or most easily- may be added later (e.g. support a specific driver), evaluated criteria are used to reject a number of solutions, so and only represent a limited additional cost. that the subsequent steps can devote more effort to evaluate • Objective vs. subjective evaluation: several crite- in depth a reduced number of solutions. ria are uneasy to assess objectively e.g. ease of We propose a list of evaluation criteria, grouped into the use. Moreover, many technical criteria (e.g.context- following classes: switch performance, inter-VM interference), while objectively defined, can only be evaluated on a spe- • Main features cific hardware, and in a specific configuration. The – hypervisor type (type I, type II, microkernel- definition of test cases and hypervisor configurations based) may not accurately model the actual field usage – supported hardware architectures (e.g. configurations. For these reasons, all quantitative ARMv8A, x86/64, etc.) criteria are regarded as an estimation only and are – supported OSs (e.g. full-virtualized Linux, subject to interpretation. paravirtualized RTOSs) – communication services (e.g. inter-partition 4. Application in the automotive domain comms, virtual network) – exposed APIs (e.g. Posix PSE-53, OSEK, In collaboration with the Renault-Nissan Alliance within ARINC653, etc.) the project FACE “Future architecture for Automotive Com- – real-time support (time-driven or priority- puter Environment“1, CEA has designed a centralized com- driven, preemption model, resource monitor- puting hardware and software platform. This platform shall ing model, etc.) serve as a generic computing unit supporting various ve- – safety & security services (memory partition- hicle product lines, designed to host several heterogeneous ing, health monitoring, fault-tolerance, etc.) software appliances ranging from e.g. hard real-time control Industrial maturity & business model to soft real-time CPU-intensive ADAS processing and best- effort multimedia applications. These appliances may be – application domains and success stories (how developed, deployed and updated independently by vari- many prototypes or industrial products that ous software providers. In this context, we applied the rely on a version of that hypervisor) methodological selection process presented above to select a – available safety & security qualification pack- suitable candidate. Choosing a software platform for a wide ages (e.g. generic qualification package like range of product is a long-term strategic decision, there- automotive SEooC or Common-Criteria EAL fore business and strategic stakes are as high as technical, certification, or successful use in a safety- or performance-related ones. security-qualified product; applicable restric- Our selection process was performed in 3 steps. At each tion for safety- or security-qualified usage) step, several criteria are used to select a limited number of – toolset (availability, and ease-of-use of devel- candidates for further analysis, as illustrated in figure 1. opment environment, configuration, debug, analysis tools) 4.1. Selection process overview – licensing model (e.g. open-source, flat rate or per-product license fee) At first, list of 23 embedded hypervisor solutions was – business model (available support, applicable identified, both open-source and commercial ones. These regulation, partnership model) were then scrutinized together against the main discriminat- These criteria are characterized along the following as- ing requirements of: pects: • real-time support, • Qualitative vs. quantitative: many qualitative crite- • available safety/security qualification package, ria are easily evaluated from public documentation, • estimated industrial maturity (assessed based on and may therefore be used in early selection steps; known industrial uses of the hypervisor) and avail- whereas most quantitative criteria should be mea- able support. sured on target, which is a more costly process. 1. http://www-list.cea.fr/en/media/news/2019/409-february-19-2019- • Technical vs. non-technical criteria: besides tech- face-powers-automotive-innovations-by-revolutionizing-electrical-and- nical compatibility and