Edited from: https://new.qq.com/rain/a/20230127A00LE200
With the development of ICT technology, the computing power of a single SOC can undertake more services. Features such as network bandwidth expansion, low latency, and differentiated services make service deployment and function allocation more flexible, such as: perception, integration, planning, control, and execution. Separation and decoupling, automotive business functions can be separated or combined, and can be defined by software. The electronic and electrical architecture has changed from a distributed architecture to a domain-centralized architecture, and then to a centralized centralized architecture. The decentralized ECU functions are integrated into domain controllers and even vehicle-mounted central computers. This is multi-domain integration.
The underlying hardware of automotive electronics is no longer provided by a single chip for simple logic calculations, but requires complex multi-core SoC chips to provide more complex control logic and powerful computing power support. However, multi-domain services have different technical requirements. For example, the cockpit domain IVI business emphasizes interactive experience and rich application ecology. The more suitable operating system is Android; RTOS; Zhijia domain emphasizes large computing power fusion perception, deduction planning, and also has real-time and reliability requirements, and will also choose RTLinux and RTOS. At the same time of domain integration, it is necessary to ensure the safety and reliability of key services, and also consider the sustainability and compatibility of application ecology. This requires resource isolation technology to support resource segmentation on the same SOC, and can run multiple operating systems concurrently. Ensure mutual non-interference.
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. Hardware isolation has the best isolation, and a single isolation domain has the best performance, security and reliability, but its flexibility and configurability are poor, and hardware sharing cannot be realized, resulting in poor resource utilization of the entire system, which 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. Among many resource isolation technologies, virtualization is a safe, reliable, flexible and preferred solution, and an important supporting technology for software-defined vehicles. A typical application scenario is shown in Figure 1:
Figure 1 Typical application scenarios of virtualization
Technical form
The literal translation of Hypervisor is "Super Supervisor", also known as Virtual Machine Monitor (VMM). As shown in Figure 2, the Hypervisor is on the SoC hardware platform, which converts physical resources (such as CPU, memory, storage space, network adapters, peripherals, etc.) into virtual resources and allocates them to each virtual machine on demand, allowing them to independently to access authorized virtual resources. Hypervisor realizes the integration and isolation of hardware resources, so that applications can not only share physical hardware such as CPU, but also rely on different kernel environments and drivers to run, so as to meet the needs of diversified application scenarios in the automotive field.
Figure 2 The position of virtualization in the system
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;
In the automotive field, Hypervisior also faces the following challenges:
Lightweight and efficient. While the hypervisor brings software-defined flexibility, it also leads to an increase in the level of the software stack, which inevitably leads to performance loss. The cost-sensitive nature of the automotive field is doomed to reduce the performance loss of CPU, storage, network, GPU and other peripherals throughout the entire vehicle project, so the lightweight and high efficiency of the Hypervisor is very important;
Safe and reliable. Compared with the dynamic allocation and idle utilization of resources that are valued in the Internet field, the automotive field pays more attention to the real-time performance, reliability, and security of Hypervisor;
Easy to adapt. In the automotive field, chip types and operating systems are rich and diverse. A major feature of embedded virtualization is heterogeneity. Hypervisors must have the ability to quickly adapt to different underlying hardware and upper-level operating systems.
Technology Development Trend
2.1 Differentiation of Key Technologies for Cloud-Edge Virtualization
Virtualization technology can be traced back to the 1960s, when IBM developed a virtual machine monitor software that divides computer hardware into one or more virtual machines to support simultaneous and interactive access to large computers by multiple users. With the improvement of the computing power of general-purpose servers in the 21st century, cloud computing is booming, and cloud virtualization, which is the underlying supporting technology, is also rapidly iteratively evolving. Later, the computing power gradually sank from the cloud, edge, and end, which was accompanied by edge virtualization and end-side embedded virtualization. Their typical architecture and key technical requirements are shown in Figure 3.
Figure 3 Typical Architecture and Key Technical Requirements of Cloud-Edge Virtualization
(1) Cloud-side virtualization
Its characteristics are that the hardware platform is basically homogeneous, and a large number of nodes form a cluster. The architecture design is based on throughput capacity. It must support multi-service concurrency, and virtualization must meet the resource scheduling strategy of cluster load balancing, energy saving and consumption reduction. Cross-node virtual machine allocation During the process, it is necessary to ensure that the business is migrated without interruption. When a virtual machine fails, it must be able to recover from the checkpoint and reduce business loss. The virtual machine must be able to support elastic expansion of CPU computing power, memory, storage space, network, GPU, peripherals, etc. Improve the operating income of the data center.
(2) Side virtualization
On the edge nodes of some specific services, a common ICT architecture is adopted to support the dynamic deployment of multiple services, such as SDN and NFV. Its technical features are: based on a general-purpose hardware platform and an industry-customized management and deployment platform, it realizes software-hardware decoupling, software definition, on-demand deployment of multi-functional nodes, and flexible networking. Generally, 1+1 or N+1 redundancy is adopted To ensure high availability of services, the end-to-end real-time performance of 5G services needs to be considered in 5G telecom network elements. Hypervisors, virtual machines, and communication protocol stacks all need to be designed and considered.
(3) Device-side virtualization
The typical feature of the device side is heterogeneity, and its chip architecture and processing capabilities are quite different. Generally, it is a single-chip solution, and there is no virtual machine migration between the cluster and the master and backup. Therefore, high security and high reliability of a single node are emphasized. For example, there will be functional safety ASIL level requirements, and at the same time, it has stronger real-time and deterministic requirements. Require. In addition, end-side resources are more limited and cost-sensitive, so the Hypervisor is required to be lightweight and high-performance.
2.2 Trends in Virtualization Models
Hypervisor can be divided into two categories, one is Type1 bare model, Hypervisor runs directly on the hardware device, also called Bare-Metal Hardware Virtualization (bare metal virtualization environment); the other is Type2 hosting type, also called Hosted Virtualization (host virtualization environment). Figure 4 shows the layered architecture of the two Hypervisors.
Figure 4 Type1 and Typer2 Hypervisors
Type2 Hypervisor needs to use the host operating system to manage CPU, memory, network and other resources. Since there is a host operating system between the Hypervisor and the hardware, all operations of the Hypervisor and VM must go through the host operating system, so there will inevitably be Latency, performance loss, and security flaws and stability issues of the host operating system will affect the VM (virtual machine) running on it. Therefore, Type-2 Hypervisor is mainly used in occasions that do not require high performance and security. For example: personal PC system.
Type 1 hypervisor does not depend on the host operating system, and it has the basic functions of the operating system. The design is more concise, it runs directly on the hardware, the overall code size and structure are more streamlined, and it requires less memory and storage resources, which can meet the functional safety level requirements of the automatic driving vehicle control system, and also has the conditions for formal verification . So the automotive operating system is more suitable to use Type 1 Hypervisor.
With the development of microkernel operating system technology, the host OS that many hypervisors rely on based on microkernel operating system design has been very streamlined, including only basic and unchanged functions, such as: CPU scheduling and memory management, device drivers and other available Variable components are located outside the kernel. There are differences in the industry as to whether this type of Hypervisor should be classified as Type 1 or Type 2. Generally speaking, the microkernel Hypervisor is smaller, more stable, and more scalable, and is more suitable for embedded virtualization occasions.
2.3 Hypervisor and Virtual Machine Collaboration Technical Route
(1) Full virtualization
The initial virtualization is to simulate a computer system with complete hardware system functions and run in an isolated environment through software, that is, to provide GuestOS with virtual hardware devices through software. The advantage is that GuestOS does not perceive the external real hardware environment and does not need to be changed. Since the guest OS needs to fall into the hypervisor every time it accesses the fully virtualized hardware, it directly leads to poor performance of the virtual hardware in this way. Generally, it is only used to simulate relatively simple hardware such as serial ports. The hardware simulation can be directly simulated in the Hypervisor, or the request can be passed to other VMs for simulation, for example, simulated in a VM through QEMU.
(2) Hardware-assisted virtualization
Intel first proposed hardware-assisted virtualization technology, which directly provides shared functions by hardware, supports access by multiple GuestOSs, and reduces delay and performance loss caused by software virtualization technology. Intel proposed Intel VT-x, Intel VT-d, and Intel VT-c technologies for processor & memory, IO, and network respectively. With the improvement of ARM's computing power, from the mobile terminal to the edge, and even the cloud computing power center, ARM is also continuously enhancing its hardware-assisted virtualization technology, such as stage 2 page table conversion, virtual exceptions, etc.
(3) 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. The front-end and back-end methods are used to realize IO device virtualization. The front-end driver is implemented in the Guest OS, and the back-end driver is implemented in the Hypervisor or Host OS. The front-end and back-end are generally implemented according to the VirtIO standard. The backend driver acts as 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. The front-end driver passes the request of the Guest OS to the back-end driver, and the back-end driver sends the request to the hardware driver. After processing, the result is sent back to the front drive. Paravirtualization has better hardware performance than full virtualization, and can implement relatively complex hardware, such as: block devices, network cards, display devices, etc. The details are shown in Figure 5.
Figure 5 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.
Interpretation of key technologies
3.1 CPU virtualization and energy saving technology
Vehicle-mounted high-performance processors generally adopt a multi-core CPU architecture. Under the SMP (Symmetric Multi-Processing) architecture, the Hypervisor scheduler will allow the guest operating system to run on the specified CPU according to the CPU affinity configuration, and the operating system of the virtual machine can follow its own scheduling method, such as : Task scheduling is performed on the CPU in priority mode. In order to maximize the use of system resources, Hypervisor also supports the shared use of a CPU by multiple virtual machines. On the shared core, the hypervisor can schedule virtual machines by priority or time partitioning to ensure that the running time and scheduling policy of virtual machines are deterministic. The scheduling algorithm of the hypervisor needs to ensure that there cannot be an infinite loop or failure of a virtual machine in the partition, which will occupy processor resources for a long time, and cause the business of other virtual machines to fail to obtain a reasonable time quota.
Virtual machine scheduling also needs to consider the issue of energy saving and consumption reduction. When the workload is high, the system increases the main frequency to improve user experience, and when the workload is low, the system automatically saves energy and reduces frequency to improve battery life. The on-board high-performance processor itself is designed as a large and small core architecture in order to save energy and reduce consumption. The CPU and the complex operating system running on it need to support large and small core scheduling, dynamic frequency adjustment, low power consumption settings, shutdown of CPU cores, sleep (Suspend to RAM/ Suspend to Disk) and other energy-saving functions. After the system is virtualized, the CPU and other physical resources need to be directly accessed by the Hypervisor, and the Hypervisor scheduling algorithm also needs to complete the support for energy saving and consumption reduction of the virtual machine.
3.2 IO device virtualization
For performance considerations, paravirtualization technology is generally used in the embedded field. The paravirtualization technology requires the cooperation of the front-end driver in the Guest OS and the back-end driver in the Hypervisor. The front-end driver sends the request of the Guest OS to the back-end driver through the communication mechanism provided by the Hypervisor, and the back-end driver realizes the access to the device by calling the physical driver. This involves the ecological docking between Guest OS from different vendors and Hypervisor from different vendors.
Virtio is currently the most popular I/O paravirtualization solution. Virtio is an open protocol and interface managed by the OASIS standards group to enable virtual machines to access IO devices in a standardized manner. Virtio was officially standardized in March 2016, and version V1.1 will be released in 2020. The Virtio standard adopts a general and standardized abstract model, supports an increasing number of device types, and has high performance. It is widely used in the field of cloud computing, has a high degree of open source activity, and has stable front-end driver codes for operating systems such as Linux. Most commercial and open source hypervisors already support the Virtio standard.
Virtio is the realization of the paravirtualization technology commonly used in the vehicle industry. As shown in Figure 6, a device bus Virtio-bus is virtualized inside the Guest OS. Through the Virtio Ring two-way communication mechanism, the front-end driver and mounted on the Virtio-bus follow the Virtio standard back-end virtual device for access and communication. Virtio provides comprehensive Virtio bus and device control interfaces, including virtio-net, virtio-blk, virtio-console, virtio-input, etc.
Figure 6 Virtio virtualization implementation model
Using virtio-blk technology to realize block device sharing
A block device is a storage device that uses a cache mechanism to read and write, and is assigned to the operating system where the Hypervisor resides for management. The virtio-blk driver is a block device driver that complies with the virtio standard. The vdev virtio block is the back-end virtual block device. The virtio blk driver completes the reading and writing of the physical block device through the vdev device and obtains the execution result.
Using virtio-net technology to achieve cross-system communication
Virtio-net realizes point-to-point communication between multiple systems. The virtio-net driver inside the Guest system performs full-duplex communication with the virtio-net device of the Hypervisor system through virtqueue to realize control and configuration commands between multiple systems. , Data interaction. It is suitable for data transmission other than audio and video streams, and has good stability. Because the control logic of virtqueue is complex, it has a certain impact on real-time performance.
Realize touch sharing with virtio technology
The touch device is a character device, and the front-end driver and back-end device are realized through virtio-input driver and vdev-input. The device reports touch coordinate data to the driver through virtqueue.
3.3 Real-time technology
Real-time is the key performance index of embedded real-time operating system. The real-time performance of the Hypervisor is the basis of the real-time performance of the entire system. If the Hypervisor cannot be scheduled to run in the client operating system in time, the client operating system cannot obtain better real-time performance indicators. The main indicators to measure the real-time performance of Hypervisor include interrupt delay and scheduling delay. The interrupt delay starts from the moment when the hardware interrupt occurs, and ends when the virtual machine receives the interrupt injected by the Hypervisor. The longest delay time under various pressure conditions is the interrupt delay. Scheduling delay refers to the start time when the high-priority virtual machine process is ready, and the end time when the high-priority virtual machine process is scheduled to run. The longest delay time under various pressure conditions of the system is the scheduling delay .
After interrupt virtualization, when an external interrupt occurs, the Hypervisor receives it and injects it into the virtual machine at the fastest speed, so that the Hypervisor takes less time to process the virtual machine interrupt. The hypervisor optimizes the switching time of the virtual machine, minimizes the time for turning off interrupts and closing the preemption on the hypervisor, and uses less kernel locks as much as possible. When a high-priority virtual machine needs to switch to run, it can switch to the high-priority virtual machine to run at the fastest speed .
3.4 Safety and reliability technology
Functional safety, information security and reliability are necessary components for the reliable and safe operation of vehicle control operating system products. Hypervisor provides the basic operating environment for the smart car domain controller, and its security and reliability are the basis and core to ensure the functional safety and reliability of the entire system. Hypervisor needs to be designed, developed and tested according to the highest standard of automotive functional safety ISO26262 ASIL-D, and its functional safety requirements are generated by the decomposition of domain controller product safety requirements.
There are multiple virtual machines running on the Hypervisor, and an exception of one virtual machine cannot be transmitted to other virtual machines. The hypervisor can obtain the current overall health status of the system. When a virtual machine is abnormal, the hypervisor should monitor the system health status in real time, effectively isolate the fault, and repair the abnormality within the minimum affected range to ensure the continuous availability of the system.
The addition of hypervisor to the automotive software stack will lead to an increase in the level of the software stack in the vertical direction and an increase in the complexity of business software in the horizontal direction. However, the safety and reliability requirements of the car are stronger than the existing cloud-side virtualization and edge virtualization. Therefore, the security of virtualization is increasing. Get the attention of the industry. These security include:
A chain of trust issue between the hypervisor and the virtual machine. Use virtualization technology to create multiple virtual machines on a trusted physical platform, and pass the chain of trust built from the hardware root of trust to each virtual machine, thereby building multiple virtual machines on a trusted physical platform Trusted Computing Platforms, some solutions lack the verification of the chain of trust between the virtual machine manager and the virtual machine;
Attacks between virtual machines: Malicious intruders can gain control of a virtual machine through another virtual machine existing on the same physical host by exploiting a vulnerability in the hypervisor, thereby destroying the target virtual machine;
Virtual machine escape: exploit the vulnerabilities of the virtual machine software or the software running in the virtual machine to attack or control the operating system of the virtual machine host.
In order to improve the security of the Hypervisor, it is important to establish corresponding security goals. The following table briefly lists the relevant requirements:
Hypervisor security capabilities can be improved from three dimensions.
(1) A security boundary needs to be established
As shown in Figure 7, this boundary is strictly defined and enforced by the hypervisor. Confidentiality, integrity, and availability of the hypervisor security perimeter need to be guaranteed. A perimeter protects against a range of attacks, including side-channel information leakage, denial of service, and privilege escalation. The hypervisor security perimeter also provides isolation of network traffic, virtual appliances, storage, compute resources, and all other virtual machine resources.
Figure 7 Security Boundary
The overall virtualization security architecture is shown in Figure 8. The confidentiality of the security boundary can be implemented through traditional cryptography methods. The integrity is guaranteed by the trusted measurement mechanism, the trusted reporting mechanism realizes the trusted interworking of different virtual environments, and the monitoring mechanism dynamically measures the behavior of entities to discover and eliminate unexpected mutual interference. The isolation mechanism provided by virtual technology separates the physical operating space.
Figure 8 Overall virtualization security architecture
Security boundary isolation is supported by Hypervisor's vCPU scheduling isolation security, memory isolation, network isolation, and storage isolation technologies, which realize the isolation between Hypervisor, virtual machines, and virtual machines on the same physical machine.
(2) Mitigation mechanisms for defense-in-depth vulnerabilities need to be established
For potential loopholes in the security boundary, Hypervisor needs to have certain technical means to actively defend, these technical means include Address Space Layout Randomization (ASLR), Data Execution Prevention (DEP), arbitrary code protection, control flow protection and data corruption protection wait.
(3) Establish a strong security assurance process
Hypervisor-related attack surfaces include virtual networks, virtual devices, and all cross-virtual machine surfaces. All virtual machine attack surfaces are recommended to implement threat modeling, code review, fuzzed testing, and trigger regular security by establishing automated builds and environments. examine.
As an important technology in cloud computing scenarios, virtualization technology has accumulated many security paradigms in more than 10 years of production practice, and these experiences can also be used for reference in automotive scenarios. However, compared with the cloud scenario, the virtualization technology of the automotive scenario also has its particularity, such as the virtual machine does not need to be dynamically migrated/created, and the hypervisor has a functional safety level requirement, etc., and its security methods need to be continuously enriched and improved in practice .
Typical application case
In the development of intelligent vehicles, virtualization is mainly used in integrated scenarios such as smart cockpits, smart driving, and smart gateways. Restricted by technology maturity, policies and regulations, intelligent driving is basically in the stage of pre-research and prototype. The business functions of the smart gateway are relatively isomorphic, and may be further integrated into other scenarios. Therefore, the current main application cases are concentrated in the smart cockpit.
The integration of the smart cockpit domain has also been launched in recent years and is undergoing iterative evolution. Affected by factors such as chip computing power, virtualization technology maturity, and the ability of the ecological chain to control virtualization solutions, some manufacturers have also adopted hard isolation solutions to achieve domain integration. Deterministic guarantee, but it lacks the flexibility of software definition, and the degree of intelligence is limited. It is an optional solution for domain fusion. In terms of embedded virtualization technology, foreign companies such as QNX, OpenSynergy, and PikeOS have first-mover advantages, especially in the automotive field for many years, so many application cases have emerged in the past two years. Driven by the development trend of intelligent localization, many chip manufacturers and independent software manufacturers have developed embedded virtualization technologies, products, and solutions in recent years, such as RAITE Hypervisor (RHOS) of ZTE and ZTE GoldenOS. , Banma Zhixing's AliOS Hypervisor, CAIC Hypervisor, etc.
4.1 Smart Cockpit Domain Controller Products
A manufacturer’s smart cockpit domain controller products, as shown in Figure 9 and Figure 10, are based on Qualcomm 8155 and Renesas R-Car H3 processors, using QNX Hypervisor, equipped with QNX Host, Android P/R/S Guest OS, configurable Output up to 6 high-definition large screens for independent display, integrating entertainment system, LCD instrument, body control, DMS, APA and other functions, supporting independent four-sound area, multi-screen interaction and audio and video sharing, high integration, in the Great Wall, Changan, Yutong It is suitable for mass production on various models such as passenger cars.
In addition, the localized solution Xinchi X9HP+ platform adopts two flexible configurations of hard partition and Hypervisor to realize low-end smart cockpit domain controller products.
Figure 9 Smart cockpit domain controller
Figure 10 Localization solution smart cockpit domain controller
4.2 RHOS Smart Cockpit Domain Controller Platform
(1) NXP I.MX8QM Cockpit Domain Controller
Based on the self-developed Type-1 virtualization software RHOS (Raite Hypervisor OS), a manufacturer has adapted and supported NXP I.MX8QM to provide a lightweight and flexible car smart cockpit virtualization solution, which has been mass-produced in Dongfeng models listed. Its system architecture is shown in Figure 11:
Figure 11 NXP I.MX8 smart cockpit system architecture
After running the Hypervisor on the SoC, it can support running multiple operating systems at the same time. For example, the Linux system can run services with high real-time and high security, such as full LCD instruments, etc., and can expand and run services such as DMS and HUD. Another virtual machine runs the Android operating system, on which services with low security and real-time requirements such as infotainment are deployed. In order to ensure that the system has good market competitiveness, the domain controller is compatible with TBOX functional requirements, and the system can support sleep wakeup and quick start.
Linux and Android virtual machines can configure resources on demand, including memory, CPU, storage space, peripherals, etc. The architecture supports system upgrades, including virtual machine and hypervisor upgrades, and supports exception logging, including virtual machine kernel and hypervisor logs.
Multi-screen interaction is an important application scenario of the smart cockpit. Android APP applications can be pushed to Linux instruments through the Hypervisor for display.
Figure 12 Virtual machine multi-screen interaction architecture
The scheme of Android and Linux instrument interaction is shown in Figure 12. The NXP I.MX8QM chip has more than two display interfaces, and each display interface can be connected to two display screens. When the Android system needs to project information to the instrument screen, the Overlay layer of the instrument display can display the projected screen content. System interaction has zero delay and zero copy, and multi-system interaction does not occupy additional CPU and GPU resources. Cross-system multi-screen interaction is realized through Hypervisor virtualization technology, which effectively improves driving safety and reduces the hardware cost of the smart cockpit.
(2) MT8675 cockpit domain controller
RHOS supports MT8675 through adaptation, forming a multi-screen intelligent cockpit domain controller solution with rich functions and high cost performance, and has obtained mass production projects of several car factories. Its overall system architecture is shown in Figure 13:
Figure 13 MT8675 smart cockpit system architecture
MT8675 only provides one GPU, and the cockpit domain needs to share GPU resources on the instrument and central control. RHOS realizes GPU virtualization sharing, and achieves industry-leading virtualization effects through performance optimization (loss