A communication system and method based on a virtual machine monitor

Abstract

The application provides a communication system and method based on a virtual machine monitor, which comprises: a hardware layer for providing hardware resources; a virtual machine monitor layer for allocating, controlling and isolating the hardware resources, and for performing client scheduling and client isolation, and limiting the direct access of the clients to the hardware resources; and a client layer comprising a plurality of clients independently running in an operating system kernel privilege level, the client layer communicating with the virtual machine monitor layer through the virtual machine monitor, and being used for initiating a resource access request and a task scheduling service, and accessing the hardware resources through the virtual machine monitor. The application realizes the mixed deployment of safety critical tasks and non-critical tasks in a core or multiple cores by completely isolating the clients of different security levels, and can prevent the abnormality of a single client from spreading to other clients and the virtual machine monitor, thereby realizing the reliable co-core operation of high and low security level functions, and solving or alleviating the security and stability problems of the co-core deployment.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a communication system and method based on a virtual machine monitor. Background Technology

[0002] In some embedded fields (such as automotive electronics, industrial control, and rail transportation), in order to achieve secure isolation and resource sharing of multi-core / multi-task, various virtualization schemes for the Cortex-R series (processors for real-time systems) have been proposed. However, the virtualization schemes proposed by these technologies have some drawbacks, such as the inability to reliably deploy security-related critical functions and non-critical functions on the same core. Summary of the Invention

[0003] This application provides a communication system and method based on a virtual machine monitor to solve or alleviate the problems described above.

[0004] In a first aspect, this application provides a communication system based on a virtual machine monitor, comprising: a hardware layer for providing hardware resources; a virtual machine monitor layer for allocating, controlling, and isolating the hardware resources, as well as scheduling and isolating guest machines, restricting guest machines from directly accessing the hardware resources; wherein the virtual machine monitor layer includes a virtual machine monitor running at the virtualization privilege level; and a guest layer including multiple guest machines running independently at the operating system kernel privilege level, wherein the guest layer communicates with the virtual machine monitor layer through the virtual machine monitor to initiate resource access requests and task scheduling services, and accesses the hardware resources through the virtual machine monitor.

[0005] Compared with related technologies, this communication system based on a virtual machine monitor has at least the following advantages: It enables secure interaction between the client and the virtual machine monitor without modifying the client OS (Operating System) kernel, supports mixed deployment of multiple types of RTOS (Real-Time Operating System) and bare-metal tasks, and improves compatibility and deployment flexibility. Furthermore, this application adopts a layered independent architecture design, with clear boundaries and independent operation between the hardware layer, the virtual machine monitor layer, and the client layer. The core modules within the virtual machine monitor layer are independently encapsulated and loosely coupled, while the hierarchical interaction between the virtual machine monitor layer and the client layer is achieved through hyper-call interfaces, avoiding strong coupling interference between core modules and layers. Furthermore, this application achieves full access isolation for clients with different security levels, enabling ASIL-D (Automotive Safety Integrity Level-D) level safety-critical tasks and QM (Quality Management) level non-critical tasks to be deployed on the same core or multiple cores in a hybrid manner. Each client independently occupies dedicated memory, external devices, and cache resources, which can isolate faults from each other, ensuring that anomalies in a single client will not spread to other clients and virtual machine monitors. This achieves reliable co-core operation of functions with high and low security levels, solving or mitigating the security and stability challenges of co-core deployment.

[0006] In one possible implementation of the first aspect, the virtual machine monitor layer includes a virtualization scheduling module, an inter-core isolation module, a resource management module, and an exception and interrupt handling module; the virtualization scheduling module is used to configure scheduling rules and perform guest scheduling according to the scheduling rules; wherein, the scheduling rules include at least one of priority and time slice; the inter-core isolation module is used to configure isolation rules and isolate the hardware resources and the guest according to the isolation rules, restricting the guest from directly accessing the hardware resources; wherein, the isolation rules include at least one of memory isolation, interrupt isolation, cache isolation, and external device isolation; the resource management module is used to perform static allocation and dynamic management of hardware resources according to pre-allocation mode and on-demand request mode, and synchronize the hardware resource allocation and management status to the virtualization scheduling module and the inter-core isolation module; the exception and interrupt handling module is used to monitor exceptions and interrupt requests in real time; wherein, the exceptions include at least one of unauthorized access, instruction errors, and cache conflicts. Therefore, this application, by abandoning the redundant and complex functional design of general-purpose hypervisors and adopting a minimized TCB (Trusted Computing Base) architecture, sets up virtualization scheduling modules, inter-core isolation modules, resource management modules, and exception and interrupt handling modules. Without redundant functional overhead, the hypervisor code size can be strictly controlled within the preset storage size, reducing the operating overhead caused by redundant software functions from the source, greatly saving on-chip storage resources, solving the problem of the bloated size of traditional general-purpose hypervisors, and adapting to processor resource-constrained scenarios. At the same time, the streamlined architecture can also significantly reduce the system security attack surface, solving the defect of a large system security attack surface.

[0007] In one possible implementation of the first aspect, if the scheduling rules include priority and time slices, then when the virtualization scheduling module performs guest scheduling, it includes: starting the highest-priority guest according to a preset priority, so that the highest-priority guest runs its own task within a preset time slice; and when the task execution time of the highest-priority guest reaches the preset time slice, actively triggering a context switch through the virtual machine monitor, and starting the remaining guests in order of priority. Therefore, the virtualization scheduling module can use a hybrid scheduling mechanism of priority and time slices to start guests.

[0008] In one possible implementation of the first aspect, if the scheduling rules include priority and time slices, the virtualization scheduling module, when scheduling clients, further includes: allocating time slices to each client according to a preset scheduling period, and scheduling clients according to the preset scheduling period, so that each client exclusively occupies central processing unit resources within the allocated time slice; and when the current client has a target task, requesting an extension of the current client's time slice through a hypercall interface, and adjusting the time slices of the current client and the next client after the virtual machine monitor verifies the time slice delay request, so that the current client can complete the target task based on the adjusted time slice, and the next client can perform basic operations based on the adjusted time slice; wherein, the preset scheduling period is the sum of the time slices allocated to all clients. Therefore, the virtualization scheduling module adopts a priority and time slice hybrid scheduling mechanism, which can pre-allocate fixed time slices to each client, and the scheduling period is fixed, eliminating the timing uncertainty caused by dynamic preemption. Simultaneously, by integrating a scheduling jitter compensation mechanism, the virtualization scheduling module can control the context switching delay within a preset time during each context switch, ensuring that the deadline of hard real-time tasks is predictable, and completing deterministic scheduling of clients and tasks. Furthermore, the virtualization scheduling module can communicate with the inter-core isolation module and the resource management module to obtain client priority and resource allocation information, and output scheduling instructions.

[0009] In one possible implementation of the first aspect, if the client layer includes a first client and a second client, and the hardware resources include a first core processor and a second core processor, then: when configuring memory isolation, the inter-core isolation module includes: configuring a memory protection unit partition table, setting the memory partitions of the first client, the second client, and the virtual machine monitor as independent address spaces, restricting cross-partition access, and setting an exception to trigger unauthorized access; when configuring interrupt isolation, the inter-core isolation module includes: configuring an interrupt routing table, routing the Controller Area Network interrupt and security interrupt corresponding to the first client to the first core processor, and routing the general asynchronous receiver / receiver corresponding to the second client to the first core processor. Inter-core isolation modules route interrupts and non-security interrupts to the second core processor, restricting interrupt propagation across core processors and across clients. When configuring cache isolation, the inter-core isolation module includes: enabling cache partitioning for the first and second core processors, allocating independent cache spaces for the first and second clients, and restricting cache space sharing. When configuring external device isolation, the inter-core isolation module includes: binding external devices connected to the controller LAN to the first client and external devices connected to the universal asynchronous transceiver to the second client, and configuring external device access permission registers to allow only the corresponding client to access the corresponding external device through the hypercall interface of the virtual machine monitor. Therefore, the inter-core isolation module, based on hardware memory protection units and native virtualization privilege levels, can achieve strong isolation between multi-core processors and between clients. Simultaneously, by configuring the memory protection unit partition table, the memory partitions of each client and the virtual machine monitor itself can be set as completely independent physical address spaces, prohibiting any unauthorized access across partitions. Furthermore, interrupt routing can be directed by configuring the interrupt routing table. And by enabling the core processor's cache partitioning function, independent cache space can be allocated to each client, achieving cache isolation and reducing the probability of cache side-channel leakage. Furthermore, by configuring the external device access permission register, a static binding relationship is established between the external device and the client, achieving external device isolation. Therefore, the inter-core isolation module can prevent isolation boundary penetration by configuring the memory protection unit partition table, interrupt routing table, and intercepting unauthorized access requests from the client.

[0010] In one possible implementation of the first aspect, when the inter-core isolation module isolates the hardware resources and the client according to the isolation rules, it includes: triggering memory isolation, pausing the second client, recording exception information, and notifying the exception and interrupt handling module when a second client attempts to access an external device or memory partition of the first client's connection controller LAN; triggering cache isolation and performing cache refresh when a cache conflict occurs between the first and second core processors, limiting the leakage of cached data from the client, and compensating for the delay caused by cache refresh; and triggering external device isolation when the client needs to access an external device, whereby the client initiates a resource access request to the virtual machine monitor through a hypercall interface, performs permission verification and request scope verification using the resource management module, and after successful verification, the virtual machine monitor proxies the client to access the external device and returns the access result to the client, restricting the client from directly accessing the external device. Therefore, the inter-core isolation module can communicate with the exception and interrupt handling module to handle isolation-related exceptions (such as unauthorized access, cache conflicts, etc.), ensuring the determinism and security of the system.

[0011] In one possible implementation of the first aspect, when the resource management module performs static allocation and dynamic control of hardware resources according to the pre-allocation mode and the on-demand request mode, it includes: loading the image file of each client from off-chip flash memory to its respective memory partition according to the pre-allocation mode and the on-demand request mode, and verifying the integrity of the image file; and allocating an independent context for each client, configuring the client's running permissions, and restricting the client's hardware access permissions, allowing only the corresponding client to access preset resources through the hypercall interface of the virtual machine monitor; wherein, the context includes a register set and / or stack space. Therefore, the resource management module adopts a "pre-allocation + on-demand request" mode, pre-allocating fixed memory partitions and external device resources to each client to avoid resource contention; supporting clients to dynamically request temporary resources within a preset range, with permission verification during the request process; and the resource management module can communicate with the virtualization scheduling module and the inter-core isolation module to synchronize resource allocation status, providing data support for scheduling and isolation.

[0012] In one possible implementation of the first aspect, when the exception and interruption handling module performs real-time monitoring of exceptions and interruption requests, it includes: marking unauthorized access by a client as a minor exception, suspending the operation of the corresponding client, triggering an alarm signal, recording exception information, generating and sending a warning message based on the exception information, and restoring the operation of the corresponding client after the unauthorized access exception is handled; marking client failures, instruction errors, and / or cache conflicts as serious exceptions, immediately terminating the operation of the corresponding client, initiating a fault isolation mechanism to ensure that the failure of the corresponding client does not spread to other clients and virtual machine monitors, triggering an alarm signal, recording exception information, and generating and sending a warning message based on the exception information; when an external device or client initiates an interruption request, routing the interruption request to the corresponding client according to the interruption routing table to limit cross-client interruption interference, and restoring the normal operation of the client after the interruption request is handled, compensating for the scheduling delay caused by the interruption request handling, and controlling the exception handling delay within a preset time. Therefore, it can be seen that by monitoring exceptions and interrupt requests in real time through the exception and interrupt handling module, all exceptions (such as unauthorized access, instruction errors, etc.) and interrupt requests can be handled; hierarchical routing and isolation of interrupts can be implemented based on the interrupt controller, routing interrupt requests from different clients to the corresponding clients and preventing cross-client interrupt interference; at the same time, a rapid exception response mechanism is implemented, and the exception handling delay is controlled within a specified time to ensure the stability of the operating system; moreover, the exception and interrupt handling module can communicate with the virtualization scheduling module, the inter-core isolation module, and the resource management module to provide feedback on exception information and trigger corresponding isolation or scheduling adjustment operations.

[0013] In one possible implementation of the first aspect, the hardware layer, upon startup, includes: entering the security monitoring privilege level, completing hardware resource initialization, and switching from the security monitoring privilege level to the virtualization privilege level after initialization; wherein, hardware resource initialization includes: initializing the processor core, including: configuring dual-core enable and virtualization privilege level enable for the processor, and enabling hardware virtualization extension; initializing memory, including: configuring the address mapping of on-chip random access memory, dividing the virtual machine monitor dedicated memory partition and guest memory partition, initializing through the memory protection unit, and setting the access permissions of each partition; initializing external devices and interrupts, including: initializing the interrupt controller, disabling all interrupts, and configuring interrupt priorities; and initializing external devices, setting the access permissions of external devices, and assigning external devices to corresponding guest machines. Therefore, by completing hardware resource initialization during hardware layer startup, a hardware security foundation can be laid for subsequent deterministic inter-core isolation and security monitoring.

[0014] Secondly, this application provides a communication method based on a virtual machine monitor, comprising: acquiring hardware resources, resource access requests, and task scheduling services, wherein the resource access requests and the task scheduling services are initiated by a client; based on the resource access requests and the task scheduling services, allocating, controlling, and isolating the hardware resources through the virtual machine monitor, and scheduling and isolating clients through the virtual machine monitor to restrict clients from directly accessing the hardware resources, so that the clients access the hardware resources through the virtual machine monitor.

[0015] Compared with related technologies, this communication method based on a virtual machine monitor has at least the following advantages: It enables secure interaction between the client and the virtual machine monitor without modifying the client OS kernel, supports mixed deployment of multiple types of RTOS and bare-metal tasks, and improves compatibility and deployment flexibility. Furthermore, by completely isolating clients with different security levels, this application enables mixed deployment of ASIL-D level security-critical tasks and QM level non-critical tasks on the same or multiple cores. Each client independently occupies dedicated memory, external devices, and cache resources, allowing for mutual isolation of faults. This prevents anomalies in a single client from spreading to other clients and the virtual machine monitor, thereby achieving reliable co-core operation of functions with high and low security levels and solving or mitigating the security and stability challenges of co-core deployment. Attached Figure Description

[0016] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application. It is obvious that the drawings described below are merely some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort.

[0017] Figure 1 A schematic diagram of the hardware structure of a communication system based on a virtual machine monitor provided in one embodiment of this application; Figure 2 This is a schematic diagram of the hardware structure of a virtual machine monitor layer provided in one embodiment of this application; Figure 3 A schematic diagram of the hardware structure of a communication system based on a virtual machine monitor, provided for another embodiment of this application; Figure 4 This is a flowchart illustrating a communication method based on a virtual machine monitor provided in one embodiment of this application. Detailed Implementation

[0018] The following specific examples illustrate the implementation of this application. Those skilled in the art can easily understand other advantages and effects of this application from the content disclosed in this specification. This application can also be implemented or applied through other different specific embodiments. Various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of this application. In the absence of conflict, the following embodiments and features in the embodiments can be combined with each other.

[0019] It is understood that the illustrations provided in the following embodiments are only schematic representations of the basic concept of this application. The drawings only show the components related to this application and are not drawn according to the actual number, shape and size of the components in the actual implementation. In the actual implementation, the form, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0020] In the following description, numerous details are explored to provide a more thorough explanation of embodiments of the present application. However, it will be apparent to those skilled in the art that embodiments of the present application may be practiced without these specific details. In other embodiments, well-known structures and devices are shown in block diagram form rather than in detail to avoid obscuring embodiments of the present application.

[0021] In Advanced RISC Machine architecture (ARM), privilege levels are called exception levels (EL). The Armv8 InstructionSet Architecture (Armv8) defines the following four privilege levels: EL0: No privilege level, used to run ordinary applications. It has the lowest privileges and cannot directly access hardware resources.

[0022] EL1: The operating system kernel privilege level, used to run the operating system kernel and device drivers. The kernel runs at this level and has full access to hardware resources.

[0023] EL2: Virtualization privilege level or Hypervisor level, used to run the Hypervisor (virtual machine monitor). The Hypervisor can manage multiple operating system kernels running on EL1, providing virtualization support.

[0024] EL3: Security monitoring privilege level, used to run trusted firmware or security monitoring programs. This level is typically used for security-critical tasks, providing a higher level of security.

[0025] In ARM architecture, the operating system kernel typically runs at EL1 level, while the hypervisor typically runs at EL2 level. The operating system kernel running at EL1 level has full access to hardware resources without needing any intermediate layers or interfaces. This means the operating system kernel can directly control the use and configuration of hardware resources, including the processor, memory, and devices. This direct access and visibility means the kernel can communicate directly with the hardware and perform various operations when needed, without requiring additional permissions or intermediaries.

[0026] Security interrupt: refers to the interrupt in the Secure World in the ARM architecture.

[0027] Non-secure interrupts refer to interrupts in the non-secure world of the ARM architecture.

[0028] The inventors discovered that in some embedded fields (such as automotive electronics, industrial control, and rail transportation), in order to achieve secure isolation and resource sharing of multi-core / multi-task, related technologies have proposed a variety of virtualization schemes for the Cortex-R series (processors for real-time systems). However, the virtualization schemes proposed by related technologies have some defects, such as the inability to reliably deploy security-related critical functions and non-critical functions on the same core.

[0029] Based on the above description, in an exemplary embodiment of this application, as follows: Figure 1 As shown, a communication system based on a virtual machine monitor is provided, comprising: Hardware layer 110 provides hardware resources. In some examples, the hardware resources provided by the hardware layer include, but are not limited to: a hardware MPU (Memory Protection Unit), a Cortex-R52 processor, on-chip RAM (Random Access Memory), off-chip Flash memory, a GIC-500 (Generic Interrupt Controller-500) interrupt controller, and external devices. These external devices include, but are not limited to, devices connected via UART (Universal Asynchronous Receiver / Transmitter), devices connected via CAN (Controller Area Network), and devices connected via SPI (Serial Peripheral Interface). In some examples, external devices may also be referred to simply as peripherals. In some examples, the number of cores in the Cortex-R52 processor can be configured according to actual needs, such as a single-core Cortex-R52 processor, a dual-core Cortex-R52 processor, a triple-core Cortex-R52 processor, or a quad-core Cortex-R52 processor.

[0030] The virtual machine monitor layer 120 is used to allocate, manage, and isolate hardware resources, as well as to schedule and isolate guest machines, restricting guest machines from directly accessing hardware resources; the virtual machine monitor layer includes virtual machine monitors running at the virtualization privilege level. The client layer 130 includes multiple independent clients running at the privilege level of the operating system kernel. The client layer communicates with the virtual machine monitor layer through the virtual machine monitor to initiate resource access requests and task scheduling services, and access hardware resources through the virtual machine monitor.

[0031] Therefore, this system achieves secure interaction between the guest machine and the virtual machine monitor through the virtual machine monitor, without modifying the guest operating system (OS) kernel. It supports mixed deployment of multiple types of RTOS (Real-Time Operating System) and bare-metal tasks, improving compatibility and deployment flexibility. Furthermore, this system adopts a layered, independent architecture design. The boundaries between the hardware layer, the virtual machine monitor layer, and the guest machine layer are clear and operate independently. The core modules within the virtual machine monitor layer are independently encapsulated and loosely coupled. At the same time, hierarchical interaction between the virtual machine monitor layer and the guest machine layer is achieved through hyper-call interfaces, avoiding strong coupling interference between core modules and layers. Furthermore, this system achieves complete access isolation for clients with different security levels, enabling ASIL-D (Automotive Safety Integrity Level-D) level safety-critical tasks and QM (Quality Management) level non-critical tasks to be deployed on the same core or multiple cores in a hybrid manner. Each client independently occupies dedicated memory, external devices, and cache resources, which can isolate faults from each other, ensuring that anomalies in a single client will not spread to other clients and virtual machine monitors. This achieves reliable co-core operation of functions with high and low security levels, solving or mitigating the security and stability challenges of co-core deployment.

[0032] In some exemplary embodiments, such as Figure 2 As shown, the virtual machine monitor layer 120 includes a virtualization scheduling module, an inter-core isolation module, a resource management module, and an exception and interrupt handling module. The virtualization scheduling module configures scheduling rules and schedules guest machines according to these rules; the scheduling rules include at least one of priority and time slice. The inter-core isolation module configures isolation rules and isolates hardware resources and guest machines according to these rules, restricting direct access to hardware resources by guest machines; the isolation rules include at least one of memory isolation, interrupt isolation, cache isolation, and external device isolation. The resource management module performs static allocation and dynamic management of hardware resources according to pre-allocation and on-demand request modes, and synchronizes the hardware resource allocation and management status to the virtualization scheduling module and the inter-core isolation module. The exception and interrupt handling module monitors exceptions and interrupt requests in real time; exceptions include at least one of unauthorized access, instruction errors, and cache conflicts. In some examples, such as... Figure 2 As shown, the inter-core isolation module may include a memory isolation submodule, an interrupt isolation submodule, a cache isolation submodule, and an external device isolation submodule. The memory isolation submodule is used for memory isolation configuration, the interrupt isolation submodule is used for cache isolation configuration, the cache isolation submodule is used for cache isolation configuration, and the external device isolation submodule is used for external device isolation configuration.

[0033] Therefore, this application, by abandoning the redundant and complex functional design of general-purpose hypervisors and adopting a minimized TCB (Trusted Computing Base) architecture, sets up virtualization scheduling modules, inter-core isolation modules, resource management modules, and exception and interrupt handling modules. Without redundant functional overhead, the hypervisor code size can be strictly controlled within a preset storage size (e.g., 8KB-10KB), reducing the operating overhead caused by redundant software functions from the source, greatly saving on-chip storage resources, solving the problem of the bloated size of traditional general-purpose hypervisors, and adapting to processor resource-constrained scenarios; at the same time, the streamlined architecture can also significantly reduce the system security attack surface, solving the defect of a large system security attack surface.

[0034] In some exemplary embodiments, such as Figure 2 As shown, if the scheduling rules include priority and time slices, the virtualization scheduling module, when scheduling guests, includes: starting the highest-priority guest according to a preset priority, so that the highest-priority guest runs its own task within a preset time slice; and when the highest-priority guest's task execution time reaches the preset time slice, actively triggering a context switch through the virtual machine monitor to start the remaining guests in order of priority. As an example, the virtualization scheduling module can start the first guest according to the preset priority. After the first guest starts, it runs its own task (e.g., a security-critical task) within the preset time slice, and ends when the first guest's time slice is reached. Then, the hypervisor triggers a context switch to start the second guest, and so on, starting the remaining guests in order of priority. Therefore, the virtualization scheduling module can use a hybrid scheduling mechanism of priority and time slices to start guests.

[0035] In some exemplary embodiments, such as Figure 2As shown, if the scheduling rules include priority and time slices, the virtualization scheduling module, when scheduling clients, also includes: allocating time slices to each client according to a preset scheduling period, and scheduling clients according to the preset scheduling period so that each client exclusively occupies central processing unit resources within its allocated time slice; and when a target task exists on the current client, requesting an extension of the current client's time slice through a hypercall interface, and adjusting the time slices of the current client and the next client after the virtual machine monitor verifies the time slice delay request, so that the current client can complete its target task based on the adjusted time slice, and the next client can perform basic operations based on the adjusted time slice; wherein, the preset scheduling period is the sum of the time slices allocated to all clients. Target tasks include, but are not limited to, urgent tasks, such as security alarms. In some examples, the scheduling period and the size of the preset time slice can be configured according to the actual scenario; for example, the scheduling period can be 50 microseconds to 200 microseconds, and the preset time slice can be 10 microseconds. In some examples, the virtualization scheduling module allocates time slices to each client according to a preset scheduling period (e.g., 100 microseconds) and schedules clients accordingly. Each client exclusively uses CPU resources within its own time slice. Context switching is actively triggered by the hypervisor, and the switching latency is controlled within a preset time (e.g., 10 microseconds). If the current client has an urgent task (such as a security alarm), its time slice can be extended via a hypercall request (e.g., up to 80 microseconds). After the hypervisor verifies the request, it adjusts the time slices of the current client and the next client, ensuring that the current client prioritizes the execution of urgent tasks without affecting the basic operation of the next client. Therefore, the virtualization scheduling module uses a priority-and-time-slice hybrid scheduling mechanism, which can pre-allocate fixed time slices to each client with a fixed scheduling period, eliminating the timing uncertainty caused by dynamic preemption. Simultaneously, by integrating a scheduling jitter compensation mechanism, the virtualization scheduling module can control the context switching latency within a preset time during each context switch, ensuring the predictability of hard real-time task deadlines and achieving deterministic scheduling of clients and tasks. Furthermore, the virtualization scheduling module can communicate with the inter-core isolation module and the resource management module to obtain client priority and resource allocation information, and output scheduling instructions.

[0036] In some exemplary embodiments, if the client layer includes a first client and a second client, and the hardware resources include a first core processor and a second core processor, then the inter-core isolation module, when configuring memory isolation, includes: configuring a memory protection unit partition table, setting the memory partitions of the first client, the second client, and the virtual machine monitor as independent address spaces, restricting cross-partition access, and setting an exception to trigger unauthorized access. When configuring interrupt isolation, the inter-core isolation module includes: configuring an interrupt routing table, routing the Controller Area Network interrupt and secure interrupt corresponding to the first client to the first core processor, and routing the Universal Asynchronous Receiver interrupt and non-secure interrupt corresponding to the second client to the second core processor, restricting interrupt propagation across core processors and across clients. When configuring cache isolation, the inter-core isolation module includes: enabling the cache partitioning function of the first core processor and the second core processor, allocating independent cache spaces for the first client and the second client, and restricting cache space sharing to avoid isolation leaks caused by cache contention. When configuring external device isolation, the inter-core isolation module includes: binding external devices connected to the controller LAN to the first client and external devices connected to the universal asynchronous transceiver to the second client, and configuring external device access permission registers to allow only the corresponding client to access the corresponding external device through the hypercall interface of the virtual machine monitor. Therefore, the inter-core isolation module, based on hardware memory protection units and native virtualization privilege levels, can achieve strong isolation between multi-core processors and between clients. Simultaneously, by configuring the memory protection unit partition table, the memory partitions of each client and the virtual machine monitor itself can be set as completely independent physical address spaces, prohibiting any unauthorized access across partitions. Furthermore, interrupt routing tables can be configured to achieve directed interrupt routing. By enabling the core processor's cache partitioning function, independent cache space can be allocated to each client, achieving cache isolation and reducing the probability of cache side-channel leakage. Finally, by configuring external device access permission registers, a static binding relationship is established between external devices and clients, achieving external device isolation. Therefore, by configuring memory protection unit partition tables, interrupt routing tables, and intercepting unauthorized access requests from clients, the inter-core isolation module can prevent isolation boundary penetration.

[0037] In some exemplary embodiments, when the inter-core isolation module isolates hardware resources and clients according to isolation rules, it includes: triggering memory isolation when a second client attempts to access an external device or memory partition of the first client's connection controller LAN, suspending the second client's operation, recording exception information, and notifying the exception and interrupt handling module. When a cache conflict occurs between the first and second core processors, cache isolation is triggered, and a cache refresh is performed to limit the leakage of cached data from the client and compensate for the latency caused by the cache refresh, ensuring scheduling determinism. When a client needs to access an external device, external device isolation is triggered. The client initiates a resource access request to the virtual machine monitor through a hypercall interface. The resource management module performs permission verification and request scope verification. After successful verification, the virtual machine monitor proxies the client to access the external device and returns the access result to the client, restricting the client from directly accessing the external device. In some examples, such as when a client needs to temporarily use additional memory (e.g., for data caching), it can initiate a resource request to the Hypervisor via a hypercall interface. After the resource management module verifies permissions and the request range (e.g., not exceeding a preset limit of 16KB), it temporarily allocates memory and reclaims it after use, ensuring efficient resource utilization without affecting other clients. Therefore, the inter-core isolation module can communicate with the exception and interrupt handling module to handle isolation-related exceptions (such as unauthorized access, cache conflicts, etc.), ensuring the determinism and security of the system.

[0038] In some exemplary embodiments, when the resource management module performs static allocation and dynamic control of hardware resources according to the pre-allocation mode and the on-demand request mode, it includes: loading the image file of each client from off-chip flash memory to its respective memory partition according to the pre-allocation mode and the on-demand request mode, and verifying the integrity of the image file to prevent the image from being tampered with. It also includes allocating an independent context for each client, configuring the client's running permissions (e.g., EL1 level), and restricting the client's hardware access permissions, allowing only the corresponding client to access preset resources through the hypercall interface of the virtual machine monitor; wherein, the context includes register groups and / or stack space. Therefore, the resource management module adopts the "pre-allocation + on-demand request" mode, pre-allocating fixed memory partitions and external device resources to each client to avoid resource contention; supporting clients to dynamically request temporary resources within a preset range, with permission verification during the request process; and the resource management module can communicate with the virtualization scheduling module and the inter-core isolation module to synchronize resource allocation status, providing data support for scheduling and isolation.

[0039] In some exemplary embodiments, when the exception and interruption handling module performs real-time monitoring of exceptions and interruption requests, it includes: marking unauthorized access by a client as a minor exception, suspending the operation of the corresponding client, triggering an alarm signal, recording exception information (e.g., exception type, occurrence address, client serial number, etc.), generating and sending a warning message based on the exception information, and restoring the operation of the corresponding client after the unauthorized access exception is handled. It also marks client failures, instruction errors, and / or cache conflicts as serious exceptions, immediately terminating the operation of the corresponding client, initiating a fault isolation mechanism to ensure that the failure of the corresponding client does not spread to other clients or the virtual machine monitor, triggering an alarm signal, recording exception information, and generating and sending a warning message based on the exception information. When an external device or client initiates an interruption request, it routes the interruption request to the corresponding client according to the interruption routing table, limiting cross-client interruption interference, and restoring the normal operation of the client after the interruption request is handled, compensating for the scheduling delay caused by the interruption request handling, and controlling the exception handling delay within a preset time. In some examples, the real-time monitoring of exceptions and interruption requests by the exception and interruption handling module can be divided into three parts: exception capture, exception handling, and interrupt handling. In this process, exception capture occurs when exceptions such as unauthorized access, instruction errors, or cache conflicts occur. The Cortex-R52 processor triggers an exception interrupt, switches to EL2 level, captures the exception, and records information such as the exception type, the address where it occurred, and the client serial number. Therefore, by monitoring exceptions and interrupt requests in real time through the exception and interrupt handling module, all exceptions (such as unauthorized access and instruction errors) and interrupt requests can be handled. It can also implement hierarchical routing and isolation of interrupts based on the interrupt controller, routing interrupt requests from different clients to their corresponding clients and preventing cross-client interrupt interference. Simultaneously, it implements a rapid exception response mechanism, controlling exception handling delays within a specified time to ensure operating system stability. Furthermore, the exception and interrupt handling module can communicate with the virtualization scheduling module, inter-core isolation module, and resource management module to provide feedback on exception information and trigger corresponding isolation or scheduling adjustment operations.

[0040] In some exemplary embodiments, the hardware layer, upon startup, includes: entering the security monitoring privilege level, completing hardware resource initialization, and switching from the security monitoring privilege level (EL3 level) to the virtualization privilege level (EL2 level) after initialization. Hardware resource initialization includes: Initializing the processor core includes configuring dual-core enabling, virtualization privilege level enabling, and enabling hardware virtualization extensions. In some examples, dual-core enabling and EL2 level enabling of the Cortex-R52 processor can be configured, and hardware virtualization extensions can be enabled (e.g., configuring the HCR_EL2 register to enable permission isolation between EL1 and EL2). The HCR_EL2 register is a key system register in the Armv8 architecture used to control virtualization behavior. As the main control interface of the Hypervisor, it defines the monitoring policy of EL2 for low-privilege-level (i.e., EL1 and EL0) execution environments.

[0041] Memory initialization includes: configuring the address mapping of on-chip random access memory, partitioning the virtual machine monitor's dedicated memory partition and the guest memory partition (e.g., the first guest partition), initializing through the memory protection unit, and setting access permissions for each partition. In some examples, the hypervisor's dedicated memory partition can be allocated as 8KB to store hypervisor code and runtime data. In some examples, the first guest's memory partition can be allocated as 64KB, and the second guest's memory partition as 32KB. In some examples, access permissions can be set so that only the hypervisor can access all partitions, and guests can only access their own partitions.

[0042] Initializing external devices and interrupts includes: initializing the interrupt controller, disabling all interrupts, and configuring interrupt priorities; and initializing external devices, setting access permissions for external devices, and assigning external devices to their corresponding client machines. In some examples, the interrupt controller can be a GIC-500 interrupt controller, and the external devices can include external devices connected via UART (UART peripherals), external devices connected via CAN (CAN peripherals), external devices connected via SPI (SPI peripherals), etc. In some examples, when assigning external devices to their corresponding client machines, a CAN peripheral can be assigned to the first client machine, giving it exclusive access; a UART peripheral can be assigned to the second client machine, giving it exclusive access.

[0043] Therefore, by initializing hardware resources during hardware layer startup, a hardware security foundation can be laid for subsequent deterministic inter-core isolation and security monitoring.

[0044] The inventors also discovered that, in order to achieve secure isolation and resource sharing of multi-core or multi-task systems in safety-critical embedded fields such as automotive electronics, industrial control, and rail transportation, related technologies have proposed various virtualization schemes for the Cortex-R series (processors for real-time systems), mainly divided into three categories: (1) General-purpose server-type hypervisors, such as Xen, KVM-ARM, etc.; Xen is a semi-virtualized VMM (Virtual Machine Monitor); KVM-ARM refers to the implementation of a kernel-based virtual machine (KVM) on an ARM architecture processor.

[0045] (2) Traditional embedded hypervisors, such as Xvisor, OpenSynergy, L4Re, etc.; Xvisor is a completely open source, lightweight virtual machine monitor, OpenSynergy is a virtual machine monitor for the automotive field, and L4Re is an open source, microkernel-based operating system framework and virtualization platform.

[0046] (3) Static partitioning or inter-core isolation schemes without Hypervisor.

[0047] The Cortex-R52 multi-core processor, as the first real-time processor to natively support Armv8 R virtualization extensions, features EL2 (Exception Level 2) virtualization privilege level, hardware MPU (Memory Protection Unit), Lockstep safety mechanism, and low-latency interrupt handling capabilities. It is widely used in ASIL D (Automotive Safety Integrity Level-D) automotive-grade controllers and high-reliability industrial MCUs (Microcontroller Units). However, existing solutions have significant shortcomings in four core dimensions: Cortex-R52 resource constraints, hard real-time determinism, lightweight design, and strong inter-core isolation. For example: (1) General-purpose hypervisors (such as Xen, KVM-ARM, etc.) have problems such as bulky size, poor real-time performance, and large security attack surface; (2) Traditional embedded hypervisors (such as Xvisor, OpenSynergy, L4Re, etc.) have problems such as incomplete isolation, insufficient determinism, and high coupling; (3) Static partitioning or inter-core isolation solutions without hypervisors have problems such as lack of virtualization abstraction, static isolation, and rigid scheduling. This results in the inability to reliably deploy security-critical and non-critical functions on the same core, difficulty in guaranteeing determinism during mixed operation of multiple operating systems, and an inability of the operating system size and resource overhead to adapt to the embedded scenarios of Cortex-R52.

[0048] Based on the above description, in another exemplary embodiment of this application, a communication system based on a virtual machine monitor is provided, including: a hardware layer, a hypervisor layer, and a client layer, such as... Figure 3 As shown.

[0049] Hardware Layer: The core is a Cortex-R52 multi-core processor (supporting 1-4 cores; this embodiment uses a dual-core configuration). The hardware layer integrates native EL2 virtualization privilege level, hardware MPU (Memory Protection Unit), GIC-500 (Generic Interrupt Controller-500) interrupt controller, on-chip RAM (256KB-1MB), off-chip Flash memory, and peripherals (such as UART, CAN, and SPI peripherals). The hardware layer provides the runtime environment for the entire system, achieving permission isolation between the Hypervisor and the client through the EL2 level, physical memory isolation through the MPU, and interrupt routing and isolation through the GIC-500.

[0050] The Hypervisor layer employs a minimal TCB (Trusted Computing Base) design, with a code size kept under 10KB. It contains only four core modules: virtualization scheduling, inter-core isolation, resource management, and exception and interrupt handling. There are no redundant functions; each module is independently encapsulated and loosely coupled. Running at EL2 level, the Hypervisor layer is the only layer in the system with hardware access permissions. It is responsible for guest machine startup, scheduling, resource allocation, and inter-core isolation arbitration, prohibiting guests from directly accessing hardware resources.

[0051] The client layer comprises multiple independent clients, supporting hybrid deployments of RTOS (such as FreeRTOS, Autosar OS, and bare-metal tasks). Each client corresponds to a security level (e.g., ASIL-D for safety-critical tasks, QM for non-critical tasks). Each client runs at EL1 level and obtains hardware resource access permissions through the hypercall interface provided by the hypervisor. They are completely isolated from each other; a failure in a single client will not affect the operation of other clients or the hypervisor itself. The hypercall interface of the hypervisor can cover functions such as resource allocation, interrupt requests, and task scheduling, and can have up to eight interfaces.

[0052] The client layer communicates with the Hypervisor layer through the Hypercall interface to request services such as resource access and task scheduling; the Hypervisor layer communicates with the hardware layer through hardware virtualization interfaces (such as EL2 instructions, MPU configuration interfaces, and GIC configuration interfaces) to achieve control and isolation of hardware resources; the hardware layer communicates with the Hypervisor layer through interrupt signals and status feedback to ensure that the Hypervisor responds to system anomalies in real time.

[0053] In some examples, the virtualization scheduling module is responsible for deterministic scheduling of clients and tasks. It adopts a hybrid scheduling mechanism of "static priority + fixed time slice", pre-allocating a fixed time slice (microsecond level, customizable) to each client. The scheduling cycle is fixed and there is no preemption uncertainty. At the same time, it integrates a scheduling jitter compensation mechanism to control the context switching latency to within 10 microseconds, ensuring that the deadline of hard real-time tasks is predictable. The virtualization scheduling module communicates with the inter-core isolation module and the resource management module to obtain client priority and resource allocation information and output scheduling instructions.

[0054] Inter-core isolation module: Based on the Cortex-R52 hardware MPU and EL2 level, it achieves strong isolation between multiple cores and between guest cores. Specifically, it includes four sub-modules: memory isolation, interrupt isolation, cache isolation, and peripheral isolation. The inter-core isolation module receives resource allocation information from the resource management module, configures MPU partitions and GIC interrupt routing tables, intercepts unauthorized access requests from guest cores to prevent isolation boundary penetration, and communicates with the exception and interrupt handling module to handle isolation-related exceptions (such as unauthorized access and cache conflicts).

[0055] The resource management module is responsible for the static allocation and dynamic control of resources (such as memory, peripherals, and interrupts). It adopts a "pre-allocation + on-demand request" model, pre-allocating fixed memory partitions and peripheral resources to each client machine to avoid resource contention. It also supports clients dynamically requesting temporary resources within a preset range, with the request process verified by the Hypervisor's permissions. The resource management module communicates with the virtualization scheduling module and the inter-core isolation module to synchronize resource allocation status, providing data support for scheduling and isolation.

[0056] The exception and interrupt handling module is responsible for handling all system exceptions (such as unauthorized access, instruction errors, etc.) and interrupt requests. Based on the GIC-500 interrupt controller, it implements hierarchical routing and isolation of interrupts, routing interrupt requests from different clients to their corresponding clients and preventing cross-client interrupt interference. It also implements a fast exception response mechanism, controlling exception handling latency to within 5 microseconds to ensure system stability. The exception and interrupt handling module communicates with the other three core modules, feeding back exception information and triggering corresponding isolation or scheduling adjustment operations.

[0057] In one specific embodiment, a communication system based on a virtual machine monitor is provided for safety-critical embedded applications such as automotive electronics, industrial control, and rail transportation. Specifically, the communication system includes a dual-core Cortex-R52 processor, comprising core processor 0 and core processor 1. Two guest computers are also deployed, denoted as Guest1 and Guest2. Guest1 is used for ASIL-D level safety-critical tasks, running Autosar OS; Guest2 is used for QM level non-critical tasks, running FreeRTOS. The hypervisor's code size is 8KB and it runs at EL2 level.

[0058] (a) Perform system initialization.

[0059] After power-on, the Cortex-R52 dual-core processor executes the reset process, enters EL3 level (security monitoring privilege level), and completes hardware initialization. The specific steps include: (1) Initializing the processor core: configuring the dual-core enable of Cortex-R52, enabling EL2 level, and enabling hardware virtualization extension (HCR_EL2 register configuration, enabling permission isolation between EL1 and EL2). (2) Initializing memory: configuring the address mapping of on-chip RAM, dividing the Hypervisor-specific memory partition and the guest memory partition. As an example, the Hypervisor-specific memory partition can be 8KB, used to store Hypervisor code and running data, the Guest1 memory partition can be 64KB, and the Guest2 memory partition can be 32KB. Then, through MPU initialization, the access permissions of each partition are set, for example, only the Hypervisor can access all partitions, and the guest can only access its own partition. (3) Initialize peripherals and interrupts: Initialize the GIC-500 interrupt controller, disable all interrupts, and configure interrupt priorities; initialize UART peripherals, CAN peripherals, etc., set access permissions for peripherals, and allocate peripheral resources to the corresponding clients (e.g., Guest1 exclusively uses the CAN peripheral, and Guest2 exclusively uses the UART peripheral). After hardware initialization is completed, the Cortex-R52 dual-core processor switches from EL3 level to EL2 level, loads the Hypervisor code, and enters the Hypervisor initialization phase.

[0060] (ii) Hypervisor initialization.

[0061] After the Hypervisor code is loaded, the Hypervisor initialization process is executed, configuring the core modules and establishing isolation rules. The specific steps include: Module initialization: The virtualization scheduling module, inter-core isolation module, resource management module, and exception and interrupt handling module are initialized in sequence. Each module loads preset configuration parameters (such as scheduling cycle, isolation rules, and resource allocation table).

[0062] Scheduling rule configuration: Set the scheduling period to 100 microseconds through the virtualization scheduling module, allocate a 60-microsecond time slice to Guest1 (corresponding to a safety-critical task with the highest priority), allocate a 40-microsecond time slice to Guest2 (with the next highest priority), disable dynamic priority adjustment, and enable the scheduling jitter compensation mechanism to compensate for context switching latency by adjusting the time slice offset.

[0063] Isolation rule configuration: Four isolation configurations are completed through the inter-core isolation module. Specifically, they include: (1) Memory isolation: Configure the MPU partition table, set the memory partitions of Guest1, Guest2 and Hypervisor as independent address spaces, prohibit cross-partition access, and set unauthorized access to trigger exceptions; (2) Interrupt isolation: Configure the GIC-500 interrupt routing table, route the CAN peripheral interrupt and security interrupt corresponding to Guest1 to core processor 0, and route the UART peripheral interrupt and non-security interrupt corresponding to Guest2 to core processor 1, prohibiting interrupts from propagating across cores and across clients; (3) Cache isolation: Enable the cache partitioning function of the Cortex-R52 dual-core processor, allocate an independent cache space for each client, prohibit cache sharing, and avoid isolation leakage caused by cache contention; (4) Peripheral isolation: Bind the CAN peripheral to Guest1 and the UART peripheral to Guest2 through the resource management module, configure the peripheral access permission register, and only allow the corresponding client to access the peripheral through Hypervisor hypercall.

[0064] Hypercall interface initialization: Register the Hypervisor's hypercall interfaces (a total of 8, covering functions such as resource request, interruption request, task scheduling, etc.), set hypercall permission verification rules, and ensure that only legitimate clients can initiate hypercalls.

[0065] (iii) Client startup.

[0066] After the Hypervisor is initialized, the guest machine is started, loaded into the preset memory partition, and switched to EL1 level for operation. The specific steps include: (1) Loading guest machine images: The image files of Guest1 and Guest2 are loaded from the off-chip Flash to their respective memory partitions through the resource management module, the integrity of the images is verified, and the images are prevented from being tampered with; (2) Guest machine context initialization: Each guest machine is allocated an independent context (e.g., register group, stack space, etc.), the running permissions of the guest machine are configured (e.g., EL1 level), the hardware access permissions of the guest machine are restricted, and the preset resources are only allowed to be accessed through hypercall; (3) Starting the guest machine: According to the preset priority, the virtualization scheduling module starts Guest1 (safety-critical task) first. After Guest1 is started, it runs its own task within the preset time slice; when Guest1 reaches the preset time slice, it ends, the Hypervisor actively triggers the context switch, starts Guest2, and so on.

[0067] (iv) Real-time operation of deterministic scheduling and inter-core isolation.

[0068] After the client machine starts up, the Hypervisor continuously performs scheduling and isolation management to ensure the determinism and security of the system. The specific operation process is as follows: Deterministic scheduling execution: The virtualization scheduling module executes scheduling according to the scheduling cycle (100 microseconds). Each guest exclusively occupies CPU resources within its own time slice. Context switching is actively triggered by the Hypervisor, and the switching latency is controlled within 10 microseconds. If Guest1 has an urgent task (such as a security alarm), the time slice can be extended through a hypercall request (for example, extended to a maximum of 80 microseconds). After the Hypervisor verifies and approves the request, the time slice is adjusted to ensure that the urgent task is executed first without affecting the basic operation of Guest2.

[0069] Inter-core isolation control: The inter-core isolation module monitors the running status of the client in real time and intercepts unauthorized access requests, including: (1) If Guest2 attempts to access Guest1's CAN peripheral or memory partition, the inter-core isolation module immediately triggers an isolation exception, suspends the operation of Guest2, records the exception information, and notifies the exception and interrupt handling module; (2) If a cache conflict occurs between core processor 0 and core processor 1, a cache refresh is immediately triggered to ensure that the cache data of each client is not leaked, while compensating for the delay caused by the cache refresh and ensuring scheduling determinism; (3) Peripheral access control: When a client needs to access a peripheral, it sends a request to the Hypervisor through a hypercall. After the resource management module verifies the permissions, the Hypervisor proxies the access to the peripheral and returns the access result, prohibiting the client from directly accessing the peripheral hardware.

[0070] Dynamic resource adjustment: If Guest2 needs to temporarily use additional memory (such as data caching), it can send a resource request to the Hypervisor through the hypercall interface. After the resource management module verifies the request range (e.g., not exceeding the preset upper limit of 16KB), it will temporarily allocate memory and reclaim it after the memory is used up, ensuring efficient resource utilization and not affecting other clients.

[0071] (v) Abnormal handling.

[0072] During system operation, the exception and interrupt handling module monitors exceptions and interruptions in real time, responds quickly, and handles them to ensure system stability and isolation. Specific steps include: Exception capture: When exceptions such as unauthorized access, instruction errors, or cache conflicts occur, the Cortex-R52 dual-core processor triggers an exception interrupt, switches to EL2 level, and the exception and interrupt handling module captures the exception and records information such as the exception type, the address where it occurred, and the client serial number.

[0073] Exception handling: Execute the corresponding processing logic according to the exception type, including: (1) Minor exceptions (such as Guest2 temporary unauthorized access, etc.): Suspend the operation of the corresponding client, send a warning message, and resume the operation of the client after processing; (2) Serious exceptions (such as Guest1 failure, isolation boundary penetration, etc.): Immediately terminate the operation of the corresponding client, start the fault isolation mechanism to ensure that the fault does not spread to other clients and Hypervisor, and trigger an alarm signal to notify external monitoring equipment.

[0074] Interrupt handling: When a peripheral device or client initiates an interrupt request, the GIC-500 interrupt controller routes the interrupt signal to the exception and interrupt handling module. The exception and interrupt handling module forwards the interrupt to the corresponding client according to the interrupt routing table, prohibiting cross-client interrupt interference. After the interrupt handling is completed, the client is restored to normal operation, and the scheduling delay caused by the interrupt handling is compensated to ensure scheduling determinism.

[0075] In a specific example, the virtual machine monitor-based communication system described in the above embodiments can be subjected to lightweight verification, deterministic verification, isolation verification, and resource overhead verification. For example, lightweight verification: the Hypervisor code size of this application is 8KB, and it occupies 16KB of on-chip RAM (including runtime data), which is far lower than existing embedded Hypervisors (typically tens to hundreds of KB), fully adapting to the resource-constrained scenarios of Cortex-R52. Deterministic verification: the scheduling cycle of this application is 100 microseconds, the context switching latency is 7 to 9 microseconds, the scheduling jitter is less than or equal to 1 microsecond, and the deadline fulfillment rate of Guest1's safety-critical tasks can reach 100%, which is better than some existing solutions with jitter typically greater than or equal to 10 microseconds. Isolation verification: through unauthorized access testing, Guest2 cannot access Guest1's memory and peripherals, interrupts cannot propagate across clients, there is no cache leak, and the ASIL-D level isolation requirements are met. Resource overhead verification: The Hypervisor's runtime CPU utilization is less than or equal to 5%, and its memory utilization is less than or equal to 3.2%, which is far lower than some existing solutions where the CPU utilization is usually greater than or equal to 10%, and does not affect the normal operation of client tasks.

[0076] In summary, this application provides a communication system based on a virtual machine monitor (VM monitor). This system enables secure interaction between the client and VM monitor without modifying the client OS kernel. It supports mixed deployment of various RTOS types and bare-metal tasks, improving compatibility and deployment flexibility. Furthermore, the system adopts a layered, independent architecture design. The boundaries between the hardware layer, VM monitor layer, and client layer are clear and operate independently. Core modules within the VM monitor layer are independently encapsulated and loosely coupled. Hyper-call interfaces facilitate hierarchical interaction between the VM monitor layer and the client layer, avoiding strong coupling interference between core modules and layers. Moreover, by completely isolating clients with different security levels, the system enables mixed deployment of ASIL-D level security-critical tasks and QM level non-critical tasks on the same or multiple cores. Each client independently occupies dedicated memory, external devices, and cache resources, allowing for mutual isolation of faults. This prevents anomalies in a single client from propagating to other clients and the VM monitor, thus achieving reliable co-core operation of functions with high and low security levels and solving or mitigating the security and stability challenges of co-core deployment.

[0077] Meanwhile, addressing the shortcomings of general-purpose hypervisors (Xen / KVM) such as bloated size, poor real-time performance, and large security surface, this application abandons the redundant and complex functional design of general-purpose hypervisors. It adopts a minimized TCB trusted computing architecture, retaining only four core essential modules: virtualization scheduling, inter-core isolation, resource management, and exception and interrupt handling. With no unnecessary functional overhead, the hypervisor code size is strictly controlled to within 10KB, thus solving or mitigating the problem of bloated size in traditional general-purpose hypervisors. Furthermore, the streamlined architecture significantly reduces the system's security attack surface, addressing its large security surface deficiency. Moreover, by abandoning the uncertain mechanisms of dynamic preemption and adaptive scheduling found in general-purpose hypervisors, a hybrid scheduling mechanism of priority and time slices is introduced, coupled with a scheduling jitter compensation mechanism. This controls the context switching latency to within 10 microseconds, allowing system scheduling jitter to be less than or equal to 1 microsecond, achieving microsecond-level hard real-time scheduling and solving or mitigating the core problem of poor real-time performance in general-purpose hypervisors.

[0078] Furthermore, addressing the issue of incomplete isolation in embedded hypervisors, this application constructs a comprehensive, four-dimensional hard isolation system encompassing memory, interrupts, cache, and peripherals, based on the Cortex-R52 hardware MPU, EL2 level, and GIC-500 controller. This system can intercept unauthorized access by clients, prevent cross-core interrupt interference, and prevent cache data leakage, achieving complete inter-core and client isolation, meeting ASIL-D high security requirements, and resolving the vulnerabilities of incomplete isolation in traditional embedded hypervisors. Regarding the issue of insufficient determinism in embedded hypervisors, this application employs deterministic scheduling logic based on scheduling cycles and time slice allocation, coupled with an exception delay compensation mechanism. The execution sequence and switching timing of all tasks can be accurately predicted, ensuring determinism throughout system operation. Regarding the issue of high coupling in embedded hypervisors, this application adopts a layered, independent architecture design. The boundaries between the hardware layer, hypervisor layer, and client layer are clear, and they operate independently. Simultaneously, the four core modules within the hypervisor are independently encapsulated and loosely coupled, enabling layered interaction through standardized hypercall interfaces, avoiding strong coupling interference between modules and layers.

[0079] Furthermore, addressing the lack of virtualization abstraction in static partitioning or hypervisor-less solutions, this application constructs a complete virtualization system based on the native EL2 virtualization extension of Cortex-R52. Using an EL2-level hypervisor as the core for unified hardware resource management, it provides standardized virtualization abstraction capabilities for upper-layer multi-guest and multi-OS environments, supporting hybrid deployment of RTOS and bare-metal tasks, thus overcoming the shortcomings of hypervisor-less solutions in terms of virtualization capabilities. Regarding the issue of static isolation in static partitioning or hypervisor-less solutions, this application breaks through the rigid limitations of pure static partitioning, adopting a pre-allocation and on-demand resource management model. Based on fixed security isolation boundaries, it supports clients dynamically requesting temporary resources within preset permission ranges, balancing isolation security with resource allocation flexibility. To address the rigid scheduling issues in static partitioning or hypervisor-free solutions, this solution abandons the fixed scheduling logic of static partitioning and supports priority configuration based on task safety levels and dynamic fine-tuning of time slices (time slices for urgent tasks can be extended as needed). It is also compatible with hardware configurations of various Cortex-R52 processors, including single-core and multi-core processors, and supports flexible deployment of up to 8 clients, thus solving the problems of rigid scheduling modes and poor adaptability in traditional solutions.

[0080] Therefore, this application relies on a multi-dimensional hard-core isolation mechanism to achieve complete permission isolation for clients with different security levels, enabling ASIL-D level security-critical tasks and QM level non-critical tasks to be deployed on the same core or in a multi-core hybrid configuration. Each client independently occupies dedicated memory, peripherals, and cache resources, and faults are isolated from each other. An anomaly in a single client will not propagate to other tasks or the core hypervisor, achieving reliable co-core operation of functions with high and low security levels. This solves or alleviates the security and stability problems of co-core deployment and overcomes the pain point that security-critical and non-critical functions cannot be reliably deployed on the same core. At the same time, this application is based on a dedicated deterministic scheduling architecture to uniformly manage the runtime sequence of multiple types of OS (such as Autosar OS, FreeRTOS, etc.) and bare-metal tasks. Through multiple mechanisms such as a fixed 100-microsecond scheduling cycle, fine-grained time slice allocation, scheduling jitter compensation, and interrupt latency compensation, the overall system scheduling jitter is controlled at the 1-microsecond level, and the deadline fulfillment rate of security-critical tasks is 100%. This makes the execution sequence of multi-OS hybrid operation completely predictable and controllable, ensuring hard real-time determinism and solving the problem of difficulty in guaranteeing determinism in multi-OS hybrid operation. Furthermore, this application achieves ultra-lightweight deployment at the KB level through a minimal architecture design. The hypervisor code size is only 8KB, the on-chip RAM usage is 16KB, and the runtime CPU utilization is less than or equal to 5%, and the memory utilization is less than or equal to 3.2%, with resource overhead far lower than existing solutions. Moreover, the extremely streamlined resource consumption is perfectly suited to embedded scenarios with limited on-chip RAM and computing resources in the Cortex-R52 processor. Simultaneously, the low-overhead design does not affect the normal operation of upper-layer business tasks, making it suitable for lightweight embedded applications such as automotive electronics and industrial control. This solves the problem that related technologies cannot be adapted to embedded scenarios using the Cortex-R52 processor due to their size and resource overhead. Therefore, this application addresses the shortcomings of existing Hypervisor and inter-core isolation solutions on the Cortex-R52 platform by synergistically improving "lightweight Hypervisor architecture design + deterministic scheduling mechanism + strong inter-core isolation strategy," achieving significant improvements in lightweight design, real-time performance, security, compatibility, and resource utilization. It enables ultra-lightweight deployment of the Hypervisor, adapting to Cortex-R52 resource-constrained scenarios; achieves microsecond-level deterministic scheduling, meeting the hard real-time requirements of safety-critical scenarios; achieves strong inter-core isolation, meeting high security level requirements and improving system security and fault tolerance; enhances compatibility and deployment flexibility, reducing development and porting costs; and optimizes resource utilization, reducing hardware and operation and maintenance costs.

[0081] In another exemplary embodiment of this application, such as Figure 4 As shown, a communication method based on a virtual machine monitor is provided, which can be applied to the communication system described in some of the above embodiments. The communication method includes the following steps: S410 acquires hardware resources, resource access requests, and task scheduling services, wherein the resource access requests and task scheduling services are initiated by the client. The S420, based on resource access requests and task scheduling services, allocates, manages, and isolates hardware resources through the virtual machine monitor, and schedules and isolates clients through the virtual machine monitor to restrict clients from directly accessing hardware resources, allowing clients to access hardware resources through the virtual machine monitor.

[0082] It is understood that the communication system based on a virtual machine monitor provided in the above embodiments and the communication method based on a virtual machine monitor provided in this embodiment belong to the same concept. The specific way in which the communication system based on a virtual machine monitor performs operations has been described in detail in some of the above embodiments, and will not be repeated here. In practical applications, the communication method based on a virtual machine monitor provided in this embodiment can, as needed, assign some of the above steps to different levels or functional modules in the communication system based on a virtual machine monitor, that is, divide the communication method based on a virtual machine monitor into different steps, and then complete the corresponding steps through the communication system based on a virtual machine monitor described in some of the above embodiments. No specific limitations are imposed here.

[0083] In summary, this application provides a communication method based on a virtual machine monitor (VM monitor). This method enables secure interaction between the client machine and the VM monitor without modifying the client OS kernel. It supports mixed deployment of multiple types of RTOS and bare-metal tasks, improving compatibility and deployment flexibility. Furthermore, by providing complete permission isolation for clients with different security levels, this application enables mixed deployment of ASIL-D level security-critical tasks and QM level non-critical tasks on the same or multiple cores. Each client machine independently occupies dedicated memory, external devices, and cache resources, allowing for mutual isolation of faults. This prevents anomalies in a single client from propagating to other clients and the VM monitor, thereby achieving reliable co-core operation of functions with high and low security levels and solving or mitigating the security and stability challenges of co-core deployment.

[0084] The above embodiments are merely illustrative of the principles and effects of this application and are not intended to limit this application. Any person skilled in the art can modify or alter the above embodiments without departing from the spirit and scope of this application. Therefore, all equivalent modifications or alterations made by those skilled in the art without departing from the spirit and technical concept disclosed in this application should still be covered by the claims of this application.

Claims

1. A communication system based on a virtual machine monitor, characterized in that, The system includes: The hardware layer is used to provide hardware resources; The virtual machine monitor layer is used to allocate, manage, and isolate the hardware resources, as well as to schedule and isolate guest machines, restricting guest machines from directly accessing the hardware resources; wherein, the virtual machine monitor layer includes a virtual machine monitor running at the virtualization privilege level; The client layer includes multiple independent clients running at the privilege level of the operating system kernel. The client layer communicates with the virtual machine monitor layer through the virtual machine monitor to initiate resource access requests and task scheduling services, and access the hardware resources through the virtual machine monitor.

2. The communication system based on a virtual machine monitor according to claim 1, characterized in that, The virtual machine monitor layer includes a virtualization scheduling module, an inter-core isolation module, a resource management module, and an exception and interrupt handling module; The virtualization scheduling module is used to configure scheduling rules and perform client scheduling according to the scheduling rules; wherein, the scheduling rules include at least one of priority and time slice; The inter-core isolation module is used to configure isolation rules and isolate the hardware resources and the client according to the isolation rules, restricting the client from directly accessing the hardware resources; wherein, the isolation rules include at least one of memory isolation, interrupt isolation, cache isolation and external device isolation; The resource management module is used to perform static allocation and dynamic control of hardware resources according to the pre-allocation mode and the on-demand application mode, and to synchronize the hardware resource allocation and control status to the virtualization scheduling module and the inter-core isolation module. The exception and interruption handling module is used to monitor exception and interruption requests in real time; wherein the exception includes at least one of unauthorized access, instruction error and cache conflict.

3. The communication system based on a virtual machine monitor according to claim 2, characterized in that, If the scheduling rules include priority and time slice, then when the virtualization scheduling module performs guest scheduling, it includes: starting the highest priority guest according to the preset priority so that the highest priority guest runs its own task within the preset time slice, and when the task running time of the highest priority guest reaches the preset time slice, actively triggering a context switch through the virtual machine monitor and starting the remaining guests in order of priority.

4. The communication system based on a virtual machine monitor according to claim 2 or 3, characterized in that, If the scheduling rules include priority and time slices, the virtualization scheduling module, when scheduling clients, further includes: allocating time slices to each client according to a preset scheduling period, and scheduling clients according to the preset scheduling period, so that each client exclusively occupies central processing unit resources within the allocated time slice; and when the current client has a target task, requesting to extend the current client's time slice through the hypercall interface, and after the virtual machine monitor verifies the time slice delay request, adjusting the time slices of the current client and the next client, so that the current client can complete the target task based on the adjusted time slice, and the next client can perform basic operations based on the adjusted time slice; wherein, the preset scheduling period is the sum of the time slices allocated to all clients.

5. The communication system based on a virtual machine monitor according to claim 2, characterized in that, If the client layer includes a first client and a second client, and the hardware resources include a first core processor and a second core processor, then: When configuring memory isolation, the inter-core isolation module includes: configuring a memory protection unit partition table, setting the memory partitions of the first client, the second client, and the virtual machine monitor as independent address spaces, restricting cross-partition access, and setting an exception to trigger unauthorized access. When configuring interrupt isolation, the inter-core isolation module includes: configuring an interrupt routing table and routing the Controller Area Network interrupt and secure interrupt corresponding to the first client to the first core processor, and routing the Universal Asynchronous Receiver interrupt and non-secure interrupt corresponding to the second client to the second core processor, thereby restricting interrupt propagation across core processors and across clients; When configuring cache isolation, the inter-core isolation module includes: enabling the cache partitioning function of the first core processor and the second core processor, allocating independent cache spaces for the first client and the second client, and restricting cache space sharing; When configuring external device isolation, the inter-core isolation module includes: binding external devices connected to the controller LAN to a first client, binding external devices connected to the universal asynchronous transceiver to a second client, and configuring an external device access permission register to only allow the corresponding client to access the corresponding external device through the hypercall interface of the virtual machine monitor.

6. The communication system based on a virtual machine monitor according to claim 5, characterized in that, When the inter-core isolation module isolates the hardware resources and the client according to the isolation rules, it includes: When the second client attempts to access the external device or memory partition of the first client's connection controller LAN, memory isolation is triggered, the second client is suspended, exception information is recorded, and the exception and interrupt handling module is notified. When a cache conflict occurs between the first and second core processors, cache isolation is triggered and a cache refresh is performed to limit the leakage of cached data in the client and to compensate for the latency caused by the cache refresh. When a client needs to access an external device, external device isolation is triggered. The client initiates a resource access request to the virtual machine monitor through the hypercall interface. The resource management module performs permission verification and request scope verification. After the verification is successful, the virtual machine monitor proxies the client to access the external device and returns the access result to the client, thus restricting the client from directly accessing the external device.

7. The communication system based on a virtual machine monitor according to claim 2, characterized in that, When the resource management module performs static allocation and dynamic control of hardware resources according to the pre-allocation mode and the on-demand application mode, it includes: loading the image file of each client from off-chip flash memory to its respective memory partition according to the pre-allocation mode and the on-demand application mode, and verifying the integrity of the image file; and allocating an independent context for each client, configuring the client's running permissions, and restricting the client's hardware access permissions, allowing only the corresponding client to access preset resources through the hypercall interface of the virtual machine monitor; wherein, the context includes a register group and / or stack space.

8. The communication system based on a virtual machine monitor according to claim 2, characterized in that, When the exception and interrupt handling module performs real-time monitoring of exception and interrupt requests, it includes: The unauthorized access by the client is marked as a minor anomaly, and the operation of the corresponding client is suspended, and an alarm signal is triggered. The anomaly information is recorded, and a warning message is generated and sent based on the anomaly information. The operation of the corresponding client is resumed after the unauthorized access anomaly is handled. Mark client failures, instruction errors, and / or cache conflicts as critical anomalies, immediately terminate the operation of the corresponding client, initiate a fault isolation mechanism to ensure that the failure of the corresponding client does not spread to other clients and virtual machine monitors, trigger alarm signals, record abnormal information, and generate and send warning information based on the abnormal information; When an external device or client initiates an interrupt request, the interrupt request is routed to the corresponding client according to the interrupt routing table to limit cross-client interrupt interference. After the interrupt request is processed, the client is restored to normal operation to compensate for the scheduling delay caused by the interrupt request processing and control the exception handling delay within a preset time.

9. The communication system based on a virtual machine monitor according to claim 1, characterized in that, Upon startup, the hardware layer includes: entering the security monitoring privilege level, completing hardware resource initialization, and switching from the security monitoring privilege level to the virtualization privilege level after initialization; wherein, hardware resource initialization includes: Initialize the processor core, including: configuring dual-core enable, virtualization privilege level enable, and enabling hardware virtualization extension; Initialize memory, including: configuring the address mapping of on-chip random access memory, dividing the virtual machine monitor dedicated memory partition and guest memory partition, initializing through the memory protection unit, and setting the access permissions of each partition; Initialize external devices and interrupts, including: initializing the interrupt controller, disabling all interrupts, and configuring interrupt priorities; and initializing external devices, setting access permissions for external devices, and assigning external devices to their corresponding clients.

10. A communication method based on a virtual machine monitor, characterized in that, The method includes the following steps: Acquire hardware resources, resource access requests, and task scheduling services, wherein the resource access requests and the task scheduling services are initiated by the client. Based on the resource access request and the task scheduling service, the hardware resources are allocated, controlled, and isolated through the virtual machine monitor, and client scheduling and isolation are performed through the virtual machine monitor to restrict clients from directly accessing the hardware resources, so that the clients access the hardware resources through the virtual machine monitor.

Images