Virtual machine management method and related system and storage medium

Abstract

The embodiment of the present application provides a virtual machine management method and related systems and storage media, the method comprising: a virtual machine manager receiving a system call instruction from a virtual machine application, the system call instruction carrying a call number, wherein the system call instruction is a privileged instruction; the virtual machine manager obtains a first context save area (CSA) based on the context and idle context save area (CSA) of the virtual machine, and processes a second CSA based on the call number to obtain a processed second CSA, wherein the second CSA is determined before the first CSA, and the first CSA is adjacent to the processed second CSA; the virtual machine manager executes a jump to the system call service processing address of the virtual machine kernel based on the return address of the first CSA to trigger the virtual machine kernel to perform system call processing. Through the embodiment of the present application, the efficiency of system operation is improved, and the system performance is improved.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a virtual machine management method and related systems and storage media. Background Art

[0002] With the development of information technology and the continuous improvement of chip manufacturing processes, embedded systems have seen widespread development and application. As the foundational development platform for applications, embedded operating systems (OSs) simplify the software development process and reduce subsequent maintenance costs, thus becoming a crucial component of embedded systems. Embedded OSs are widely used in the Internet of Things, automotive electronics, industrial automation, military, and aerospace sectors, all of which have stringent requirements for real-time performance and reliability.

[0003] At the same time, with the increasing functionality and complexity of automotive electronic control systems, a mid-range sedan is now equipped with approximately 80 electronic control units (ECUs), making automotive electronic software development increasingly complex. Furthermore, ECU application software development is highly dependent on the hardware platform, leading to problems such as poor application portability and software incompatibility. In the 1990s, ECUs were primarily built on a standalone architecture, limited by hardware capabilities. Each ECU operated independently and did not communicate with each other; applications interacted directly with the hardware through drivers.

[0004] With the application and development of new technologies such as electronics, computers, and information technology, automotive electronic control applications have emerged. The automotive industry has subsequently proposed standards such as open systems and the corresponding interfaces for automotive electronics / vehicle distributed executive (OSEK / VDX) and the automotive open system architecture (AUTOSAR). These standards establish unified standards for in-vehicle embedded real-time operating systems and related services, enabling an open development platform for automotive electronics. These standards offer high modularity, portability, and reusability, simplifying the development process and reducing costs.

[0005] The OSEK / VDX specification is the earliest standard for automotive electronics basic software. Proposed by the German automotive industry in 1993, it aims to provide a unified software architecture standard for ECUs, encompassing embedded operating systems, communication stacks, and network management protocols. However, as ECU performance improves and scalability considerations increase, the limitations of the OSEK / VDX specification are no longer sufficient to meet the demands of modern, complex, integrated architectures in automotive electronics, where numerous functions are integrated into a single ECU.

[0006] OSEK / VDX fails to consider the security and reliability of automotive electronics applications. AUTOSAR, building on OSEK / VDX, has proposed a series of implementation specifications related to isolation and protection to ensure the safety and reliability of automotive electronics applications. Currently, automotive electronic control is primarily performed by electronic control units (ECUs). With the increasing capabilities of ECUs, AUTOSAR has proposed a software partitioning isolation approach for devices equipped with memory protection units (MPUs). This approach divides the device's storage area into an operating system (OS) partition and an application partition. Basic software, such as the OS kernel, storage software, peripherals, and input / output (I / O), reside in a trusted, privileged OS partition. Application software is logically divided into trusted applications and standard applications. Standard applications are assigned to an untrusted, non-privileged application partition; trusted applications, like the OS kernel, reside in a trusted, privileged OS partition. Among them, data on the data segments between ordinary applications cannot be read or written, and code cannot be executed. System services can only be accessed through privilege switching through system calls.

[0007] Most existing microcontroller units (MCUs) do not support hardware virtualization. When using instruction emulation, each instruction must be trapped into the host to confirm whether it can be processed. When accessing system services through a privileged system call, the host must first be trapped. Once the host confirms that the system call can be processed, the virtual machine kernel will process the system call. After the virtual machine kernel completes the process, it must also trap into the host to confirm the return address. Since each instruction must be trapped and emulated, system performance is significantly reduced. Summary of the Invention

[0008] The present application discloses a virtual machine management method and related system and storage medium, which can reduce the number of times the host is trapped, improve the efficiency of system operation, and improve system performance.

[0009] In a first aspect, an embodiment of the present application provides a virtual machine management method, the method comprising: a virtual machine manager receiving a system call instruction from a virtual machine application, the system call instruction carrying a call number, wherein the system call instruction is a privileged instruction; the virtual machine manager obtains a first context save area (CSA) based on the context and idle context save area (CSA) of the virtual machine, and processes a second CSA based on the call number to obtain a processed second CSA, wherein the second CSA is determined before the first CSA, the first CSA is adjacent to the processed second CSA, the return address of the first CSA is the system call service processing address of the virtual machine kernel, the return address of the processed second CSA is the next hop address of the virtual machine kernel, and the processed second CSA is used to indicate a jump to the next hop address of the virtual machine kernel after the system call is processed; the virtual machine manager executes a jump to the system call service processing address of the virtual machine kernel based on the return address of the first CSA to trigger the virtual machine kernel to perform system call processing.

[0010] According to an embodiment of the present application, a virtual machine manager receives a system call instruction from a virtual machine application and obtains a first context storage area (CSA) based on the context and free context storage area (CSA) of the virtual machine. The virtual machine manager processes a second context storage area (CSA) based on the call number to obtain a processed second CSA. The virtual machine manager then executes a jump to the system call service processing address of the virtual machine kernel based on the return address of the first CSA, triggering the virtual machine kernel to process the system call. This approach allows the virtual machine manager to execute a jump to the system call service processing address of the virtual machine kernel to perform the system call. The processed second CSA is determined before the first CSA, and the first CSA is adjacent to the processed second CSA. Thus, after the virtual machine kernel completes the system call processing, the virtual machine kernel can jump to the next hop address of the virtual machine kernel based on the processed second CSA. Compared to the prior art method of trapping into the host multiple times, this solution reduces the number of traps, improves system operation efficiency, and enhances system performance.

[0011] As an optional implementation, the virtual machine manager obtains a first CSA based on the context of the virtual machine and an idle context save area CSA, including: the virtual machine manager stores the context of the virtual machine in the idle CSA to obtain the CSA of the context of the virtual machine; the virtual machine manager modifies the mode of the CSA of the context to kernel mode, modifies the memory protection domain of the CSA of the context to the memory boundary of the virtual machine, modifies the stack address of the CSA of the context to the stack address of the virtual machine, modifies the return address of the CSA of the context to the system call service processing address of the virtual machine kernel, and modifies the context bit of the CSA of the context to obtain the first CSA.

[0012] By adopting this method, a new CSA is constructed, so that the virtual machine manager can execute a jump to the system call service processing address of the virtual machine kernel to perform a system call.

[0013] As an optional implementation, the virtual machine manager copies the call number to the second CSA and updates the return address of the second CSA to the address of the next hop of the virtual machine kernel to obtain the processed second CSA.

[0014] This approach allows the virtual machine kernel to jump to the next hop address of the virtual machine kernel based on the processed second CSA after the virtual machine kernel completes the system call processing. Compared to the existing technology that requires multiple traps to the host, this solution reduces the number of traps, improves system operation efficiency, and enhances system performance.

[0015] As an optional implementation manner, the next hop address of the virtual machine kernel is the next instruction address of the virtual machine application.

[0016] As another optional implementation, the next hop address of the virtual machine kernel is the result check address of the virtual machine manager.

[0017] As an optional implementation, the method further includes: the virtual machine manager obtaining the processing result of the virtual machine kernel and verifying the processing result; when the processing result is verified, the virtual machine manager jumps to the virtual machine application.

[0018] By adopting this method, the processing result is checked, and the process jumps to the virtual machine application only after passing the verification, thereby ensuring the legitimacy of the processing result and improving the security of the system call.

[0019] As an optional implementation, the system call instruction also carries the address of the virtual machine application. Before the virtual machine manager executes a jump to the virtual machine kernel according to the return address of the first CSA, the method also includes: the virtual machine manager compares the address of the virtual machine application with a preset legal address to confirm whether the address of the virtual machine application is legal.

[0020] By adopting this method, the present solution verifies the legitimacy of the call initiator, thereby improving the security of the system call.

[0021] In a second aspect, an embodiment of the present application provides a virtual machine management method, the method comprising: a virtual machine manager receives a system call instruction from a virtual machine application, the system call instruction carries a call number, wherein the system call instruction is a privileged instruction; the virtual machine manager obtains a processed first context save area (CSA) based on the call number and a first context save area (CSA), the return address of the processed first CSA being the next instruction address of the virtual machine application; the virtual machine manager performs system call processing based on the call number, and after the system call processing is completed, executes a jump to the next instruction address of the virtual machine application based on the return address of the processed first CSA.

[0022] Through the embodiment of the present application, the virtual machine manager receives a system call instruction from a virtual machine application and obtains a processed first context save area (CSA) based on the call number and the first context save area (CSA). The return address of the processed first CSA is the next instruction address of the virtual machine application. The virtual machine manager then performs system call processing based on the call number, and after the system call processing is completed, it jumps to the next instruction address of the virtual machine application based on the return address of the processed first CSA. By adopting this approach, the present solution adds same-layer HVC call processing, which can be used to process custom HVC requests. In other words, the virtual machine manager performs system call processing and, after the system call processing is completed, jumps to the next instruction address of the virtual machine application. By adopting this approach, the efficiency of system operation is improved and system performance is enhanced.

[0023] As an optional implementation method, the virtual machine manager obtains a processed first CSA based on the call number and the first context saving area CSA, including: the virtual machine manager copies the call number to the first context saving area CSA, and updates the return address of the first CSA to the next instruction address of the virtual machine application to obtain the processed first CSA.

[0024] As an optional implementation, the system call instruction also carries the address of the virtual machine application. The virtual machine manager processes the system call according to the call number, and after the system call is processed, before executing a jump to the next instruction address of the virtual machine application according to the return address of the processed first CSA, the method further includes: the virtual machine manager compares the address of the virtual machine application with a preset legal address to confirm whether the address of the virtual machine application is legal.

[0025] By adopting this method, the present solution verifies the legitimacy of the call initiator, thereby improving the security of the system call.

[0026] In a third aspect, an embodiment of the present application provides a virtual machine management method, the method comprising: when a virtual machine manager receives an interrupt instruction from an external device of the virtual machine, obtaining an interrupt suspension bit corresponding to the interrupt instruction; the virtual machine manager determines a target virtual machine based on the interrupt suspension bit, wherein the kernel of the target virtual machine is the kernel to which the interrupt suspension bit belongs; the virtual machine manager obtains a first context save area (CSA) based on the context and idle context save area (CSA) of the target virtual machine, and processes a second CSA to obtain a processed second CSA, wherein the second CSA is determined before the first CSA, the first CSA is adjacent to the processed second CSA, the return address of the first CSA is the interrupt processing address of the kernel of the target virtual machine, the return address of the processed second CSA is the current instruction address of the application of the target virtual machine, and the processed second CSA is used to indicate a jump to the current instruction address of the application of the target virtual machine after the interrupt is handled; the virtual machine manager executes a jump to the interrupt processing address of the kernel of the target virtual machine based on the return address of the first CSA to trigger the kernel of the target virtual machine to perform interrupt processing.

[0027] According to an embodiment of the present application, after receiving an interrupt instruction from an external device, if the interrupt pending bit belongs to the target virtual machine kernel, the virtual machine manager obtains a first context save area (CSA) based on the context and idle context save area (CSA) of the target virtual machine, processes the second CSA, and obtains a processed second CSA. The virtual machine manager then executes a jump to the target virtual machine kernel based on the return address of the first CSA so that the target virtual machine kernel can handle the interrupt. Based on the processed second CSA, the virtual machine kernel can jump to the next hop address of the virtual machine kernel. Compared with the prior art that requires multiple traps to the host, this solution reduces the number of traps, improves the efficiency of system operation, and improves system performance.

[0028] This solution distributes system call processing kernels by constructing new contexts in real time, achieving partition isolation between virtual machines and reducing the trusted base. Using this solution, interrupt virtualization can be achieved.

[0029] As an optional implementation, the virtual machine manager obtains a first CSA based on the context of the target virtual machine and an idle context save area CSA, including: the virtual machine manager stores the context of the target virtual machine in the idle CSA to obtain the CSA of the context of the target virtual machine; the virtual machine manager modifies the mode of the CSA of the context to kernel mode, modifies the memory protection domain of the CSA of the context to the memory boundary of the target virtual machine, modifies the stack address of the CSA of the context to the stack address of the target virtual machine, modifies the return address of the CSA of the context to the interrupt handling address of the kernel of the target virtual machine, and modifies the context bit of the CSA of the context to obtain the first CSA.

[0030] As an optional implementation manner, the virtual machine manager updates the return address of the second CSA to the current instruction address of the application of the target virtual machine to obtain the processed second CSA.

[0031] In a fourth aspect, an embodiment of the present application provides a virtual machine management device, comprising: a receiving module for receiving a system call instruction from a virtual machine application, the system call instruction carrying a call number, wherein the system call instruction is a privileged instruction; a determination module for obtaining a first CSA based on the context and idle context save area CSA of the virtual machine, and processing a second CSA based on the call number to obtain a processed second CSA, wherein the second CSA is determined before the first CSA, the first CSA is adjacent to the processed second CSA, the return address of the first CSA is the system call service processing address of the virtual machine kernel, the return address of the processed second CSA is the address of the next hop of the virtual machine kernel, and the processed second CSA is used to indicate a jump to the next hop address of the virtual machine kernel after the system call is processed; a processing module for executing a jump to the system call service processing address of the virtual machine kernel based on the return address of the first CSA to trigger the virtual machine kernel to perform system call processing.

[0032] According to an embodiment of the present application, a virtual machine manager receives a system call instruction from a virtual machine application and obtains a first context storage area (CSA) based on the context and free context storage area (CSA) of the virtual machine. The virtual machine manager processes a second context storage area (CSA) based on the call number to obtain a processed second CSA. The virtual machine manager then executes a jump to the system call service processing address of the virtual machine kernel based on the return address of the first CSA, triggering the virtual machine kernel to process the system call. This approach allows the virtual machine manager to execute a jump to the system call service processing address of the virtual machine kernel to perform the system call. The processed second CSA is determined before the first CSA, and the first CSA is adjacent to the processed second CSA. Thus, after the virtual machine kernel completes the system call processing, the virtual machine kernel can jump to the next hop address of the virtual machine kernel based on the processed second CSA. Compared to the prior art method of trapping into the host multiple times, this solution reduces the number of traps, improves system operation efficiency, and enhances system performance.

[0033] As an optional implementation method, the determination module is used to: store the context of the virtual machine in the idle CSA to obtain the CSA of the context of the virtual machine; modify the mode of the CSA of the context to kernel mode, modify the memory protection domain of the CSA of the context to the memory boundary of the virtual machine, modify the stack address of the CSA of the context to the stack address of the virtual machine, modify the return address of the CSA of the context to the system call service processing address of the virtual machine kernel, and modify the context bit of the CSA of the context to obtain the first CSA.

[0034] As an optional implementation, the determination module is further used to: copy the call number to the second CSA, and update the return address of the second CSA to the address of the next hop of the virtual machine kernel to obtain the processed second CSA.

[0035] As an optional implementation manner, the next hop address of the virtual machine kernel is the next instruction address of the virtual machine application.

[0036] As another optional implementation manner, the next hop address of the virtual machine kernel is the result check address of the device.

[0037] As an optional implementation, the device further includes a first verification module, which is used to: obtain the processing result of the virtual machine kernel and verify the processing result; when the processing result is verified, jump to the virtual machine application.

[0038] As an optional implementation, the system call instruction also carries the address of the virtual machine application, and the device also includes a second verification module for comparing the address of the virtual machine application with a preset legal address to confirm whether the address of the virtual machine application is legal.

[0039] In a fifth aspect, an embodiment of the present application provides a virtual machine management device, comprising: a receiving module for receiving a system call instruction from a virtual machine application, the system call instruction carrying a call number, wherein the system call instruction is a privileged instruction; a determination module for obtaining a processed first context save area (CSA) based on the call number and a first context save area (CSA), the return address of the processed first CSA being the next instruction address of the virtual machine application; a processing module for performing system call processing based on the call number, and executing a jump to the next instruction address of the virtual machine application based on the return address of the processed first CSA after the system call processing is completed.

[0040] Through the embodiment of the present application, the virtual machine manager receives a system call instruction from a virtual machine application and obtains a processed first context save area (CSA) based on the call number and the first context save area (CSA). The return address of the processed first CSA is the next instruction address of the virtual machine application. The virtual machine manager then performs system call processing based on the call number, and after the system call processing is completed, it jumps to the next instruction address of the virtual machine application based on the return address of the processed first CSA. By adopting this approach, the present solution adds same-layer HVC call processing, which can be used to process custom HVC requests. In other words, the virtual machine manager performs system call processing and, after the system call processing is completed, jumps to the next instruction address of the virtual machine application. By adopting this approach, the efficiency of system operation is improved and system performance is enhanced.

[0041] As an optional implementation, the determination module is used to: copy the call number to the first context save area CSA, and update the return address of the first CSA to the next instruction address of the virtual machine application to obtain the processed first CSA.

[0042] As an optional implementation, the system call instruction also carries the address of the virtual machine application, and the device further includes a verification module for comparing the address of the virtual machine application with a preset legal address to confirm whether the address of the virtual machine application is legal.

[0043] In a sixth aspect, an embodiment of the present application provides a virtual machine management device, comprising: an acquisition module for acquiring an interrupt suspension bit corresponding to an interrupt instruction when receiving an interrupt instruction from an external device of the virtual machine; a first determination module for determining a target virtual machine based on the interrupt suspension bit, wherein the kernel of the target virtual machine is the kernel to which the interrupt suspension bit belongs; a second determination module for obtaining a first context save area (CSA) based on the context and idle context save area (CSA) of the target virtual machine, and processing a second CSA to obtain a processed second CSA, wherein the second CSA is determined before the first CSA, the first CSA is adjacent to the processed second CSA, the return address of the first CSA is the interrupt processing address of the kernel of the target virtual machine, the return address of the processed second CSA is the current instruction address of the application of the target virtual machine, and the processed second CSA is used to indicate a jump to the current instruction address of the application of the target virtual machine after the interrupt is processed; a processing module for executing a jump to the interrupt processing address of the kernel of the target virtual machine based on the return address of the first CSA to trigger the kernel of the target virtual machine to perform interrupt processing.

[0044] According to an embodiment of the present application, after receiving an interrupt instruction from an external device, if the interrupt pending bit belongs to the target virtual machine kernel, the virtual machine manager obtains a first context save area (CSA) based on the context and idle context save area (CSA) of the target virtual machine, processes the second CSA, and obtains a processed second CSA. The virtual machine manager then executes a jump to the target virtual machine kernel based on the return address of the first CSA so that the target virtual machine kernel can handle the interrupt. Based on the processed second CSA, the virtual machine kernel can jump to the next hop address of the virtual machine kernel. Compared with the prior art that requires multiple traps to the host, this solution reduces the number of traps, improves the efficiency of system operation, and improves system performance.

[0045] This solution distributes system call processing kernels by constructing new contexts in real time, achieving partition isolation between virtual machines and reducing the trusted base. Using this solution, interrupt virtualization can be achieved.

[0046] As an optional implementation method, the second determination module is used to: store the context of the target virtual machine in the idle CSA to obtain the CSA of the context of the target virtual machine; modify the mode of the CSA of the context to kernel mode, modify the memory protection domain of the CSA of the context to the memory boundary of the target virtual machine, modify the stack address of the CSA of the context to the stack address of the target virtual machine, modify the return address of the CSA of the context to the interrupt handling address of the kernel of the target virtual machine, and modify the context bit of the CSA of the context to obtain the first CSA.

[0047] As an optional implementation manner, the second determining module is further configured to: update the return address of the second CSA to the current instruction address of the application of the target virtual machine to obtain the processed second CSA.

[0048] In the seventh aspect, an embodiment of the present application provides a virtual machine management device, comprising a processor and a memory; wherein the memory is used to store program code, and the processor is used to call the program code to execute the method provided by any possible implementation method of the first aspect and / or any possible implementation method of the second aspect and / or the method provided by any possible implementation method of the third aspect.

[0049] In an eighth aspect, the present application provides a computer storage medium comprising computer instructions, which, when the computer instructions are run on an electronic device, enable the electronic device to execute the method provided in any possible implementation of the first aspect and / or any possible implementation of the second aspect and / or any possible implementation of the third aspect.

[0050] In the ninth aspect, an embodiment of the present application provides a computer program product, which, when running on a computer, enables the computer to execute the method provided by any possible implementation of the first aspect and / or any possible implementation of the second aspect and / or any possible implementation of the third aspect.

[0051] It is understandable that the apparatus described in the fourth aspect, the apparatus described in the fifth aspect, the apparatus described in the sixth aspect, the apparatus described in the seventh aspect, the computer storage medium described in the eighth aspect, or the computer program product described in the ninth aspect are all used to execute any of the methods provided in the first aspect, any of the methods provided in the second aspect, and any of the methods provided in the third aspect. Therefore, the beneficial effects that can be achieved can refer to the beneficial effects of the corresponding methods and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0052] The following is an introduction to the drawings used in the embodiments of this application.

[0053] Figure 1a A schematic diagram of the architecture of a computer system applicable to embodiments of the present application;

[0054] Figure 1b This is a schematic diagram of the software architecture in the existing AUTOSAR OS;

[0055] Figure 1c This is a schematic diagram of a vehicle architecture provided by an embodiment of the present application;

[0056] Figure 1d This is a schematic diagram of a virtual machine management system architecture provided by an embodiment of the present application;

[0057] Figure 1e This is a schematic diagram of the processing logic of a CSA provided in an embodiment of the present application;

[0058] Figure 1f is a schematic diagram of a virtual machine architecture provided in an embodiment of the present application;

[0059] Figure 2a This is a flow chart of a virtual machine management method provided in an embodiment of the present application;

[0060] Figure 2b is a schematic diagram of a method for determining execution environment parameters provided by an embodiment of the present application;

[0061] Figure 2c is a schematic diagram of a virtual machine management method provided in an embodiment of the present application;

[0062] Figure 3a This is a flowchart of another virtual machine management method provided by an embodiment of the present application;

[0063] Figure 3b is a schematic diagram of another virtual machine management method provided in an embodiment of the present application;

[0064] Figure 4a is a schematic diagram of another virtual machine management method provided in an embodiment of the present application;

[0065] Figure 4b is a schematic diagram of another virtual machine management method provided in an embodiment of the present application;

[0066] Figure 5a This is a flowchart of another virtual machine management method provided in an embodiment of the present application;

[0067] Figure 5b This is a flowchart of another virtual machine management method provided in an embodiment of the present application;

[0068] Figure 6aThis is a structural diagram of a virtual machine management device provided in an embodiment of the present application;

[0069] Figure 6b This is a structural diagram of another virtual machine management device provided in an embodiment of the present application;

[0070] Figure 6c This is a structural diagram of another virtual machine management device provided in an embodiment of the present application;

[0071] Figure 7 This is a structural diagram of a virtual machine management device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0072] The following describes the embodiments of the present application in conjunction with the accompanying drawings. The terms used in the implementation methods of the embodiments of the present application are only used to explain the specific embodiments of the present application and are not intended to limit the present application.

[0073] The embodiments of the present application provide a virtual machine management method that can be applied to a computer system that adopts the automotive open system architecture (AUTOSAR) standard. The computer system can be deployed on a vehicle, or it can be deployed at a location remote from the vehicle and wirelessly communicate with the vehicle, such as being deployed on a server that is communicatively connected to the vehicle. The computer system deployed on a vehicle can be referred to as an on-board device. The vehicle can specifically be a car, truck, motorcycle, bus, ship, airplane, helicopter, lawn mower, recreational vehicle, amusement park vehicle, construction equipment, tram, golf cart, train, and cart, etc., and the embodiments of this solution do not make any special restrictions.

[0074] Figure 1a This is a schematic diagram of the architecture of a computer system applicable to the embodiments of the present application, such as Figure 1aAs shown, computer system 100 includes a processor 101 coupled to a system bus 102. Processor 101 can be one or more processors, each of which can include one or more processor cores. A display adapter (video adapter) 103 can drive a display 104, which is coupled to system bus 102. System bus 102 is coupled to an input / output (I / O) bus via a bus bridge 105. An I / O interface 106 is coupled to the I / O bus. I / O interface 106 communicates with various I / O devices, such as input device 107 (e.g., keyboard, mouse, touch screen, etc.), media tray 108 (e.g., CD-ROM, multimedia interface, etc.), transceiver 109 (capable of sending and / or receiving radio communication signals), camera 110 (capable of capturing still and moving digital video images), and external USB interface 111. Optionally, the interface connected to I / O interface 106 can be a USB interface.

[0075] Processor 101 may be any conventional processor, including a reduced instruction set computing (RISC) processor, a complex instruction set computing (CISC) processor, or a combination thereof. Alternatively, the processor may be a dedicated device such as an application-specific integrated circuit (ASIC). Alternatively, processor 101 may be a neural network processor or a combination of a neural network processor and the aforementioned conventional processors.

[0076] Alternatively, in various embodiments described herein, the computer system 100 may be located remotely from the autonomous vehicle and may be in wireless communication with the autonomous vehicle. In other aspects, some of the processes described herein are executed on a processor located within the autonomous vehicle, while others are executed by a remote processor, including taking actions required to execute a single maneuver.

[0077] Computer system 100 can communicate with software deployment server 113 via network interface 112. Network interface 112 is a hardware network interface, such as a network card. Network 114 can be an external network, such as the Internet, or an internal network, such as Ethernet or a virtual private network (VPN). Alternatively, network 114 can be a wireless network, such as a WiFi network or a cellular network.

[0078] The hard disk drive interface 115 is coupled to the system bus 102. The hard disk drive interface 115 is connected to a hard disk drive 116. The system memory 117 is coupled to the system bus 102. The data running in the system memory 117 may include the operating system OS 118 of the computer system 100 and application programs 122.

[0079] Operating system 118 includes a shell 120 and a kernel 121. Shell 120 serves as an interface between the user and the operating system's kernel. The shell is the outermost layer of the operating system. It manages the interaction between the user and the operating system: it waits for user input, interprets user input to the operating system, and processes various operating system output.

[0080] The kernel 121 is composed of those parts of the operating system that are used to manage memory, files, peripherals, and system resources. It directly interacts with the hardware. The operating system kernel usually runs processes and provides communication between processes, CPU time slice management, interrupts, memory management, I / O management, etc.

[0081] Applications 122 include programs 123 related to controlling the autonomous driving of the vehicle. For example, these programs manage the interaction between the autonomous vehicle and obstacles on the road, control the route or speed of the autonomous vehicle, and control the interaction between the autonomous vehicle and other autonomous vehicles on the road. Applications 122 also reside on a system hosted by a software deployment server 113. In one embodiment, when application 122 is needed, computer system 100 can download application 122 from software deployment server 113.

[0082] The application 122 may also include other programs, which are not specifically limited in this solution.

[0083] Sensor 124 is associated with computer system 100. Sensor 124 is used to detect the environment surrounding computer system 100. For example, sensor 124 can detect animals, cars, obstacles, and crosswalks. Furthermore, sensor 124 can detect the environment surrounding these objects, such as animals, cars, obstacles, and crosswalks, for example, the environment surrounding the animals, such as other animals around the animals, weather conditions, and ambient light levels. Alternatively, if computer system 100 is located in a self-driving car, the sensor can be a camera, an infrared sensor, a chemical detector, a microphone, and the like.

[0084] The MPU is a hardware resource commonly used for memory protection in embedded systems. Embedded systems use multi-tasking operations and control. The system must provide a mechanism to ensure that the running task does not disrupt the operations of other tasks, that is, to prevent system resources and other tasks from being illegally accessed.

[0085] The MPU manages the memory address space using regions or protected regions. A region is an attribute associated with the memory address space. The MPU typically has eight regions, numbered 0-7. The region size and starting address are stored in register c6 of the coprocessor CP15. The region size can be any power of two from 4KB to 4GB, and the region's starting address must be a multiple of its size.

[0086] The operating system can configure access permissions for the MPU domain. The operating system can set the domain access permissions to read, read-only, or inaccessible based on the current operating mode of the processor.

[0087] When the processor accesses a memory domain, the MPU compares the domain's access permission attributes with the processor's current operating mode. If the processor's access request meets the domain's access permission, the MPU allows the kernel to read and write memory. If the processor's access request does not meet the domain's access permission, an exception signal is generated.

[0088] In embedded systems, a memory management unit (MMU) can provide a more powerful memory protection mechanism than an MPU. An MPU usually only provides memory protection, while an MMU can also provide functions such as mapping virtual addresses to physical addresses on the basis of providing memory protection.

[0089] Most machines that use an MMU use a paging mechanism. The operating system can set the access rights of each page table in the page table. Some page tables cannot be accessed, some can only be accessed in privileged mode, and some can be accessed in both user mode and privileged mode. At the same time, the access rights are divided into three types: readable, writable, and executable. After this setting, when the processor wants to access a virtual address (VA), the MMU will check whether the processor is currently in user mode or privileged mode, and whether the purpose of accessing memory is to read data, write data, or fetch instructions for execution: if it matches the permissions set by the operating system, access is allowed and the VA is converted into a physical address (PA); otherwise, execution is not allowed and an exception is generated.

[0090] The processing mechanism of exceptions is similar to that of interrupts. The difference is that interrupts are generated by external devices (such as hardware errors, input errors), while exceptions are generated inside the processor. Interrupts are not related to the instructions currently executed by the processor, while exceptions are caused by problems with the currently executed instructions.

[0091] Under normal circumstances, the processor executes user programs in user mode. In the event of an interrupt or exception, the processor switches to privileged mode to execute kernel programs. After handling the interrupt or exception, the processor returns to user mode to continue executing the user program. Typically, the operating system divides the virtual address space into user space and kernel space. For example, the virtual address space of the Linux system on the x86 platform ranges from 0x0000 0000 to 0xffff ffff, with the first 3GB of space allocated to user space and the last 1GB to kernel space. User programs are loaded into user space, while kernel programs are loaded into kernel space. User programs cannot access kernel data or jump into kernel space for execution. This protects the kernel. If a process accesses an illegal address, it may crash, but it will not affect the stability of the kernel or the system. When an interrupt or exception occurs, the system not only jumps to the interrupt service routine or exception service routine, but also switches from user mode to privileged mode, and jumps from the interrupt service routine or exception service routine to kernel code for execution.

[0092] Figure 1b In the illustrated architecture, standard applications run in the non-privileged layer. When standard applications handle tasks, system service requests, and I / O access, they must switch privileges from non-privileged mode to privileged mode, which takes a long time. For example, when standard applications request services from the kernel that require higher privileges, such as privileged I / O access or inter-process communication, they cannot directly access system services and must instead perform a privilege switch through system calls.

[0093] Processor instructions are divided into normal instructions and privileged instructions. Privileged instructions can only be executed by the kernel, while user mode can only run normal instructions. Computer system I / O access includes privileged I / O access and normal I / O access. Privileged I / O refers to I / O that only the kernel can access, while normal I / O is accessible only to applications. When a task in an application requires privileged I / O access, it must make a system call to access the privileged I / O.

[0094] Specifically, when a user task in a normal application initiates a system service request to the system call handler (syscallhandler), the following behaviors will occur: the processor will generate a synchronous exception (Trap), refresh the pipeline (pipeline), save the CPU registers of the user task, read the exception vector table, and switch the MPU protection domain.

[0095] Tasks are the fundamental unit of operating system operation, and managing task objects is a crucial aspect of any operating system design. Task context refers to the processor's general-purpose registers and special-function registers used by tasks during execution. These registers represent the processor's operating state. As different tasks take turns occupying the processor, they modify the corresponding registers based on the stored values ​​of the tasks, a process known as task context switching. Operating systems frequently perform task context switching operations during operation. Each time the operating system enters a scheduling point, a task context switch may occur, allowing more important tasks to occupy processor resources. Therefore, the speed of task switching significantly impacts the operating system's real-time responsiveness.

[0096] Each system call requires a context switch from the user task to the kernel. Next, the syscall handler calls the system service's application programming interface (API). After completing the user task, it also needs to go through a context switch from the kernel to the user task. The above context switch from the user task to the kernel or from the kernel to the user task is a privilege switch.

[0097] During a system call, two context switches (or two privilege switches) are required, with each context switch incurring clock overhead of over 300 instruction cycles. Although memory allocation, I / O access, and mutually exclusive resources are common tasks, these resources and I / O operations are privileged and therefore require system calls to access. Memory allocation and I / O access occur frequently in the system, resulting in excessive privilege switch overhead for common applications. This high privilege switch overhead can lead to delayed application responses, which can cause error transmission or task scheduling anomalies.

[0098] Among vehicle-mounted equipment, autonomous emergency braking (AEB) is an active safety technology that uses radar, cameras, and other devices to detect the road ahead and initiate emergency braking when the distance is less than the safe distance. Therefore, AEB has extremely high requirements for real-time performance and system response.

[0099] in addition, Figure 1aIn the partition architecture shown, trusted applications and the kernel form a trusted base. However, if the number of trusted applications increases, the trusted base becomes too large, posing a security risk. This is because if a trusted task or kernel vulnerability is exploited, user and kernel data could be completely exposed, posing a security risk.

[0100] The Trusted Computing Base (TCB), also known as the Trusted Base, is the collection of all security mechanisms used to protect computer systems. These mechanisms can take the form of hardware, firmware, and software. A program error or security vulnerability in any component of the TCB can compromise the security of the entire system. Conversely, problems with components outside the TCB only compromise the permissions granted to them by the system's security policy. These permissions are generally low, so reducing the TCB is crucial to overall system security.

[0101] Security threats facing automotive electronic systems include remote intrusion and physical attacks. For in-car entertainment systems with security vulnerabilities, exploitation would only result in the disclosure of user privacy and would not endanger personal safety. However, for steering assistance systems, security vulnerabilities could pose a personal safety risk if compromised and remotely controlled. Therefore, real-time performance and security are crucial for in-vehicle devices.

[0102] like Figure 1c FIG2 is a schematic diagram of a vehicle architecture provided by an embodiment of the present application. In particular, this solution can realize the migration and operation of the headlight management system and the electric window management system on the traditional ECU to the ECU used by VDC without modification.

[0103] For example, the VDC ECU uses the TC397 chip, which supports the Tricore architecture and is a 6-core MCU; the traditional ECU uses the TC297 chip, which supports the Tricore architecture but is a 3-core MCU.

[0104] Both the headlight system and the power window system are based on the AutoSAR standard. The operating system for the headlight system uses the Erika system, while the operating system for the power window system uses the Microsar system. Both systems support the Tricore system architecture. Partition management is deployed at the privileged layer, and both systems are deployed at the user layer.

[0105] This schematic diagram is only an example and may also be in other forms, which is not specifically limited in this solution.

[0106] Based on this, the embodiment of the present application provides a new system architecture. Figure 1d A schematic diagram of the new system architecture applicable to this application, such as Figure 1d As shown, in the new system architecture, virtual machines are divided into the user layer, and the virtual machine manager is in the privileged layer.

[0107] Specifically, the system includes Tricore, a virtual machine manager, and a virtual machine. The virtual machine is bound to one or more cores. The core resources of the host CPU are not less than the requirements of the virtual machine. Figure 1f As shown, the virtual machine (client operating system OS) includes a virtual machine application (user program) and a virtual machine kernel (operating system kernel). In the virtual machine management system of this solution, the entire virtual machine is placed in user mode, and only the virtual machine manager runs in kernel mode.

[0108] Because the client's operating system kernel is deployed from kernel state to user state, exceptions occur when accessing privileged instructions and I / O, trapping the client in kernel state for processing by the virtual machine manager. Similarly, when a client's user-state program accesses a system call, it first traps the client in kernel state for processing by the virtual machine manager. Similarly, external interrupts also first pass through the virtual machine manager before being distributed to the operating system kernel of the corresponding virtual machine for processing. To this end, this application provides a virtual machine management method for system call processing and interrupt handling.

[0109] In the embodiment of the present application, system calls and interrupt processing are virtualized with the assistance of CSA. The purpose is to enable a single-core system to be smoothly migrated to multi-core hardware. At the same time, when a single-core system is compromised, it will not affect other single-core systems on the multi-core hardware, achieving data isolation, and being able to isolate system calls and interrupts, perform pre- and post-control flow checks, and ensure system security. Compared with hardware virtualization, this solution does not require hardware support. Compared with pure virtualization simulation, it avoids the complete use of instruction simulation. This solution improves system performance by optimizing system calls and interrupt processing.

[0110] First, the relevant terms in the embodiments of this application are introduced:

[0111] 1. Tricore: A 32-bit single-core MCU architecture with its own instruction set, mostly used in real-time scenarios.

[0112] 2. CSA: Context Save Areas. Each CSA stores one context or one context. The Tricore architecture uses a linked list of fixed-size Context Save Areas (CSAs). CSAs consist of 16 words of memory, aligned on 16-word boundaries. Each CSA can store exactly one context or one context.

[0113] CSAs are linked together using a link word. The link word consists of two fields that link a given CSA to the next CSA in the chain. These fields are a 4-bit segment and a 16-bit offset. The segment number and offset are used to generate the effective address (EA) of the linked CSA.

[0114] Increasing the pointer offset value by 1 always increases the EA to an address 16 word locations higher than the previous address. The total available range in each address segment of the CSA is 4MB, providing storage space for 216 CSAs.

[0115] This architecture saves and restores context faster than traditional microprocessors. A unique memory subsystem design with wide data paths allows the architecture to perform fast data transfers between processor registers and on-chip memory. A context switch occurs when an event or instruction causes program execution to be interrupted. The CPU then needs to process this event before continuing the program. Events and instructions that cause program execution to be interrupted include:

[0116] Interruption or service request

[0117] ·trap

[0118] Function call

[0119] Among them, the Tricore architecture uses a memory structure (context save area CSA) to save the context of general registers and system registers, which is similar to ARM's register bank, but these CSA spaces can be configured, and CSA primitives such as load, save, restore, and store can be explicitly executed.

[0120] The upper context (Upper Context) and lower context (Lower Context) store data registers and address registers, respectively. The upper context also stores system registers such as the stack pointer (SP) and the program status word (PSW), while the lower context stores general-purpose registers. The former is automatically saved by the hardware during function calls, exceptions, and interrupts; the latter requires explicit calls to pass parameters.

[0121] For example, Figure 1eAs shown, the Free Context List (FCX) contains three CSAs (3, 4, and 5), and the Previous Context List (PCX) contains two CSAs (2 and 1). FCX points to CSA3, the first available CSA. CSA3's link word points to CSA4; CSA4's link word points to CSA5. PCX points to the most recently saved CSA in the previous context list. CSA2's link word points to CSA1. CSA1 contains the context previously saved by CSA2. When a context save operation is performed, the first CSA in the Free Context List (CSA3) is pulled out and placed in front of the previous context list.

[0122] Before a context is saved to the first available CSA, its link word is read, providing a new value for FCX, which links to the next available CSA. For the memory subsystem, a context save is a read / modify / write operation. The new value of FCX points to the next available CSA and is immediately available for subsequent context saves.

[0123] The LCX register points to one of the last CSAs in the free list and is used to identify an impending free CSA list exhaustion event. If the value of FCX is equal to the value of LCX when an attempt is made to execute a context-saved operation, a free CSA list exhaustion exception (FCD) is triggered on the next instruction.

[0124] After executing the context save operation, the return address A

[11] (RA) will be updated:

[0125] For a call, A

[11] (RA) will be updated with the function return address.

[0126] For synchronous exceptions, A

[11] (RA) will be updated with the PC of the instruction that caused the exception.

[0127] For SYSCALL and asynchronous exceptions or interrupts, A

[11] (RA) will be updated with the PC of the next instruction to be executed.

[0128] When a system call, external interrupt, exception, or function call occurs, the upper part will be automatically saved, while the lower part will need to be explicitly saved. As shown in Table 1 below:

[0129] Table 1

[0130]

[0131]

[0132] The main difference between context and context lies in the different registers used. Context registers are typically similar to general-purpose registers, preserving the global register values ​​before an interrupt, exception, or function call. After returning from an interrupt or other event, global registers retain their current state and are not automatically restored to the context after a RET or RFE instruction. When an exception occurs, the exception handler must save the original values ​​and restore them upon return.

[0133] Context-switching is the process of storing and restoring the CPU state so that thread execution can resume from the point where it was interrupted.

[0134] The CPU uses a time-slice allocation algorithm to execute tasks in a loop. After the current task executes a time slice, it switches to the next task. However, before switching, the state of the previous task is saved so that the next time you switch back to the current task, the state of the previous task can be loaded again. The process from saving the task to loading it again is called a context switch.

[0135] Similar to the ARM architecture, the user state enters the exception handling function through the syscall instruction, at which time the user context is automatically backed up. After entering the system call dispatch function, the kernel context is created. After processing is completed, the kernel context is recovered through the exception return instruction (RFE), the user context is restored, and the next instruction of the client application is returned.

[0136] 3. Virtualization technology is a resource management (optimization) technology that abstracts and transforms various physical resources of a computer (such as CPU, memory, disk space, network adapters and other I / O devices), and then presents a configuration environment that can be divided and arbitrarily combined into one or more (virtual) logical computers.

[0137] Among them, multiple logical computers can run simultaneously on one computer, each logical computer can run a different operating system (Guest OS), and applications can run in independent spaces without affecting each other, thereby significantly improving the computer's work efficiency.

[0138] GuestOS: the operating system (OS) in a VM (virtual machine); HostOS: the operating system (OS) in a physical machine;

[0139] Virtual Address (VA): The linear address space provided by the Guest OS to its applications.

[0140] Physical Address (PA): A pseudo physical address seen by a virtual machine, abstracted by the virtual machine monitor.

[0141] Machine Address (MA): The real machine address, that is, the address signal appearing on the address bus.

[0142] Exception Level (EL):

[0143] Different types of software typically have different levels of access to resources such as the processor and memory. For example, the operating system kernel has higher access rights to system resources, while user programs typically have only limited system configuration rights.

[0144] Tricore divides access to system resources into different levels of privilege. Privilege levels change only when the processor encounters or returns from an exception. Therefore, privilege levels are also called exception levels. They are divided into User-0 mode, User-1 mode, and Supervisor mode. User-0 mode prevents access to peripherals and cannot enable or disable interrupts. User-1 mode allows application tasks to directly access non-critical system peripherals. Privileged mode allows access to all peripherals and reads and writes to system registers and privileged peripherals.

[0145] 4. Privileged instructions: These instructions have privileged permissions and can only be used by the operating system kernel. Because these instructions have the highest permissions, improper use can cause the entire system to crash. Examples include clearing memory, resetting the clock, allocating system resources, modifying virtual memory segment and page tables, and changing user access permissions.

[0146] To ensure system security, these instructions are only available to the operating system or other system software and are not directly available to users. Therefore, privileged execution must be performed in kernel state. In fact, the CPU can execute the entire instruction set in kernel state.

[0147] Non-privileged instructions: instructions that can be used by all programs.

[0148] To prevent user programs from using privileged instructions, only non-privileged instructions are available in user mode, while all instructions are available in kernel mode. When a privileged instruction is used in user mode, an interrupt is generated, preventing the user from using the privileged instruction. Therefore, user programs are run in user mode, while the operating system's essential privileged instructions are run in kernel mode, ensuring the security and reliability of the computer system. The only way to transition from user mode to kernel mode is through an interrupt or exception.

[0149] 5. System calls

[0150] System calls: The primary function of an operating system is to manage hardware resources and provide a favorable environment for application developers, ensuring greater compatibility. To achieve this, the kernel provides a series of multi-kernel functions with predetermined functionality, presented to users through a set of interfaces called system calls. System calls transmit application requests to the kernel, which then invokes the corresponding kernel function to complete the required processing and returns the results to the application.

[0151] System calls are very similar to regular library function calls, except that system calls are provided by the operating system kernel and run in kernel mode, while regular function calls are provided by libraries or by the user and run in user mode. Generally, a process cannot access the kernel. It cannot access kernel memory or call kernel functions. System calls switch from user context to kernel context to access kernel services.

[0152] Under the Tricore architecture, system calls also provide service access from user mode to kernel mode. Users switch to the kernel's exception handling function through the syscall instruction. At this time, the user context is automatically backed up. After entering the system call dispatch function, the kernel context is created. After processing is completed, the kernel context is recovered through the exception return instruction (RFE), the user context is restored, and the next instruction is returned.

[0153] In Tricore, context saving and restoration are both assisted by CSA.

[0154] 6. Interrupt refers to the process of temporarily suspending the current program on the CPU when encountering an event that needs to be processed urgently during program execution, and switching to executing the corresponding event handler. After the processing is completed, the program returns to the point where it was interrupted or schedules other programs to be executed.

[0155] 7. Mode switching, also known as processor state switching, includes:

[0156] User mode to kernel mode interrupt / exception / system call: triggered by interrupting the execution of user process;

[0157] Kernel mode to user mode OS executes interrupt return instruction: triggering the return of control to the user process.

[0158] Process switching refers to reclaiming the processor from the currently running process and allowing the next process to take over the processor. Process switching is essentially a context switch between the interrupted process and the next process. The process is as follows:

[0159] Save the context of the interrupted process;

[0160] Turn to process scheduling;

[0161] Restore the context of the running process.

[0162] Among them, process switching must be completed in the operating system kernel mode.

[0163] The virtual machine management method provided in the embodiment of the present application is described in detail below.

[0164] Reference Figure 2a FIG. 1 is a flow chart of a virtual machine management method provided in an embodiment of the present application. The method includes steps 201-205, which are as follows:

[0165] 201. The virtual machine application sends a system call instruction to the virtual machine manager, where the system call instruction carries a call number.

[0166] The system call instruction is a privileged instruction, and the virtual machine application can be understood as a user program.

[0167] The virtual machine manager in this application can be understood as the host corresponding to the virtual machine.

[0168] 202. The virtual machine manager receives a system call instruction from the virtual machine application, obtains a first context save area (CSA) based on the context and idle context save area (CSA) of the virtual machine, and processes a second CSA based on the call number to obtain a processed second CSA, wherein the second CSA is determined before the first CSA, the first CSA is adjacent to the processed second CSA, a return address of the first CSA is a system call service processing address of the virtual machine kernel, and a return address of the processed second CSA is a next instruction address of the virtual machine application. The processed second CSA is used to indicate a jump to the next instruction address of the virtual machine application after the system call is processed.

[0169] The virtual machine kernel can be understood as the user-mode kernel, that is, the operating system kernel.

[0170] As an optional implementation, the virtual machine manager obtains a first CSA according to the context and idle context storage area CSA of the virtual machine, including:

[0171] The virtual machine manager stores the context of the virtual machine in the free CSA to obtain the CSA of the context of the virtual machine;

[0172] The virtual machine manager modifies the mode of the subsequent CSA to kernel mode, modifies the memory protection domain of the subsequent CSA to the memory boundary of the virtual machine, modifies the stack address of the subsequent CSA to the stack address of the virtual machine, modifies the return address of the subsequent CSA to the system call service processing address of the virtual machine kernel, and modifies the context bits of the subsequent CSA to obtain a first CSA.

[0173] Specifically, obtaining an available idle CSA from the idle context list of the virtual machine can be performed by explicitly using the svlcx instruction to apply for an available context save area CSA based on the original CSA linked list.

[0174] The virtual machine manager processes the following CSA to obtain a first CSA, which can be as follows: Figure 2b As shown:

[0175] The virtual machine manager modifies the mode of the CSA below (Lb) to kernel mode, specifically by modifying the Program Status Word (PSW) of the CSA below to kernel mode; modifying the memory protection domain of the CSA below to the memory boundary of the virtual machine (client operating system OS), modifying the stack address of the CSA below to the stack address of the virtual machine (client operating system), modifying the return address of the CSA below to the system call service processing address of the virtual machine kernel (operating system kernel), and modifying the context bit of the CSA below, specifically modifying the PCXI.UL flag bit of the CSA below to the above identifier, to obtain the above CSA (Ub).

[0176] Since the return address information can only be obtained from the above context when returning from an exception, the context bits need to be transformed.

[0177] The virtual machine manager copies the call number to the second CSA and updates the return address of the second CSA to the next instruction address of the virtual machine application to obtain the processed second CSA.

[0178] The virtual machine manager determines a second CSA, i.e., the most recently saved CSA, based on the past context list in the register. This may be by finding the address (Ua) of the previous CSA using the link word in the past context list PCX. The virtual machine manager copies the call number (parameter register) in the system call instruction to the CSA and modifies the return address of the CSA to the address of the next instruction of the virtual machine application (user program), thereby obtaining the second CSA after the above processing.

[0179] The above-mentioned second CSA is determined before the first CSA, and the first CSA is adjacent to the processed second CSA. It can be understood that the second CSA is determined before the first CSA in time sequence, and the second CSA is adjacent to the first CSA.

[0180] For example, you can refer to Figure 1e , CSA2 is equivalent to the first CSA of this scheme, and CSA1 is equivalent to the second CSA of this scheme.

[0181] It should be noted that the above is only an example, and it can also be other forms of processing. For example, the order of the above modifications can be adaptively adjusted, and this solution does not make specific limitations on this.

[0182] When a call occurs, it enters the exception handling function. To avoid using pure virtual emulation to simulate system calls and reduce overhead, the client operating system's exception handling function address entry vector table is first maintained. This address is obtained by capturing the privileged instruction that sets the vector table. When a call occurs, unlike ordinary pure virtualization, this solution does not require complex context switching simulation. Instead, it uses CSA to build the client jump and return environment, fully leveraging the advantages of the Tricore architecture to achieve fast system call and return.

[0183] 203. The virtual machine manager jumps to the system call service processing address of the virtual machine kernel according to the return address of the first CSA;

[0184] Specifically, in step 203, after obtaining the first CSA and the processed second CSA, the virtual machine manager returns from the exception by calling the Return from Exception (RFE) instruction. At this point, the CSA (Ub) in the previous context is released, and the hardware tricore architecture restores the stored context to the corresponding context register. The virtual machine kernel then returns to the system call processing entry point, and the context has now been switched to the kernel context, including memory boundaries and stack information. System call processing is then performed based on the system call number requested by the virtual machine application, as shown in step 204.

[0185] As an optional implementation, the system call instruction carries the address of the virtual machine application. Before step 203, the method further includes:

[0186] The virtual machine manager compares the address of the virtual machine application with a preset legal address to confirm whether the address of the virtual machine application is legal.

[0187] The preset legal address may include multiple legal addresses, and the legality of the address of the virtual machine application is confirmed by comparing the address of the virtual machine application with the above legal addresses.

[0188] If the address of the virtual machine application is legal, step 203 is executed.

[0189] By adopting this method, the present solution verifies the legitimacy of the call initiator, thereby improving the security of the system call.

[0190] The virtual machine kernel corresponds to the virtual machine application. That is, when there are multiple virtual machine kernels, the virtual machine manager can jump to the corresponding virtual machine kernel based on the virtual machine application.

[0191] 204. The virtual machine kernel performs system call processing to obtain a processing result;

[0192] The virtual machine kernel can perform system call processing according to the call number to obtain the processing result.

[0193] Each system call is numbered, forming a system call table within the kernel—an array of function pointers. The call number is the index into the array corresponding to the function. The virtual machine application passes the call number to the kernel, allowing it to use the system function.

[0194] After the system call is processed, the virtual machine kernel calls RFE, at which time Ua is released. After Ua is released, the virtual machine kernel returns to the virtual machine application, as shown in step 205 .

[0195] 205. The virtual machine kernel jumps to the virtual machine application.

[0196] Specifically, the virtual machine kernel calls the return from exception instruction RFE, and the kernel releases the upper context Ua, and then jumps to the next instruction of the virtual machine application.

[0197] Through the embodiment of the present application, the virtual machine manager receives a system call instruction from a virtual machine application, and obtains a first CSA based on the context and idle context save area CSA of the virtual machine, processes the second CSA according to the call number, and obtains a processed second CSA. Then, the virtual machine manager executes a jump to the system call service processing address of the virtual machine kernel according to the return address of the first CSA to trigger the virtual machine kernel to perform system call processing.

[0198] This approach uses a first context save area (CSA) derived from the virtual machine's context and free context save area (CSA). This allows the virtual machine manager to execute a jump to the system call service processing address of the virtual machine kernel to perform a system call. The processed second CSA is determined before the first CSA, and the first CSA is adjacent to the processed second CSA. This allows the virtual machine kernel to jump to the virtual machine application based on the processed second CSA after the virtual machine kernel completes the system call processing. Because the CSA performs context saving and loading based on hardware, this solution reduces the number of traps to the host compared to existing technologies that require multiple traps to the host, improving system efficiency and performance.

[0199] On the other hand, this solution also verifies the legitimacy of the call initiator, further improving the security of system calls.

[0200] Moreover, this solution distributes system call processing kernels by constructing new contexts in real time, thus achieving partition isolation between virtual machines and reducing the trusted base.

[0201] Reference Figure 2c FIG. 1 is a schematic diagram of a virtual machine management method provided by an embodiment of the present application. The method includes steps S1-S6, which are as follows:

[0202] S1. After the virtual machine application issues an instruction, the CPU obtains the address of the virtual machine application and decodes the instruction.

[0203] S2. The CPU determines whether the instruction is a privileged instruction. If not, the CPU directly executes the instruction. If the instruction is a privileged instruction and is not a system call instruction, other privileged instruction emulation methods, such as pure software emulation, are used.

[0204] S3. If the instruction is a privileged instruction and a system call instruction, then the system call entry of the virtual machine manager is entered.

[0205] In S4, the virtual machine manager obtains operating environment parameters to build a CSA simulation environment. The operating environment parameters can be understood as the first CSA and the processed second CSA.

[0206] S5. The virtual machine manager jumps to the system call service processing address of the virtual machine kernel according to the return address of the first CSA to trigger the virtual machine kernel to perform system call processing.

[0207] S6. After processing the system call, the virtual machine kernel jumps to the next instruction of the virtual machine application.

[0208] This approach uses a first context save area (CSA) derived from the virtual machine's context and free context save area (CSA). This allows the virtual machine manager to execute a jump to the system call service processing address of the virtual machine kernel to perform a system call. The processed second CSA is determined before the first CSA, and the first CSA is adjacent to the processed second CSA. This allows the virtual machine kernel to jump to the virtual machine application based on the processed second CSA after the virtual machine kernel completes the system call processing. Because the CSA performs context saving and loading based on hardware, this solution reduces the number of traps to the host compared to existing technologies that require multiple traps to the host, improving system efficiency and performance.

[0209] Reference Figure 3a FIG. 1 is a flow chart of another virtual machine management method provided by an embodiment of the present application. The method includes steps 301-307, which are as follows:

[0210] 301. The virtual machine application sends a system call instruction to the virtual machine manager, where the system call instruction carries a call number.

[0211] The system call instruction is a privileged instruction.

[0212] 302. The virtual machine manager receives a system call instruction from a virtual machine application, obtains a first context save area (CSA) based on the context and idle context save area (CSA) of the virtual machine, and processes a second CSA based on the call number to obtain a processed second CSA, wherein the second CSA is determined before the first CSA, the first CSA is adjacent to the processed second CSA, a return address of the first CSA is a system call service processing address of the virtual machine kernel, and a return address of the processed second CSA is a result check address of the virtual machine manager. The processed second CSA is used to indicate a jump to the result check address of the virtual machine manager after the system call is processed.

[0213] As an optional implementation, the virtual machine manager obtains a first CSA according to the context and idle context storage area CSA of the virtual machine, including:

[0214] The virtual machine manager stores the context of the virtual machine in the free CSA to obtain the CSA of the context of the virtual machine;

[0215] The virtual machine manager modifies the mode of the subsequent CSA to kernel mode, modifies the memory protection domain of the subsequent CSA to the memory boundary of the virtual machine, modifies the stack address of the subsequent CSA to the stack address of the virtual machine, modifies the return address of the subsequent CSA to the system call service processing address of the virtual machine kernel, and modifies the context bits of the subsequent CSA to obtain a first CSA.

[0216] Specifically, obtaining an available idle CSA from the idle context list of the virtual machine can be performed by explicitly using the svlcx instruction to apply for an available context save area CSA based on the original CSA linked list.

[0217] The above-mentioned obtaining of an available CSA from the idle context list of the virtual machine may be performed by explicitly using svlcx to apply for an available context saving area CSA based on the original CSA linked list.

[0218] The virtual machine manager modifies the mode of the CSA below (Lb) to kernel mode, specifically by modifying the programming status word PSW of the CSA below to kernel mode; modifying the memory protection domain of the CSA below to the memory boundary of the virtual machine (client operating system OS), modifying the stack address of the CSA below to the stack address of the virtual machine (client operating system), modifying the return address of the CSA below to the system call service processing address of the virtual machine kernel (operating system kernel), and modifying the context bit of the CSA below, specifically modifying the PCXI.UL flag bit of the CSA below to the above identifier, to obtain the above CSA (Ub).

[0219] Since the return address information can only be obtained from the above context when returning from an exception, the context bits need to be transformed.

[0220] The above is only an example, and other forms of processing are also possible. For example, the order of the above modifications can be adaptively adjusted, and this solution does not make specific limitations on this.

[0221] The virtual machine manager determines the most recently saved CSA based on the past context list in the register, which may be performed by finding the address (Ua) of the previous CSA through the link word in the past context list PCX. The virtual machine manager copies the call number (parameter register) in the system call instruction to the CSA and modifies the return address of the CSA to the result check address of the virtual machine manager.

[0222] 303. The virtual machine manager jumps to the system call service processing address of the virtual machine kernel according to the return address of the first CSA;

[0223] Specifically, after obtaining the first CSA and the processed second CSA, the virtual machine manager returns from the exception by calling the Return from Exception (RFE) instruction. At this point, the CSA (Ub) in the previous context is released, and the hardware tricore architecture restores the stored context to the corresponding context register. The virtual machine kernel then returns to the system call processing entry point, and the context has now been switched to the kernel context, including memory boundaries and stack information. System call processing is then performed based on the system call number requested by the virtual machine application, as shown in step 304.

[0224] As an optional implementation, the system call instruction carries the address of the virtual machine application. Before step 303, the method further includes:

[0225] The virtual machine manager compares the address of the virtual machine application with a preset legal address to confirm whether the address of the virtual machine application is legal.

[0226] The preset legal address includes a plurality of legal addresses, and the legality of the address of the virtual machine application is confirmed by comparing the address of the virtual machine application with the above legal addresses.

[0227] If the address of the virtual machine application is legal, step 303 is executed.

[0228] By adopting this method, the present solution verifies the legitimacy of the call initiator, thereby improving the security of the system call.

[0229] The virtual machine kernel corresponds to the virtual machine application. That is, when there are multiple virtual machine kernels, the virtual machine manager can jump to the corresponding virtual machine kernel based on the virtual machine application.

[0230] 304. The virtual machine kernel performs system call processing to obtain a processing result;

[0231] The virtual machine kernel performs system call processing according to the call number to obtain the processing result.

[0232] Each system call is numbered, forming a system call table within the kernel—an array of function pointers. The call number is the index into the array corresponding to the function. The virtual machine application passes the call number to the kernel, allowing it to use the system function.

[0233] After the system call is processed, the virtual machine kernel calls RFE, at which time Ua is released. After Ua is released, the virtual machine kernel returns to the virtual machine manager, as shown in step 305 .

[0234] 305. The virtual machine kernel jumps to the virtual machine manager;

[0235] Specifically, the result check address returned to the virtual machine manager.

[0236] After the virtual machine kernel completes the system call processing, the kernel calls RFE, at which time Ua is released and the upper register of Ua is restored. At this time, the result check function of the virtual machine manager is returned. If the verification is correct, the virtual machine application is returned, as shown in steps 306 and 307.

[0237] 306. The virtual machine manager obtains a processing result of the virtual machine kernel and verifies the processing result;

[0238] As an optional implementation, the virtual machine manager obtains the processing result from the register and compares the range of the numerical value of the processing result with a preset range to confirm its accuracy.

[0239] As another optional implementation, the virtual machine manager verifies the size of the numerical value of the processing result to confirm whether the result is accurate.

[0240] The above are just two examples. It can also be verification of other information, and this solution does not make specific limitations on this.

[0241] 307. When the verification is passed, the virtual machine manager jumps to the virtual machine application.

[0242] Specifically, the virtual machine manager jumps to the next instruction of the virtual machine application.

[0243] By adopting this method, the present solution checks the processing result and jumps to the virtual machine application only after the verification is passed, thereby ensuring the legitimacy of the processing result and improving the security of the system call.

[0244] According to an embodiment of the present application, a virtual machine manager receives a system call instruction from a virtual machine application and obtains a first context storage area (CSA) based on the context and free context storage area (CSA) of the virtual machine. It then processes a second context storage area (CSA) based on the call number to obtain a processed second CSA. The virtual machine manager then executes a jump to the system call service processing address of the virtual machine kernel based on the return address of the first CSA, triggering the virtual machine kernel to process the system call. This approach allows the virtual machine manager to execute a jump to the system call service processing address of the virtual machine kernel to perform the system call. The processed second CSA is determined before the first CSA, and the first CSA is adjacent to the processed second CSA. Thus, after the virtual machine kernel completes the system call processing, the virtual machine kernel can jump to the virtual machine manager based on the processed second CSA to check the result. Because the CSA performs context saving and loading based on hardware, compared to the prior art method that requires multiple traps to the host, this solution reduces the number of traps, improves system operation efficiency, and enhances system performance. Moreover, this solution performs a validity check on the processing results and jumps to the virtual machine application only after the verification is passed, thereby improving the security of the system call.

[0245] On the other hand, this solution also verifies the legitimacy of the call initiator, further improving the security of system calls.

[0246] Moreover, this solution distributes system call processing kernels by constructing new contexts in real time, thus achieving partition isolation between virtual machines and reducing the trusted base.

[0247] Reference Figure 3b FIG. 1 is a schematic diagram of a virtual machine management method provided by an embodiment of the present application. The method includes steps S1-S8, which are as follows:

[0248] S1. After the virtual machine application issues an instruction, the CPU obtains the address of the virtual machine application and decodes the instruction.

[0249] S2. The CPU checks whether the instruction is a privileged instruction. If not, the CPU directly executes the instruction. If the instruction is a privileged instruction and not a system call instruction, other privileged instruction emulation is used.

[0250] S3. If the instruction is a privileged instruction and a system call instruction, then the system call entry of the virtual machine manager is entered.

[0251] In S4, the virtual machine manager obtains operating environment parameters to build a CSA simulation environment. The operating environment parameters can be understood as the first CSA and the processed second CSA.

[0252] Then, step S5 is executed, and the virtual machine manager performs a pre-verification to verify the legitimacy of the call initiator.

[0253] If the verification is passed, step S6 is executed, and the virtual machine manager jumps to the system call service processing address of the virtual machine kernel according to the return address of the first CSA to trigger the virtual machine kernel to perform system call processing.

[0254] After the processing is completed, the virtual machine kernel jumps to the virtual machine manager for post-verification, that is, S7, to verify the processing result.

[0255] After the verification is passed, S8 is executed, and the virtual machine manager jumps to the virtual machine application.

[0256] Using this method, a first CSA is derived based on the virtual machine's context and the idle context save area (CSA). This allows the virtual machine manager to execute a jump to the virtual machine kernel's system call service processing address to perform a system call. The processed second CSA is determined before the first CSA, and the first CSA is adjacent to the processed second CSA. Thus, after the virtual machine kernel completes the system call processing, the processed second CSA allows the virtual machine kernel to jump to the virtual machine manager for result verification. Because the CSA performs context saving and loading based on hardware, compared to existing technologies that require multiple traps to the host, this solution reduces the number of traps, improves system operation efficiency, and enhances system performance. Furthermore, this solution performs a validity check on the processing results, and only jumps to the virtual machine application if verification passes, thus improving the security of system calls.

[0257] Reference Figure 4a FIG. 4 is a flow chart of another virtual machine management method provided in an embodiment of the present application. The method includes steps 401-404, which are as follows:

[0258] 401. The virtual machine application sends a system call instruction to the virtual machine manager, where the system call instruction carries a call number.

[0259] The system call instruction is a privileged instruction.

[0260] 402. The virtual machine manager receives a system call instruction from a virtual machine application, and obtains a processed first context save area (CSA) based on the call number and the first context save area (CSA), wherein a return address of the processed first CSA is an address of a next instruction of the virtual machine application.

[0261] The operating environment parameters are used by the virtual machine manager to manage custom calls (Hypercall, HVC).

[0262] The virtual machine manager manages the custom call, that is, the virtual machine manager has the authority to perform custom call processing.

[0263] As an optional implementation manner, the virtual machine manager obtains the processed first context saving area CSA according to the call number and the first context saving area CSA, including:

[0264] The virtual machine manager copies the call number to the first context saving area CSA, and updates the return address of the first CSA to the next instruction address of the virtual machine application to obtain the processed first CSA.

[0265] That is, the virtual machine manager determines the most recently saved CSA (i.e., the first CSA) based on the past context list in the register;

[0266] The virtual machine manager copies the call number to the most recently saved CSA and updates the return address of the most recently saved CSA to the next instruction address of the virtual machine application.

[0267] The virtual machine manager determines the most recently saved CSA in the past context list according to the past context list in the register, and may find the address (Ua) of the previous CSA through the link word in the past context list PCX.

[0268] The virtual machine manager copies the call number (parameter register) in the system call instruction to the CSA and modifies the return address of the CSA to the next instruction address of the virtual machine application.

[0269] The above is only an example, and it can also be other forms of processing. For example, the order of the above processing can be adaptively adjusted, and this solution does not make specific limitations on this.

[0270] 403. The virtual machine manager performs system call processing to obtain a processing result;

[0271] Specifically, the virtual machine manager performs system call processing based on the call number.

[0272] As an optional implementation, the system call instruction carries the address of the virtual machine application. Before step 403, the method further includes:

[0273] The virtual machine manager compares the address of the virtual machine application with a preset legal address to confirm whether the address of the virtual machine application is legal.

[0274] The preset legal address stores a plurality of legal addresses, and the legality of the address of the virtual machine application is confirmed by comparing the address of the virtual machine application with the above legal addresses.

[0275] If the address of the virtual machine application is legal, step 403 is executed.

[0276] By adopting this method, the present solution verifies the legitimacy of the call initiator, thereby improving the security of the system call.

[0277] 404. After processing the system call, the virtual machine manager jumps to the virtual machine application according to the return address of the processed first CSA.

[0278] Specifically, jump to the next instruction of the virtual machine application.

[0279] Through the embodiment of the present application, the virtual machine manager receives a system call instruction from a virtual machine application and obtains a processed first context save area (CSA) based on the call number and the first context save area (CSA). The return address of the processed first CSA is the next instruction address of the virtual machine application. The virtual machine manager then performs system call processing based on the call number, and after the system call processing is completed, it jumps to the next instruction address of the virtual machine application based on the return address of the processed first CSA. By adopting this approach, the present solution adds same-layer HVC call processing, which can be used to process custom HVC requests. In other words, the virtual machine manager performs system call processing and, after the system call processing is completed, jumps to the next instruction address of the virtual machine application. By adopting this approach, the efficiency of system operation is improved and system performance is enhanced.

[0280] Reference Figure 4b FIG. 1 is a schematic diagram of a virtual machine management method provided by an embodiment of the present application. The method includes steps S1-S6, which are as follows:

[0281] S1. After the virtual machine application issues an instruction, the CPU obtains the address of the virtual machine application and decodes the instruction.

[0282] S2. The CPU checks whether the instruction is a privileged instruction. If not, the CPU directly executes the instruction. If the instruction is a privileged instruction and not a system call instruction, other privileged instruction emulation is used.

[0283] S3. If the instruction is a privileged instruction and a system call instruction, then the system call entry of the virtual machine manager is entered.

[0284] In S4, the virtual machine manager builds a CSA simulation environment for custom HVC calls, which is the first CSA after the above processing.

[0285] S5. The virtual machine manager calls the HVC call processing function entry and enters the HVC call service processing function to perform system call processing.

[0286] S6. The virtual machine manager jumps to the next instruction of the virtual machine application.

[0287] By using this method, this solution adds the same-layer HVC call processing, which can be used to process custom HVC requests. In other words, the virtual machine manager processes the system call and jumps to the next instruction address of the virtual machine application after the system call is processed. This method improves the efficiency of system operation and improves system performance.

[0288] Reference Figure 5a FIG. 5 is a flow chart of another virtual machine management method provided in an embodiment of the present application. The method includes steps 501-505, which are as follows:

[0289] 501. The virtual machine manager receives an interrupt instruction from a device external to the virtual machine;

[0290] It should be noted that interrupts are generated by external devices (such as hardware errors, input errors).

[0291] The external device is relative to the virtual machine, and may be, for example, a keyboard, a mouse, a sensor, etc.

[0292] For example, when a specific event occurs, the keyboard will trigger an interrupt instruction, etc.

[0293] 502. The virtual machine manager obtains an interrupt pending bit corresponding to the interrupt instruction;

[0294] 503. The virtual machine manager determines a target virtual machine according to the interrupt pending bit, wherein the kernel of the target virtual machine is the kernel to which the interrupt pending bit belongs;

[0295] Among them, the virtual machine manager can obtain the core ID of the CPU of each virtual machine and the interrupt pending bit in turn to determine whether the interrupt pending bit belongs to the core corresponding to the core ID of the CPU of the virtual machine. If it does, the virtual machine is the target virtual machine.

[0296] 504. The virtual machine manager obtains a first context save area (CSA) based on the context and idle context save area (CSA) of the target virtual machine, and processes a second CSA to obtain a processed second CSA, wherein the second CSA is determined before the first CSA, the first CSA is adjacent to the processed second CSA, a return address of the first CSA is an interrupt handling address of the kernel of the target virtual machine, a return address of the processed second CSA is a current instruction address of an application of the target virtual machine, and the processed second CSA is used to indicate a jump to the current instruction address of the application of the target virtual machine after the interrupt is handled;

[0297] The virtual machine manager obtains an available context saving area CSA from the idle context list of the target virtual machine;

[0298] The virtual machine manager stores the context of the target virtual machine in the available CSA to obtain the CSA of the context of the target virtual machine;

[0299] The virtual machine manager modifies the mode of the subsequent CSA to kernel mode, modifies the memory protection domain of the subsequent CSA to the memory boundary of the target virtual machine, modifies the stack address of the subsequent CSA to the stack address of the target virtual machine, modifies the return address of the subsequent CSA to the interrupt handling address of the kernel of the target virtual machine, and modifies the context bit of the subsequent CSA to obtain a first CSA.

[0300] The virtual machine manager determines a most recently saved second CSA based on the past context list in the register;

[0301] The virtual machine manager updates the return address of the most recently saved CSA to the current instruction address of the application of the target virtual machine.

[0302] If the pending interrupt bit does not belong to the target virtual machine kernel, the virtual machine manager jumps to the current running instruction of the virtual machine application.

[0303] 505. The virtual machine manager jumps to the kernel of the target virtual machine according to the return address of the first CSA, so that the kernel of the target virtual machine performs interrupt processing.

[0304] After the interrupt is processed, the kernel of the target virtual machine jumps to the current instruction address of the application of the target virtual machine.

[0305] According to an embodiment of the present application, after receiving an interrupt instruction from an external device, if the interrupt pending bit belongs to the target virtual machine kernel, the virtual machine manager obtains a first context save area (CSA) based on the context and idle context save area (CSA) of the target virtual machine, processes the second CSA, and obtains a processed second CSA. The virtual machine manager then executes a jump to the target virtual machine kernel based on the return address of the first CSA so that the target virtual machine kernel can handle the interrupt. Based on the processed second CSA, the virtual machine kernel can jump to the next hop address of the virtual machine kernel. Compared with the prior art that requires multiple traps to the host, this solution reduces the number of traps, improves the efficiency of system operation, and improves system performance.

[0306] This solution distributes system call processing kernels by constructing new contexts in real time, achieving partition isolation between virtual machines and reducing the trusted base. Using this solution, interrupt virtualization can be achieved.

[0307] like Figure 5b FIG. 1 is a flow chart of a virtual machine management method according to an embodiment of the present application. The method includes steps S1-S6, which are as follows:

[0308] S1. An external device triggers an interrupt instruction, and the virtual machine manager obtains the core ID of the CPU of the virtual machine.

[0309] S2. The virtual machine manager checks the current interrupt bit and determines whether the current interrupt bit belongs to the core of the CPU of the virtual machine. If not, the virtual machine manager jumps to the current instruction address of the virtual machine core.

[0310] If the current interrupt bit belongs to the core of the CPU of the virtual machine, step S3 is executed, and the virtual machine manager clears the interrupt bit.

[0311] S4. The virtual machine manager changes the memory protection domain.

[0312] S5. The virtual machine manager changes the return address of the context to a kernel address to construct a CSA simulation environment.

[0313] S6. The virtual machine manager jumps to the virtual machine kernel according to the CSA simulation environment to perform interrupt processing.

[0314] Compared with the prior art which requires multiple trapping into the host, this solution reduces the number of trapping times, improves the efficiency of system operation, and improves system performance.

[0315] This solution distributes system call processing kernels by constructing new contexts in real time, achieving partition isolation between virtual machines and reducing the trusted base. Using this solution, interrupt virtualization can be achieved.

[0316] Reference Figure 6a As shown, an embodiment of the present application provides a virtual machine management device. The device includes: a receiving module 601, a determining module 602 and a processing module 603, which are specifically as follows:

[0317] A receiving module 601 is configured to receive a system call instruction from a virtual machine application, wherein the system call instruction carries a call number and is a privileged instruction;

[0318] a determination module 602 configured to obtain a first context save area (CSA) based on the context and idle context save area (CSA) of the virtual machine, and process a second CSA based on the call number to obtain a processed second CSA, wherein the second CSA is determined before the first CSA, the first CSA is adjacent to the processed second CSA, a return address of the first CSA is a system call service processing address of the virtual machine kernel, the return address of the processed second CSA is an address of a next hop of the virtual machine kernel, and the processed second CSA is used to indicate an address of a next hop to the virtual machine kernel after the system call is processed;

[0319] The processing module 603 is configured to execute a jump to the system call service processing address of the virtual machine kernel according to the return address of the first CSA, so as to trigger the virtual machine kernel to perform system call processing.

[0320] As an optional implementation, the determination module 602 is used to: store the context of the virtual machine in the idle CSA to obtain the context CSA of the virtual machine; modify the mode of the context CSA to kernel mode, modify the memory protection domain of the context CSA to the memory boundary of the virtual machine, modify the stack address of the context CSA to the stack address of the virtual machine, modify the return address of the context CSA to the system call service processing address of the virtual machine kernel, and modify the context bit of the context CSA to obtain the first CSA.

[0321] As an optional implementation, the determination module 602 is further used to: copy the call number to the second CSA, and update the return address of the second CSA to the address of the next hop of the virtual machine kernel to obtain the processed second CSA.

[0322] As an optional implementation manner, the next hop address of the virtual machine kernel is the next instruction address of the virtual machine application.

[0323] As another optional implementation manner, the next hop address of the virtual machine kernel is the result check address of the device.

[0324] As an optional implementation, the device further includes a first verification module, which is used to: obtain the processing result of the virtual machine kernel and verify the processing result; when the processing result is verified, jump to the virtual machine application.

[0325] As an optional implementation method, the system call instruction also carries the address of the virtual machine application, and the device also includes a second verification module for comparing the address of the virtual machine application with a preset legal address to confirm whether the address of the virtual machine application is legal.

[0326] According to an embodiment of the present application, a virtual machine manager receives a system call instruction from a virtual machine application and obtains a first context storage area (CSA) based on the context and free context storage area (CSA) of the virtual machine. The virtual machine manager processes a second context storage area (CSA) based on the call number to obtain a processed second CSA. The virtual machine manager then executes a jump to the system call service processing address of the virtual machine kernel based on the return address of the first CSA, triggering the virtual machine kernel to process the system call. This approach allows the virtual machine manager to execute a jump to the system call service processing address of the virtual machine kernel to perform the system call. The processed second CSA is determined before the first CSA, and the first CSA is adjacent to the processed second CSA. Thus, after the virtual machine kernel completes the system call processing, the virtual machine kernel can jump to the next hop address of the virtual machine kernel based on the processed second CSA. Compared to the prior art method of trapping into the host multiple times, this solution reduces the number of traps, improves system operation efficiency, and enhances system performance.

[0327] The specific execution steps of each module in the device can be referred to the aforementioned Figure 2a 、 Figure 2b 、 Figure 2c The embodiment shown, or Figure 3a 、 Figure 3b The embodiments shown will not be described in detail here.

[0328] Reference Figure 6b As shown, another virtual machine management device provided by an embodiment of the present application includes: a receiving module 604, a determining module 605 and a processing module 606, specifically as follows:

[0329] A receiving module 604 is configured to receive a system call instruction from a virtual machine application, wherein the system call instruction carries a call number and is a privileged instruction;

[0330] a determination module 605 configured to obtain a processed first context save area (CSA) according to the call number and the first context save area (CSA), wherein a return address of the processed first CSA is an address of a next instruction of the virtual machine application;

[0331] The processing module 606 is configured to perform system call processing according to the call number, and after the system call processing is completed, execute a jump to the next instruction address of the virtual machine application according to the return address of the processed first CSA.

[0332] As an optional implementation method, the determination module 605 is used to: copy the call number to the first context saving area CSA, and update the return address of the first CSA to the next instruction address of the virtual machine application to obtain the processed first CSA.

[0333] As an optional implementation, the system call instruction also carries the address of the virtual machine application, and the device also includes a second verification module for comparing the address of the virtual machine application with a preset legal address to confirm whether the address of the virtual machine application is legal.

[0334] Through the embodiment of the present application, the virtual machine manager receives a system call instruction from a virtual machine application and obtains a processed first context save area (CSA) based on the call number and the first context save area (CSA). The return address of the processed first CSA is the next instruction address of the virtual machine application. The virtual machine manager then performs system call processing based on the call number, and after the system call processing is completed, it jumps to the next instruction address of the virtual machine application based on the return address of the processed first CSA. By adopting this approach, the present solution adds same-layer HVC call processing, which can be used to process custom HVC requests. In other words, the virtual machine manager performs system call processing and, after the system call processing is completed, jumps to the next instruction address of the virtual machine application. By adopting this approach, the efficiency of system operation is improved and system performance is enhanced.

[0335] The specific execution steps of each module in the device can be referred to the aforementioned Figure 4a 、 Figure 4b The embodiments shown will not be described in detail here.

[0336] Reference Figure 6c As shown, another virtual machine management device provided by an embodiment of the present application includes: an acquisition module 607, a first determination module 608, a second determination module 609 and a processing module 610, specifically as follows:

[0337] The acquisition module 607 is configured to acquire an interrupt pending bit corresponding to an interrupt instruction when receiving the interrupt instruction from a device external to the virtual machine;

[0338] A first determining module 608 is configured to determine a target virtual machine according to the interrupt pending bit, wherein the kernel of the target virtual machine is the kernel to which the interrupt pending bit belongs;

[0339] a second determining module 609 configured to obtain a first context save area (CSA) based on the context and idle context save area (CSA) of the target virtual machine, and process a second CSA to obtain a processed second CSA, wherein the second CSA is determined before the first CSA, the first CSA is adjacent to the processed second CSA, a return address of the first CSA is an interrupt handling address of the kernel of the target virtual machine, a return address of the processed second CSA is a current instruction address of an application of the target virtual machine, and the processed second CSA is used to indicate a jump to the current instruction address of the application of the target virtual machine after the interrupt is handled;

[0340] The processing module 610 is configured to execute a jump to the interrupt handling address of the kernel of the target virtual machine according to the return address of the first CSA, so as to trigger the kernel of the target virtual machine to perform interrupt handling.

[0341] As an optional implementation method, the second determination module 609 is used to: store the context of the target virtual machine in the idle CSA to obtain the CSA of the context of the target virtual machine; modify the mode of the CSA of the context to kernel mode, modify the memory protection domain of the CSA of the context to the memory boundary of the target virtual machine, modify the stack address of the CSA of the context to the stack address of the target virtual machine, modify the return address of the CSA of the context to the interrupt handling address of the kernel of the target virtual machine, and modify the context bit of the CSA of the context to obtain the first CSA.

[0342] As an optional implementation, the second determining module 609 is further configured to update the return address of the second CSA to the current instruction address of the application of the target virtual machine to obtain the processed second CSA.

[0343] According to an embodiment of the present application, after receiving an interrupt instruction from an external device, if the interrupt pending bit belongs to the target virtual machine kernel, the virtual machine manager obtains a first context save area (CSA) based on the context and idle context save area (CSA) of the target virtual machine, processes the second CSA, and obtains a processed second CSA. The virtual machine manager then executes a jump to the target virtual machine kernel based on the return address of the first CSA so that the target virtual machine kernel can handle the interrupt. Based on the processed second CSA, the virtual machine kernel can jump to the next hop address of the virtual machine kernel. Compared with the prior art that requires multiple traps to the host, this solution reduces the number of traps, improves the efficiency of system operation, and improves system performance.

[0344] This solution distributes system call processing kernels by constructing new contexts in real time, achieving partition isolation between virtual machines and reducing the trusted base. Using this solution, interrupt virtualization can be achieved.

[0345] The specific execution steps of each module in the device can be referred to the aforementioned Figure 5a 、 Figure 5b The embodiments shown will not be described in detail here.

[0346] In this embodiment, each of the aforementioned virtual machine management devices is implemented as a module. A "module" here may refer to an application-specific integrated circuit (ASIC), a processor and memory that executes one or more software or firmware programs, an integrated logic circuit, and / or other devices that can provide the aforementioned functions.

[0347] In addition, the modules in each of the above virtual machine management devices can be Figure 7 The virtual machine management device is implemented by the processor 702 shown.

[0348] Figure 7 This is a schematic diagram of the hardware structure of the virtual machine management device provided in an embodiment of the present application. Figure 7 The virtual machine management apparatus 700 shown (the apparatus 700 may be a computer device) includes a memory 701, a processor 702, a communication interface 703, and a bus 704. The memory 701, the processor 702, and the communication interface 703 are connected to each other via the bus 704.

[0349] The memory 701 may be a read-only memory (ROM), a static storage device, a dynamic storage device or a random access memory (RAM).

[0350] The memory 701 can store programs. When the program stored in the memory 701 is executed by the processor 702, the processor 702 and the communication interface 703 are used to perform the various steps of the virtual machine management method of the embodiment of the present application.

[0351] The processor 702 can adopt a general central processing unit (CPU), a microprocessor, an application specific integrated circuit (ASIC), a graphics processing unit (GPU) or one or more integrated circuits to execute relevant programs to implement the functions required to be performed by the units in the virtual machine management device of the embodiment of the present application, or to execute the virtual machine management method of the method embodiment of the present application.

[0352] The processor 702 may also be an integrated circuit chip having signal processing capabilities. During implementation, the various steps of the virtual machine management method of the present application may be completed by hardware integrated logic circuits or software instructions in the processor 702. The above-mentioned processor 702 may also be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, a discrete gate or transistor logic device, or a discrete hardware component. The various methods, steps, and logic block diagrams disclosed in the embodiments of the present application may be implemented or executed. The general-purpose processor may be a microprocessor or the processor may also be any conventional processor, etc.

[0353] Among them, the steps of the method disclosed in conjunction with the embodiment of the present application can be directly embodied as being executed by a hardware decoding processor, or can be executed by a combination of hardware and software modules in the decoding processor. The software module can be located in a storage medium mature in the art, such as a random access memory, a flash memory, a read-only memory, a programmable read-only memory, or an electrically erasable programmable memory, a register, etc. The storage medium is located in the memory 701, and the processor 702 reads the information in the memory 701 and, in combination with its hardware, completes the functions required to be executed by the units included in the virtual machine management device of the embodiment of the present application, or executes the virtual machine management method of the method embodiment of the present application.

[0354] The communication interface 703 uses a transceiver device such as, but not limited to, a transceiver to implement communication between the apparatus 700 and other devices or a communication network. For example, data can be obtained through the communication interface 703 .

[0355] The bus 704 may include a path for transmitting information between various components of the device 700 (eg, the memory 701 , the processor 702 , and the communication interface 703 ).

[0356] It should be noted that although Figure 7 The device 700 shown only shows a memory, a processor, and a communication interface. However, in the specific implementation process, those skilled in the art should understand that the device 700 also includes other devices necessary for normal operation. At the same time, according to specific needs, those skilled in the art should understand that the device 700 may also include hardware devices that implement other additional functions. In addition, those skilled in the art should understand that the device 700 may also include only the devices necessary to implement the embodiments of the present application, and does not necessarily include Figure 7 All devices shown in .

[0357] An embodiment of the present application also provides a computer-readable storage medium, which stores instructions. When the computer-readable storage medium is executed on a computer or a processor, the computer or processor executes one or more steps in any of the above methods.

[0358] The present application also provides a computer program product comprising instructions, which, when executed on a computer or processor, causes the computer or processor to execute one or more steps in any of the above methods.

[0359] Those skilled in the art will clearly understand that, for the convenience and brevity of description, the specific working processes of the above-described systems, devices and units can refer to the specific descriptions of the corresponding steps in the aforementioned method embodiments and will not be repeated here.

[0360] It should be understood that in the description of this application, unless otherwise specified, " / " indicates that the objects associated with each other are in an "or" relationship. For example, A / B can mean A or B; where A and B can be singular or plural. Also, in the description of this application, unless otherwise specified, "multiple" means two or more than two. "At least one of the following" or similar expressions refers to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can mean: a, b, c, ab, ac, bc, or abc, where a, b, and c can be single or plural. In addition, to facilitate the clear description of the technical solutions of the embodiments of this application, in the embodiments of this application, words such as "first" and "second" are used to distinguish between identical or similar items with substantially the same functions and effects. Those skilled in the art will understand that words such as "first" and "second" do not limit the quantity or execution order, and words such as "first" and "second" do not necessarily mean different. At the same time, in the embodiments of this application, words such as "exemplary" or "for example" are used to indicate examples, illustrations, or descriptions. Any embodiment or design described as "exemplary" or "for example" in the embodiments of this application should not be interpreted as being more preferred or more advantageous than other embodiments or designs. Rather, the use of words such as "exemplary" or "for example" is intended to present the relevant concepts in a concrete manner to facilitate understanding.

[0361] In the several embodiments provided in this application, it should be understood that the disclosed systems, devices, and methods can be implemented in other ways. For example, the division of the units is only a logical function division, and there may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. The mutual coupling, direct coupling, or communication connection shown or discussed can be through some interface, indirect coupling or communication connection of devices or units, and can be electrical, mechanical or other forms.

[0362] Units described as separate components may or may not be physically separate, and components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected to achieve the purpose of this embodiment according to actual needs.

[0363] In the above embodiments, all or part of the embodiments may be implemented by software, hardware, firmware, or any combination thereof. When implemented using software, all or part of the embodiments may be implemented in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions according to the embodiments of the present application are generated. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted via the computer-readable storage medium. The computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via a wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) method. The computer-readable storage medium may be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more available media integrated therein. The available medium may be a read-only memory (ROM), a random access memory (RAM), a magnetic medium such as a floppy disk, a hard disk, a tape, a magnetic disk, or an optical medium such as a digital versatile disc (DVD), or a semiconductor medium such as a solid state disk (SSD).

[0364] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any changes or substitutions within the technical scope disclosed in the present invention should be included in the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be based on the scope of protection of the claims.

Claims

1. A virtual machine management method, characterized in that: The method comprises: The virtual machine manager receives a system call instruction from a virtual machine application, wherein the system call instruction carries a call number, wherein the system call instruction is a privileged instruction; The virtual machine manager obtains a first CSA based on the context and idle context save area CSA of the virtual machine, and processes a second CSA based on the call number to obtain a processed second CSA, wherein the second CSA is determined before the first CSA, the first CSA is adjacent to the processed second CSA, a return address of the first CSA is a system call service processing address of the virtual machine kernel, the return address of the processed second CSA is an address of a next hop of the virtual machine kernel, and the processed second CSA is used to indicate a jump to the address of the next hop of the virtual machine kernel after the system call is processed; The virtual machine manager executes a jump to the system call service processing address of the virtual machine kernel according to the return address of the first CSA to trigger the virtual machine kernel to perform system call processing.

2. The method according to claim 1, characterized in that The virtual machine manager obtains a first context saving area (CSA) according to the context of the virtual machine and an idle context saving area (CSA), including: The virtual machine manager stores the context of the virtual machine in the free CSA to obtain the CSA of the context of the virtual machine; The virtual machine manager modifies the mode of the subsequent CSA to kernel mode, modifies the memory protection domain of the subsequent CSA to the memory boundary of the virtual machine, modifies the stack address of the subsequent CSA to the stack address of the virtual machine, modifies the return address of the subsequent CSA to the system call service processing address of the virtual machine kernel, and modifies the context bits of the subsequent CSA to obtain a first CSA.

3. The method according to claim 1 or 2, characterized in that The virtual machine manager copies the call number to the second CSA and updates the return address of the second CSA to the address of the next hop of the virtual machine kernel to obtain the processed second CSA.

4. The method according to claim 1 or 2, characterized in that The next hop address of the virtual machine kernel is the next instruction address of the virtual machine application.

5. The method according to claim 1 or 2, characterized in that The next hop address of the virtual machine kernel is the result check address of the virtual machine manager.

6. The method according to claim 5, characterized in that The method further comprises: The virtual machine manager obtains the processing result of the virtual machine kernel and verifies the processing result; When the processing result is verified to be successful, the virtual machine manager jumps to the virtual machine application.

7. The method according to claim 1 or 2, characterized in that The system call instruction also carries the address of the virtual machine application, and before the virtual machine manager executes a jump to the virtual machine kernel according to the return address of the first CSA, the method further includes: The virtual machine manager compares the address of the virtual machine application with a preset legal address to confirm whether the address of the virtual machine application is legal.

8. A virtual machine management method, characterized in that: The method comprises: When receiving an interrupt instruction from a device external to the virtual machine, the virtual machine manager obtains an interrupt pending bit corresponding to the interrupt instruction; The virtual machine manager determines a target virtual machine according to the interrupt pending bit, wherein the kernel of the target virtual machine is the kernel to which the interrupt pending bit belongs; The virtual machine manager obtains a first context save area (CSA) based on the context and idle context save area (CSA) of the target virtual machine, and processes a second CSA to obtain a processed second CSA, wherein the second CSA is determined before the first CSA, the first CSA is adjacent to the processed second CSA, a return address of the first CSA is an interrupt handling address of the kernel of the target virtual machine, a return address of the processed second CSA is a current instruction address of an application of the target virtual machine, and the processed second CSA is used to indicate a jump to the current instruction address of the application of the target virtual machine after the interrupt is handled; The virtual machine manager jumps to the interrupt handling address of the kernel of the target virtual machine according to the return address of the first CSA to trigger the kernel of the target virtual machine to perform interrupt handling.

9. The method according to claim 8, characterized in that The virtual machine manager obtains a first context saving area (CSA) according to the context of the target virtual machine and an idle context saving area (CSA), including: The virtual machine manager stores the context of the target virtual machine in the free CSA to obtain the CSA of the context of the target virtual machine; The virtual machine manager modifies the mode of the subsequent CSA to kernel mode, modifies the memory protection domain of the subsequent CSA to the memory boundary of the target virtual machine, modifies the stack address of the subsequent CSA to the stack address of the target virtual machine, modifies the return address of the subsequent CSA to the interrupt handling address of the kernel of the target virtual machine, and modifies the context bits of the subsequent CSA to obtain a first CSA.

10. The method according to claim 8 or 9, characterized in that The virtual machine manager updates the return address of the second CSA to the current instruction address of the application of the target virtual machine to obtain the processed second CSA.

11. A virtual machine management device, characterized in that: The device comprises: a receiving module, configured to receive a system call instruction from a virtual machine application, wherein the system call instruction carries a call number, and wherein the system call instruction is a privileged instruction; a determination module, configured to obtain a first CSA based on the context and idle context save area CSA of the virtual machine, and process a second CSA based on the call number to obtain a processed second CSA, wherein the second CSA is determined before the first CSA, the first CSA is adjacent to the processed second CSA, a return address of the first CSA is a system call service processing address of the virtual machine kernel, the return address of the processed second CSA is an address of a next hop of the virtual machine kernel, and the processed second CSA is used to indicate a jump to the address of the next hop of the virtual machine kernel after the system call is processed; A processing module is used to execute a jump to the system call service processing address of the virtual machine kernel according to the return address of the first CSA, so as to trigger the virtual machine kernel to perform system call processing.

12. The device according to claim 11, characterized in that The determining module is configured to: Storing the context of the virtual machine in the idle CSA to obtain the CSA of the context of the virtual machine; The mode of the CSA below is modified to kernel mode, the memory protection domain of the CSA below is modified to the memory boundary of the virtual machine, the stack address of the CSA below is modified to the stack address of the virtual machine, the return address of the CSA below is modified to the system call service processing address of the virtual machine kernel, and the context bits of the CSA below are modified to obtain a first CSA.

13. The device according to claim 11 or 12, characterized in that The determining module is further configured to: The call number is copied to the second CSA, and the return address of the second CSA is updated to the address of the next hop of the virtual machine kernel to obtain the processed second CSA.

14. The device according to claim 11 or 12, characterized in that The next hop address of the virtual machine kernel is the next instruction address of the virtual machine application.

15. The device according to claim 11 or 12, characterized in that The next hop address of the virtual machine kernel is the result check address of the device.

16. The device according to claim 15, characterized in that The device further includes a first verification module, configured to: Obtaining a processing result of the virtual machine kernel and verifying the processing result; When the processing result is verified, jump to the virtual machine application.

17. The device according to claim 11 or 12, characterized in that The system call instruction also carries the address of the virtual machine application, and the apparatus further includes a second verification module, configured to: The address of the virtual machine application is compared with a preset legal address to confirm whether the address of the virtual machine application is legal.

18. A virtual machine management device, characterized in that: The device comprises: An acquisition module, configured to, upon receiving an interrupt instruction from a device external to the virtual machine, acquire an interrupt pending bit corresponding to the interrupt instruction; A first determining module is configured to determine a target virtual machine according to the interrupt pending bit, wherein the kernel of the target virtual machine is the kernel to which the interrupt pending bit belongs; a second determining module, configured to obtain a first CSA based on the context and idle context save area CSA of the target virtual machine, and process a second CSA to obtain a processed second CSA, wherein the second CSA is determined before the first CSA, the first CSA is adjacent to the processed second CSA, a return address of the first CSA is an interrupt handling address of the kernel of the target virtual machine, the return address of the processed second CSA is a current instruction address of an application of the target virtual machine, and the processed second CSA is used to indicate a jump to the current instruction address of the application of the target virtual machine after the interrupt is handled; A processing module is used to execute a jump to the interrupt processing address of the kernel of the target virtual machine according to the return address of the first CSA, so as to trigger the kernel of the target virtual machine to perform interrupt processing.

19. The device according to claim 18, characterized in that The second determining module is configured to: Storing the context of the target virtual machine in the idle CSA to obtain the CSA of the context of the target virtual machine; The mode of the CSA below is modified to kernel mode, the memory protection domain of the CSA below is modified to the memory boundary of the target virtual machine, the stack address of the CSA below is modified to the stack address of the target virtual machine, the return address of the CSA below is modified to the interrupt handling address of the kernel of the target virtual machine, and the context bits of the CSA below are modified to obtain a first CSA.

20. The device according to claim 18 or 19, characterized in that The second determining module is further configured to: The return address of the second CSA is updated to the current instruction address of the application of the target virtual machine to obtain the processed second CSA.

21. A virtual machine management device, characterized in that: The method comprises a processor and a memory; wherein the memory is used to store program code, and the processor is used to call the program code to execute the method according to any one of claims 1 to 7, and / or the method according to any one of claims 8 to 10.

22. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, and the computer program is executed by a processor to implement the method according to any one of claims 1 to 7 and / or the method according to any one of claims 8 to 10.

23. A computer program product, characterized in that When the computer program product is run on a computer, the computer is caused to execute the method according to any one of claims 1 to 7 and / or the method according to any one of claims 8 to 10.

Images