Bosch's division of in-vehicle systems is usually divided into 5 major domains: power domain, chassis domain, body domain, smart cockpit domain and adas automatic driving domain. With the development trend of centralization of ECU integration, giants such as Volkswagen and Huawei have merged the power domain, chassis domain and body domain into the vehicle control domain, which is divided into three major domains. The following figure is the 2-domain architecture diagram of a car company, which omits the vehicle control domain. This article mainly involves the relationship between the hypervisior, qnx, and android system in the smart cockpit domain.
Vehicle architecture diagram divided into two domains
1 Introduction to virtualization
There are many resource isolation technologies, including hardware isolation, virtualization isolation, container isolation, and process isolation from the bottom layer of the hardware layer up. The hardware isolation domain has the best performance, safety and reliability, but its flexibility and configurability are poor, and hardware sharing cannot be realized, which leads to poor resource utilization of the entire system and cannot fully achieve the goal of software-defined vehicles.
Container isolation and process isolation can realize business isolation at a lighter weight. However, there are hidden dangers of resource interference and mutual security attacks in the same operating system, and it cannot support the integration of business domains of heterogeneous operating systems, which affects traditional business inheritance. , is not conducive to ecological development.
Virtualization is a safe, reliable, flexible and preferred solution, and an important supporting technology for software-defined vehicles. This article mainly involves the hypervisor bare-metal virtualization technology. The hypervisor runs directly on the SOC, and there is no host operating system Host OS in between. As shown in the following figure Type1:
In the automotive field, Hypervisior mainly completes the following tasks:
-
CPU virtualization: provide VCPU resources and operating environment for virtual machines;
-
Memory virtualization: Responsible for allocating and managing hardware memory resources for itself and virtual machines;
-
Interrupt virtualization: When interrupts and exceptions occur, the interrupts and exceptions are routed to the virtual machine for processing as needed;
-
Virtual machine device simulation: Create virtual hardware components that virtual machines can access according to requirements;
-
Hardware support BSP: provide board-level support package for Hypervisor running on SoC, such as serial port driver;
-
Virtual machine resource configuration: configure and manage resources such as CPU, memory, and IO peripherals of the virtual machine;
-
Virtual machine communication: Provide communication mechanisms such as IPC and shared memory for virtual machines.
-
Virtual machine scheduling: Provide scheduling algorithms such as priority and time slice for virtual machines;
-
Virtual machine lifecycle management: create, start and stop virtual machines;
-
Virtual machine debugging service: provide console, log and other debugging functions;
Paravirtualization
In the development stage when the hardware-assisted virtualization technology is not perfect and powerful, or for the sharing and multiplexing of some complex peripherals, in order to avoid the performance problem of full virtualization, the paravirtualization technology of GuestOS and Hypervisor cooperation can be used. This technology is generally applied to IO device virtualization, using front-end and back-end methods to realize IO device virtualization. The front-end driver is implemented in the Guest OS (VM2 is marked with android system), and after it is implemented in Hypervisor or Host OS (VM1 is marked with qnx system) The front-end driver is generally implemented according to the VirtIO standard, and the back-end driver is the actual accessor of the hardware. The front-end driver in the Guest OS communicates with the back-end driver through a communication mechanism such as Virt Queue, and the front-end driver on the android side passes the request from the Guest OS to the back-end driver on the qnx side, and the back-end driver sends the request to the hardware driver, and sends the result after processing Then pass it back to the front-end driver. Paravirtualization has better hardware performance than full virtualization, and can implement relatively complex hardware, such as: block devices, network cards, display devices, etc., as shown in the following figure:
Paravirtualized Pass-through resource allocation
The Hypervisor supports direct allocation of hardware resources to the Guest OS in the virtual machine on it, without address and instruction translation through the Hypervisor. For example, resources with abundant interfaces such as serial port resources and USB resources can be directly assigned to a virtual machine through Pass-through. The device controller is generally accessed in MMIO mode, so it is only necessary to map the controller address area to the VM to realize the allocation of the device controller. At the same time, it is also necessary to assign a virtual interrupt corresponding to the device hardware interrupt to the VM, directly The way of transparent transmission is that the VM exclusively accesses the hardware, so it is the best in terms of performance.
三 qnx hypervisor
This picture is provided by Qualcomm's official website. The virtual machine management program hypervisor includes a virtual machine management program microkernel and one or more qvm process instances. In a QNX hypervisor environment, a virtual machine is represented as a qvm process. The qvm process is an operating system process running in the Hypervisor outside the kernel.
have to be aware of is:
1 The Guest OS does not actually run in the VM. The hypervisor does not translate the guest's instructions on the physical CPU. The VM presents the defined virtual hardware and pass-through hardware to the Guest OS, while the Guest executes instructions on the physical CPU as if there were no hypervisor. Only when the Guest executes instructions that are not allowed, or accesses the guest memory and virtualization hardware monitored by the Hypervisor, the Hypervisor will catch the exception and force the Guest to exit. Personal understanding: hypervisior is similar to a monitoring role.