Hardware peripheral virtualization methods and systems

Abstract

This invention provides a hardware peripheral virtualization method and system. The method includes: acquiring hardware configuration information and container allocation configuration information, and parsing to obtain peripheral channel parameters, shared resource parameters, and container binding parameters; configuring hardware isolation rules for multiple physical channels in a parent physical peripheral based on the peripheral channel parameters and shared resource parameters; creating a corresponding sub-device and a corresponding sub-device file node for each physical channel according to the hardware isolation rules; and allocating the sub-device file nodes to corresponding containers in an isolated manner according to the container binding parameters, so that each container can only access the sub-device file nodes allocated to it, controlling the containers to directly access the corresponding physical channels through the sub-device file nodes, and scheduling the shared hardware resources of the parent physical peripheral, thereby achieving isolated virtualization sharing of hardware peripherals by containers. This hardware peripheral virtualization method can achieve strong isolation virtualization sharing of hardware peripherals in a multi-container environment.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a hardware peripheral virtualization method and system. Background Technology

[0002] Currently, hardware peripheral virtualization is mainly divided into two major technical routes: virtual machine virtualization and container virtualization. Both of them have the core drawback of being unable to balance hardware cost, access performance and isolation.

[0003] Virtual machine virtualization solutions rely on hardware-assisted virtualization technology, requiring native chipset support, making them incompatible with older hardware and resulting in extremely high deployment and upgrade costs. Without hardware assistance, pure software-simulated peripherals require frequent context switching, leading to significant performance degradation.

[0004] Furthermore, existing container virtualization solutions significantly increase hardware costs by allocating containers across multiple hardware instances. When a single hardware instance is shared via multiple software channels, the kernel-mode driver needs to handle complex sharing logic, resulting in a substantial decrease in system performance and an inability to achieve strong isolation for hardware access between containers. Therefore, existing technologies cannot achieve high-performance, strongly isolated virtualization sharing of container-level hardware peripherals with minimal hardware modifications, becoming a technical bottleneck in multi-core System-on-Chip (SOC) chip virtualization scenarios. Summary of the Invention

[0005] In view of this, this application provides a hardware peripheral virtualization method and system to achieve strong isolation virtualization sharing of hardware peripherals in a multi-container environment, while taking into account system security, real-time performance and resource utilization.

[0006] In a first aspect, this application provides a hardware peripheral virtualization method, the method being applied to the kernel-mode driver module of a hardware peripheral virtualization system, the method comprising: Obtain hardware configuration information and container allocation configuration information, parse the hardware configuration information and container allocation configuration information to obtain peripheral channel parameters, shared resource parameters and container binding parameters; Based on the peripheral channel parameters and the shared resource parameters, configure hardware isolation rules for multiple physical channels in the parent physical peripheral; According to the hardware isolation rules, a corresponding sub-device is created for each physical channel, and a corresponding sub-device file node is created for each sub-device; According to the container binding parameters, the sub-device file nodes are allocated to the corresponding containers in an isolated manner, so that each container can only access the sub-device file nodes allocated to it. The container is controlled to directly access the corresponding physical channel through the sub-device file nodes and schedule the shared hardware resources of the parent physical peripheral, thereby realizing the isolated virtualization sharing of hardware peripherals by the container.

[0007] Optionally, the step of allocating the sub-device file nodes to corresponding containers in an isolated manner according to the container binding parameters, so that each container can only access the sub-device file nodes allocated to it, and controlling the containers to directly access the corresponding physical channels through the sub-device file nodes, includes: The binding relationship between the target container and the sub-device file node is determined based on the container binding parameters, and an independent device namespace is created for the target container according to the binding relationship; The sub-device file node corresponding to the target container is mounted to the independent device namespace to obtain an isolated container environment with a dedicated sub-device file node. Based on the isolated container environment, the target container's access permissions to other sub-device file nodes except for the dedicated sub-device file node are blocked, forming a container-specific node access permission, so that each container can only access the sub-device file nodes assigned to it. Based on the container-specific node access permissions, a dedicated hardware access link is established for the target container to directly access the corresponding physical channel through the dedicated sub-device file node, and the container is controlled to directly access the corresponding physical channel through the dedicated sub-device file node.

[0008] Optionally, determining the binding relationship between the target container and the sub-device file node based on the container binding parameters, and creating an independent device namespace for the target container according to the binding relationship, includes: Based on the container binding parameters, the target container is matched with the corresponding sub-device file node, and the binding relationship between the target container and the sub-device file node is determined and generated; Based on the binding relationship, the container independent namespace mechanism is invoked to create a dedicated device namespace for the target container; Configure access isolation rules for the dedicated device namespace to prevent permission overlap between the dedicated device namespace and the device namespaces of other containers, thus creating an independent device namespace.

[0009] Optionally, the access isolation rules include: Within the dedicated device namespace, only the dedicated child device file node corresponding to the target container is retained, while the master control device node of the parent physical peripheral and other child device file nodes are hidden.

[0010] Optionally, the control container directly accesses the corresponding physical channel through a dedicated sub-device file node, including: The hardware access requests for the container are verified through the dedicated sub-device file node. Once the permission verification is successful, the control container directly accesses the corresponding physical channel and maps the register space of the corresponding physical channel to the user-mode virtual address space of the container, enabling the container to directly read and write the register data inside the physical channel at the user-mode level.

[0011] Optionally, configuring hardware isolation rules for multiple physical channels in the parent physical peripheral based on the peripheral channel parameters and the shared resource parameters includes: Based on the peripheral channel parameters and shared resource parameters, obtain the basic hardware configuration information of multiple physical channels in the parent physical peripheral to obtain the physical channel hardware configuration baseline data; Based on the physical channel hardware configuration baseline data, an independent address access range is allocated to each physical channel to obtain the physical channel parameters configured with an independent address access range; Based on the physical channel parameters, a dedicated interrupt line is assigned to each physical channel, and an independent register base address is assigned to each physical channel, forming a hardware isolation rule for multiple physical channels in the parent physical peripheral.

[0012] Optionally, the step of creating a corresponding sub-device for each physical channel and a corresponding sub-device file node for each sub-device according to the hardware isolation rules includes: According to the hardware isolation rules, a device number is assigned to each physical channel through the kernel standard character device model, and the device number is bound to the physical channel number to form a channel device binding relationship. Based on the channel device binding relationship, a sub-device corresponding to each physical channel is created, and a corresponding sub-device file node is created for each sub-device.

[0013] Optionally, after allocating a dedicated interrupt line for each physical channel and an independent register base address for each physical channel, the method further includes: It verifies the address validity of all access requests in real time, intercepts unauthorized access operations between physical channels, and achieves hardware-level isolation of multiple physical channels.

[0014] Secondly, this application provides a hardware peripheral virtualization system, the hardware peripheral virtualization system comprising: The parent physical peripheral integrates multiple hardware-isolated physical channels, each physical channel corresponding to a child physical device, and the multiple physical channels share some hardware resources; A kernel-mode driver module is communicatively connected to the parent physical peripheral device, and the kernel-mode driver module is used to execute the hardware peripheral virtualization method provided in the embodiments of this application.

[0015] Optionally, the parent physical peripheral also includes: The hardware configuration and isolation unit is used to configure independent address mapping, dedicated interrupt routing and access permissions for each physical channel, and to verify the legality of hardware access requests in real time and intercept unauthorized access between physical channels. A shared hardware resource pool is provided for use by multiple physical channels and is configured and managed by the kernel-mode driver module.

[0016] The hardware peripheral virtualization method provided in this application, based on the multi-physical channel structure of the parent physical peripheral and configured isolation rules, achieves virtualization sharing, exhibits good compatibility with hardware platforms, effectively reduces hardware deployment and upgrade costs, and solves the shortcomings of traditional hardware-assisted virtualization, which relies on dedicated chips and has limited applicability. The method establishes a direct access link between the container and the physical channel through sub-device file nodes, allowing the container to directly access hardware resources, effectively reducing peripheral access latency and achieving near-physical direct connection operational efficiency. Furthermore, by configuring independent hardware isolation rules for the physical channel, the method can avoid problems such as unauthorized access between containers, address conflicts, or interruption interference, enhancing the overall virtualization isolation of the system. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0018] Figure 1 This is a schematic diagram illustrating the steps of the hardware peripheral virtualization method provided in the embodiments of this application; Figure 2 This is a flowchart illustrating the steps for establishing container-side sub-device isolation and hardware direct access links provided in an embodiment of this application. Figure 3 This is a flowchart illustrating the steps involved in creating and configuring the container device namespace and isolation rules, as provided in this application embodiment. Figure 4 This is a flowchart illustrating the steps for verifying container hardware access permissions provided in an embodiment of this application; Figure 5 This is a flowchart illustrating the steps for configuring physical channel hardware isolation rules according to an embodiment of this application. Figure 6 This is a flowchart illustrating the steps of physical channel device binding and sub-device file node creation provided in this application embodiment; Figure 7 This is a schematic diagram of the hardware peripheral virtualization system provided in the embodiments of this application; Figure 8 This is a schematic diagram of the structure of the internal modules of the parent physical peripheral provided in the embodiments of this application; Figure 9 This is a schematic diagram of the hardware channel structure of the parent physical peripheral and its child devices provided in the embodiments of this application; Figure 10 This is a schematic diagram of the hardware module composition of the parent physical peripheral provided in the embodiments of this application. Detailed Implementation

[0019] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not all of them. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0020] The terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish different objects, not to describe a specific order. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or apparatuses.

[0021] In this document, references to "embodiment" or "implementation" mean that a particular feature, structure, or characteristic described in connection with an embodiment or implementation may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0022] Please see Figure 1 This application provides a hardware peripheral virtualization method, which is applied to the kernel-mode driver module 102 of a hardware peripheral virtualization system 100. The method includes the following steps: S10. Obtain hardware configuration information and container allocation configuration information, parse the hardware configuration information and container allocation configuration information to obtain peripheral channel parameters, shared resource parameters and container binding parameters.

[0023] Optionally, the hardware peripheral virtualization system 100 is built on a multi-core system-on-chip (SOC) chip and can achieve container-level isolated virtualization sharing for hardware peripherals with multiple physical channels, such as display output, graphics processor, and direct memory access. This is used to overcome the technical defects of existing hardware-assisted virtualization, which relies on chip support and has high deployment costs; pure software virtualization, which has frequent context switching and poor access performance; and container peripheral sharing isolation, which has chaotic resource scheduling.

[0024] Specifically, the hardware peripheral virtualization method is executed by the kernel-mode driver module 102 of the hardware peripheral virtualization system 100. The kernel-mode driver module 102 runs in the operating system kernel layer and has the authority to manage hardware resources, configure container permissions, and schedule shared resources.

[0025] Optionally, the hardware configuration information comes from the device tree configuration file of the parent physical peripheral 101 in the multi-core SOC chip, specifically including the global hardware base address of the parent physical peripheral 101, the total number of physical channels, the hardware specifications of each physical channel, the register address range, the interrupt number allocation rules and other inherent hardware parameters.

[0026] Optionally, the container allocation configuration information is the system's preset container service configuration data, which specifically includes configuration parameters such as the number of containers, the service type of each container, priority, and the physical channel number to be bound.

[0027] Optionally, the kernel-mode driver module 102 calls the kernel parsing interface to parse and extract the above two types of configuration information field by field, and separates the peripheral channel parameters, shared resource parameters and container binding parameters.

[0028] Optionally, the peripheral channel parameters are used to characterize the hardware attributes and independent configuration rules of each physical channel, the shared resource parameters are used to characterize the type, address and scheduling rules of the shared hardware resources of multiple physical channels in the parent physical peripheral 101, and the container binding parameters are used to characterize the one-to-one correspondence between the container and the physical channel and the sub-device file node.

[0029] S20. Configure hardware isolation rules for multiple physical channels in the parent physical peripheral according to the peripheral channel parameters and the shared resource parameters.

[0030] Optionally, the parent physical peripheral 101 integrates multiple independent physical channels, each physical channel corresponding to a child physical device, and the multiple physical channels share hardware resources such as a global clock unit, an electromagnetic interference suppression unit, and a bus arbitration unit.

[0031] Optionally, the hardware configuration baseline of each physical channel is determined based on the peripheral channel parameters, and the resource usage boundary of each physical channel is defined in combination with the shared resource parameters. An independent address access range, a dedicated interrupt line and an independent register base address are allocated to each physical channel to form hardware isolation rules.

[0032] The hardware isolation rules are used to limit the hardware access permissions and resource usage scope of each physical channel, blocking address conflicts, interruptions, and unauthorized access between physical channels at the hardware level, and providing hardware-level protection for the isolated access of containers.

[0033] S30. According to the hardware isolation rules, create a corresponding sub-device for each physical channel and a corresponding sub-device file node for each sub-device.

[0034] Optionally, the kernel-mode driver module 102 is based on the standard character device model of the operating system kernel. It assigns a unique device number to each physical channel according to the hardware isolation rules, and binds the device number to the physical channel number one by one to form a fixed channel device mapping relationship.

[0035] Furthermore, based on this mapping relationship, a dedicated sub-device is created for each physical channel. The sub-device corresponds one-to-one with the hardware resources of the physical channel and only has access permissions to the corresponding physical channel.

[0036] Furthermore, a corresponding sub-device file node is created for each sub-device in the system device directory. The sub-device file node serves as the sole software interface for containers to access the physical channel, establishing a direct access link between the container and the physical channel, replacing the traditional software-simulated forwarding path of virtualization.

[0037] S40. According to the container binding parameters, the sub-device file nodes are allocated to the corresponding containers in an isolated manner, so that each container can only access the sub-device file nodes allocated to it. The container is controlled to directly access the corresponding physical channel through the sub-device file nodes, and the shared hardware resources of the parent physical peripheral are scheduled to realize the isolated virtualization sharing of the hardware peripheral by the container.

[0038] Optionally, based on the container binding parameters, the sub-device file nodes are matched with the target container, and the container isolation mechanism is used to block the container's access permissions to non-dedicated sub-device file nodes and the parent physical peripheral 101 master control device node, ensuring that the container only has access permissions to its own bound sub-device file nodes.

[0039] Furthermore, the control container can directly read and write register data of the corresponding physical channel through the sub-device file node without kernel-mode software simulation and context switching, thereby effectively improving hardware access performance.

[0040] Optionally, the kernel-mode driver module 102 uniformly schedules the shared hardware resources of the parent physical peripheral 101, dynamically allocates shared resources according to the container service priority and access requirements, ensures stability and isolation when multiple containers access each other in parallel, and ultimately achieves high-performance, strongly isolated virtualization sharing of hardware peripherals by containers with only a few hardware modifications.

[0041] As can be seen, the hardware peripheral virtualization method provided in this application embodiment implements process control for configuration parsing, hardware isolation, sub-device creation, container isolation allocation, and shared resource scheduling through the kernel-mode driver module 102. The hardware peripheral virtualization method provided in this application embodiment does not rely on a Central Processing Unit (CPU) or chipset-level hardware-assisted virtualization unit. It achieves virtualization sharing solely based on the multi-physical channel structure configuration isolation rules of the parent physical peripheral 101, exhibiting good compatibility with older hardware platforms and effectively reducing hardware deployment and upgrade costs. It solves the shortcomings of traditional hardware-assisted virtualization, which relies on dedicated chips and has limited applicability. Furthermore, the hardware peripheral virtualization method provided in this application embodiment establishes a direct access link between the container and the physical channel through the sub-device file node. Unlike the context switching, instruction simulation, and data forwarding processes of traditional pure software virtualization, the container can directly connect to hardware resources, effectively reducing peripheral access latency and achieving near-physical direct connection operational efficiency. This makes it suitable for multi-core SOC application scenarios with strict real-time requirements, such as automotive and embedded systems. Furthermore, by configuring independent hardware isolation rules for physical channels, issues such as unauthorized access, address conflicts, or interruption interference between containers can be avoided, enhancing the overall virtualization isolation of the system. In addition, the kernel-mode driver module 102 only completes configuration and rule creation during the initialization phase, and is only responsible for lightweight permission verification and resource scheduling during the runtime phase, reducing system memory consumption and computing power overhead, and improving the overall throughput efficiency when multiple containers run in parallel. This method is compatible with various hardware peripherals with multiple physical channels, does not depend on specific hardware architectures or peripheral types, and is suitable for container virtualization scenarios using mainstream multi-core SOC chips. Simultaneously, the decoupling design between sub-devices and parent drivers maintains stable performance across different hardware versions, providing stronger scenario expansion capabilities. Moreover, the kernel-mode driver module 102 uniformly schedules the shared hardware resources of the parent physical peripheral 101, dynamically allocating resources based on container service type and priority, avoiding resource contention issues during concurrent access by multiple containers, and ensuring long-term stable system operation.

[0042] Please see Figure 2 The step of allocating the sub-device file nodes to corresponding containers in an isolated manner according to the container binding parameters, so that each container can only access the sub-device file nodes assigned to it, and controlling the containers to directly access the corresponding physical channels through the sub-device file nodes, includes the following steps: S41. Determine the binding relationship between the target container and the sub-device file node based on the container binding parameters, and create an independent device namespace for the target container according to the binding relationship.

[0043] Optionally, the container binding parameters predefine the unique correspondence between each service container and the corresponding physical channel and sub-device file node. The kernel-mode driver module 102 completes the matching and binding of the target container and the dedicated sub-device file node based on the parameters, ensuring that a container is bound to only one sub-device file node and a sub-device file node is assigned to only one container.

[0044] Optionally, based on the container's native device namespace isolation mechanism, a dedicated device namespace that is independent and does not interfere with each other is created for each target container. This namespace is separated from the system's global device space and the device namespaces of other containers, thus building an isolation barrier for device access between containers at the software architecture level.

[0045] S42. Mount the sub-device file node corresponding to the target container to the independent device namespace to obtain an isolated container environment with a dedicated sub-device file node.

[0046] Optionally, the kernel-mode driver module 102 calls the kernel device mounting interface to mount the created dedicated sub-device file node to the independent device namespace of the current target container. After the container starts, it can only recognize and access the mounted node within its own namespace and cannot perceive other device resources in the global device directory, thus forming a lightweight, highly isolated container runtime environment that only contains dedicated device interfaces.

[0047] S43. Based on the isolated container environment, the target container's access permissions to other sub-device file nodes besides the dedicated sub-device file node are blocked, forming a container-specific node access permission, so that each container can only access the sub-device file nodes assigned to it.

[0048] Optionally, by configuring permission rules, the device access scope of the target container can be restricted, blocking its access permissions to the parent physical peripheral 101 master control device node and the child device file nodes corresponding to other physical channels, including read, write, and control operation permissions. This ensures that the container only has operation permissions assigned to its own exclusive child device file nodes, preventing the container from accessing unbound hardware resources without authorization and strengthening the access isolation when multiple containers run in parallel.

[0049] S44. Based on the container-specific node access permissions, establish a dedicated hardware access link for the target container to directly access the corresponding physical channel through the dedicated sub-device file node, and control the container to directly access the corresponding physical channel through the dedicated sub-device file node.

[0050] Optionally, based on dedicated node permissions, a direct hardware access link is established between the container and the bound physical channel. This link bypasses the software simulation, data forwarding, and context switching processes of traditional virtualization. The container can directly access the hardware registers of the physical channel through a dedicated sub-device file node. With the support of this link, the container's hardware access commands can be directly issued to the corresponding physical channel, and the hardware response data can be directly sent back to the container, achieving high-performance direct hardware access without intermediate losses and ensuring the real-time performance and efficiency of peripheral device operations.

[0051] As can be seen, the hardware peripheral virtualization method provided in this application creates an independent device namespace for each target container, making the device environments of each container independent. This blocks the penetration and cross-access of device resources between containers from the software architecture perspective. Combined with a dedicated node permission shielding mechanism, it avoids the risk of containers accessing unauthorized hardware resources. Simultaneously, dedicated sub-device file nodes are independently mounted to the container's own namespace. The container can only identify and use the uniquely authorized device node, eliminating irrelevant device enumeration and resource loading processes, simplifying the container's device access logic, reducing resource load and the probability of anomalies during container runtime, and improving the stability and reliability of multi-container parallel operation. Furthermore, a dedicated hardware access link from the container to the physical channel is established based on dedicated node permissions, skipping the intermediate proxy, instruction simulation, and context switching stages of traditional virtualization. The container's hardware operation commands can directly reach the physical channel, and hardware response data is directly transmitted back to the container, effectively reducing access latency and restoring the performance of direct hardware connection, adapting to the high real-time peripheral business requirements. In addition, by forming dedicated node access permissions for the container, it restricts the container to only perform operations on the bound sub-device nodes, ensuring the normal operation of container services while avoiding security risks caused by permission redundancy. Furthermore, it achieves isolated allocation based on the operating system's native device namespace and mounting mechanism, without requiring modifications to the container runtime and kernel core architecture. It is compatible with mainstream container engines, adapts to general operating systems, and is easy to deploy on existing multi-core SOC virtualization platforms.

[0052] Please see Figure 3 The process of determining the binding relationship between the target container and the child device file node based on the container binding parameters, and creating an independent device namespace for the target container according to the binding relationship, includes the following steps: S411. Based on the container binding parameters, match the target container with the corresponding sub-device file node, determine and generate the binding relationship between the target container and the sub-device file node.

[0053] The container binding parameters are obtained in advance by the kernel-mode driver module 102, which records the identification information, service type, priority, and sub-device file node path corresponding to the allocated physical channel of each service container.

[0054] Optionally, the kernel-mode driver module 102 performs a one-to-one matching between the unique identifier of the target container and the corresponding sub-device file node based on the container binding parameters, ensuring that a single target container is bound to only one unique sub-device file node and a single sub-device file node belongs to only one target container, with no cross-binding or missing binding, and generates a standardized binding relationship table between containers and sub-device file nodes, providing a basis for subsequent namespace creation and device mounting.

[0055] S412. Based on the binding relationship, the container independent namespace mechanism is invoked to create a dedicated device namespace for the target container.

[0056] Optionally, the kernel-mode driver module 102 relies on the native container isolation mechanism of the operating system kernel to allocate a dedicated device namespace for the target container that has been bound by calling the kernel namespace creation interface.

[0057] Optionally, the dedicated device namespace provides an independent device view environment for the target container, which is separated from the system global device namespace and the device namespaces of other containers. It only serves the device access needs of the current target container, thus building the foundation for isolation of device resources between containers at the kernel level.

[0058] S413. Configure access isolation rules for the dedicated device namespace so that the dedicated device namespace has no permission overlap with the device namespaces of other containers, thus obtaining an independent device namespace.

[0059] Optionally, an access isolation policy can be configured for the created dedicated device namespace, restricting the namespace to only loading and identifying the child device file nodes bound to the current target container, and prohibiting it from accessing or calling system global device resources and any device nodes in other container-specific device namespaces.

[0060] In one possible embodiment, permission penetration and data interaction channels between namespaces are blocked, thereby ensuring that each dedicated device namespace is independent and does not overlap in terms of permissions, resources and access paths, forming an independent device namespace that meets the isolation requirements.

[0061] As can be seen, the hardware peripheral virtualization method provided in this application achieves a one-to-one matching between the target container and the sub-device file node based on container binding parameters, generating a stable and unique binding relationship. This avoids problems such as multiple containers competing for the same device, duplicate allocation of a single device, or misaligned channel binding, ensuring the accuracy and standardization of hardware resource allocation. Simultaneously, it directly calls the operating system's native container independent namespace mechanism to create a dedicated isolated environment, without requiring customized modifications to the kernel or container runtime. This allows for compatibility with mainstream operating systems and general container engines, reducing deployment costs and improving the long-term stability of the system. Furthermore, by configuring dedicated access isolation rules, the device namespaces of each container are independent in terms of permissions, resources, and views, strengthening the isolation boundaries between containers and achieving a strong dual isolation effect at the kernel and device layers.

[0062] Optionally, the access isolation rules include: retaining only the dedicated sub-device file node corresponding to the target container within the dedicated device namespace, and blocking the master control device node of the parent physical peripheral 101 from other sub-device file nodes.

[0063] Optionally, after the kernel-mode driver module 102 completes the creation of the dedicated device namespace, it filters and configures the device nodes in the namespace, retaining only the dedicated sub-device file nodes that are pre-bound to the target container in the dedicated device namespace, and performing masking on all other device nodes.

[0064] Specifically, the kernel-mode driver module 102, through the kernel permission control interface, blocks the master control device node of the parent physical peripheral 101 from the target container, prohibiting the container from performing any read, write, or configuration operations on the core master control nodes such as the parent device's global control register and shared resource master control interface. At the same time, it blocks all child device file nodes corresponding to other physical channels, preventing the target container from enumerating or accessing child device resources that are not bound to it.

[0065] Through the aforementioned access isolation rules, the target container can only see the unique child device file node within its own dedicated device namespace, and cannot perceive the parent physical peripheral 101 master node and the child device nodes of other containers. This achieves access isolation at the device view level, avoids unauthorized access to hardware resources between containers, address conflicts and interruptions, and ensures the stability and security when multiple containers access hardware peripherals in parallel.

[0066] Please see Figure 4 The control container directly accesses the corresponding physical channel through a dedicated sub-device file node, including the following steps: S441. Perform permission verification on the container's hardware access request through the dedicated sub-device file node.

[0067] Optionally, when a container initiates a hardware access request for physical channel, such as register read / write or parameter configuration, the request will first be uploaded to the kernel-mode driver module 102 via a dedicated sub-device file node.

[0068] In one possible embodiment, the kernel-mode driver module 102 verifies the legitimacy of access requests item by item based on the pre-configured container-specific node access permissions, and determines whether the request points to the physical channel currently bound to the container, whether it is within the authorized register address range, and whether the operation type conforms to the preset permissions, thereby filtering out abnormal requests such as unauthorized access and illegal address operations, and ensuring the security of hardware access.

[0069] S442. After the permission verification is passed, the control container directly accesses the corresponding physical channel and maps the register space of the corresponding physical channel to the user-mode virtual address space of the container, so that the container can directly read and write the register data inside the physical channel at the user-mode level.

[0070] Optionally, the kernel-mode driver module 102 calls the operating system kernel's memory mapping interface and uses a mapping mechanism to directly map the physical address space of the hardware registers of the physical channel to the user-mode virtual address space of the container, thus establishing a direct mapping relationship from user mode to hardware registers.

[0071] Based on the above mapping relationship, containers can directly read and write register data inside the physical channel at the user space level without triggering kernel space switching or data forwarding through the software simulation layer. Hardware access commands can directly reach the physical channel, and hardware feedback data can be directly sent back to the container user space, avoiding the performance loss caused by traditional virtualization and enabling containers to directly access hardware peripherals with low latency and high efficiency.

[0072] As can be seen, the hardware peripheral virtualization method provided in this application performs independent permission verification on all hardware access requests of the container through dedicated sub-device file nodes. This can filter abnormal behaviors such as unauthorized operations, illegal address access, and unauthorized instructions in real time, preventing illegal operations from damaging the hardware state and interfering with other container services, thereby improving the security and stability of system hardware access. Furthermore, by directly mapping the physical channel register space to the container's user-space virtual address space, the container can directly read and write register data in user space, avoiding the overhead of multi-layer context switching in traditional virtualization. This effectively reduces peripheral access latency, bringing performance close to that of direct physical hardware access, thus achieving an effective balance between isolation security and access efficiency.

[0073] Please see Figure 5 The step of configuring hardware isolation rules for multiple physical channels in a parent physical peripheral based on the peripheral channel parameters and the shared resource parameters includes the following steps: S21. Based on the peripheral channel parameters and shared resource parameters, obtain the basic hardware configuration information of multiple physical channels in the parent physical peripheral to obtain the physical channel hardware configuration baseline data.

[0074] Optionally, the peripheral channel parameters include information such as the total number of physical channels of the parent physical peripheral 101, the hardware capabilities of each channel, and the physical address range of the registers, while the shared resource parameters include configuration information of shared resources such as global clock, electromagnetic interference suppression, and bus arbitration.

[0075] Optionally, the kernel-mode driver module 102 extracts basic information such as hardware specifications, resource dependencies, and address boundaries of each physical channel based on the peripheral channel parameters and shared resource parameters, and integrates them to form standardized physical channel hardware configuration benchmark data, providing data support for hardware isolation rule configuration.

[0076] S22. Based on the physical channel hardware configuration baseline data, allocate an independent address access range for each physical channel to obtain physical channel parameters configured with independent address access ranges.

[0077] Optionally, the address space boundaries of each physical channel are defined based on the hardware configuration baseline data, and each physical channel is allocated an independent address access range that does not overlap or intersect with each other. This blocks address conflicts and illegal out-of-bounds access between different physical channels at the hardware address level, ensuring that the address spaces of each physical channel are independent and forming the basic conditions for hardware isolation.

[0078] S23. Based on the physical channel parameters, allocate a dedicated interrupt line to each physical channel and assign an independent register base address to each physical channel to form a hardware isolation rule for multiple physical channels in the parent physical peripheral.

[0079] Optionally, each physical channel can be assigned a dedicated and independent interrupt line to avoid interrupt signal interference and interrupt preemption between different channels, ensuring the stability of hardware response. Simultaneously, each physical channel is assigned an independent register base address, isolating the register configuration and status read / write operations of each channel and preventing them from affecting each other. Through the configuration of independent address ranges, dedicated interrupt lines, and independent register base addresses, a complete hardware isolation rule is formed, achieving strong hardware-level isolation for the parent physical peripheral's 101 multiple physical channels.

[0080] As can be seen, the hardware peripheral virtualization method provided in this application extracts the real physical channel hardware configuration benchmark based on peripheral channel parameters and shared resource parameters, enabling isolation rules to match the hardware architecture and channel attributes of the parent physical peripheral 101. Simultaneously, it allocates non-overlapping address spaces to each physical channel, blocking risks such as cross-channel address unauthorized access and address overwriting at the hardware address bus level, thus improving hardware access security and reducing performance overhead caused by software verification. Furthermore, each physical channel uses a dedicated interrupt line, avoiding issues such as interrupt preemption, false triggering, or signal interference between multiple channels. Moreover, each channel's register space is independent; the container's register read / write and parameter configuration for its own channel do not affect the hardware state of other channels, achieving full isolation of channel operations at the hardware level. This prevents systemic hardware failures caused by single-channel configuration anomalies. By constructing a strong hardware-level isolation barrier through independent addresses, dedicated interrupts, and independent registers, it effectively enhances the overall system security protection capability.

[0081] Please see Figure 6 The step of creating a corresponding sub-device for each physical channel and a corresponding sub-device file node for each sub-device according to the hardware isolation rules includes the following steps: S31. According to the hardware isolation rules, a device number is assigned to each physical channel through the kernel standard character device model, and the device number is bound to the physical channel number to form a channel device binding relationship.

[0082] Optionally, the standard character device model provides standardized device registration, management, and access interfaces for hardware peripherals.

[0083] Optionally, the kernel-mode driver module 102 assigns a globally unique device number containing a major device number and a minor device number to each physical channel based on the isolation configuration information such as the independent address range and register base address of each physical channel in the hardware isolation rules. The device number is then fixedly bound one-to-one with the hardware number of the physical channel to ensure that the device number and the physical channel correspond one-to-one without duplication or overlap, forming a stable and unique channel device binding relationship, and providing an identification basis for the creation of sub-devices.

[0084] S32. Based on the channel device binding relationship, create a sub-device corresponding to each physical channel, and create a corresponding sub-device file node for each sub-device.

[0085] Optionally, based on the channel device binding relationship, a dedicated sub-device is registered and created for each physical channel. This sub-device fully inherits the hardware isolation attributes of the corresponding physical channel, has only the permission to access its own bound physical channel, and is independent of other sub-devices and does not interfere with each other.

[0086] Optionally, a corresponding sub-device file node is generated for each sub-device in the system device file directory. The sub-device file node serves as the only software interface for containers to access the corresponding physical channel, providing a standardized access entry point for subsequent container isolation allocation and direct hardware access.

[0087] As can be seen, the hardware peripheral virtualization method provided in this application adopts a character device model to allocate device numbers and create sub-devices, which is compatible with various multi-core SOC hardware platforms. Simultaneously, it binds device numbers to physical channel hardware numbers one-to-one, solidifying the correspondence between channels and devices at the device identification level. This avoids problems such as device number conflicts, channel binding misalignments, or device identification failures in multi-channel scenarios, ensuring the accuracy and stability of the hardware access link. Furthermore, sub-devices created based on hardware isolation rules inherit the isolation characteristics of the corresponding physical channel, such as independent addresses, dedicated interrupts, and independent registers. This ensures that the isolation attributes of software-layer sub-devices and hardware-layer channels are consistent, allowing hardware isolation rules to permeate the software access layer, forming end-to-end isolation.

[0088] Optionally, after allocating a dedicated interrupt line for each physical channel and assigning an independent register base address for each physical channel, the method further includes: verifying the address validity of all access requests in real time, intercepting unauthorized access operations between physical channels, and achieving hardware-level isolation of multiple physical channels.

[0089] Optionally, after allocating a dedicated interrupt line and configuring an independent register base address for each physical channel, a real-time hardware access address verification mechanism is initiated to perform full and real-time legality verification on all access requests sent to the parent physical peripheral 101. The verification mechanism is based on hardware isolation rules, and the verification content includes whether the target address of the access request belongs to the authorized address range of the current physical channel, whether it exceeds the register space of other channels, and whether it touches the shared resource control address, etc.

[0090] In one possible embodiment, if real-time verification detects illegal behavior such as address out-of-bounds access or cross-channel access in the access request, the unauthorized access operation will be blocked, and related instructions such as register read / write or hardware configuration will be refused to be executed. At the same time, the instruction transmission and data interaction of the abnormal request will be blocked, so as to avoid illegal access, address conflict and signal interference between physical channels from the kernel level.

[0091] As can be seen, the hardware peripheral virtualization method provided in this application, based on static hardware isolation configurations such as independent interrupt lines and independent register base addresses, adds real-time address verification and privilege escalation interception mechanisms. Even if there are problems such as address configuration deviations or abnormal software permissions, it can still block unauthorized access through real-time verification, providing security for hardware isolation. Furthermore, it performs full and real-time address verification on hardware access requests. When illegal operations such as crossing channels or exceeding addresses are detected, instructions are executed at the hardware access entry point to block them, preventing illegal instructions from reaching hardware registers and causing data corruption or hardware failure.

[0092] Please see Figure 7 This application also provides a hardware peripheral virtualization system 100, which includes a parent physical peripheral 101 and a kernel-mode driver module 102. The parent physical peripheral 101 integrates multiple hardware-isolated physical channels, each physical channel corresponding to a sub-physical device, and the multiple physical channels share some hardware resources. The kernel-mode driver module 102 is communicatively connected to the parent physical peripheral 101, and the kernel-mode driver module 102 is used to execute the hardware peripheral virtualization method provided in any embodiment of this application.

[0093] Please see Figure 9 In one specific embodiment of this application, the parent physical peripheral contains multiple independent hardware channels, each corresponding to an independent sub-device. Specifically, this includes sub-device 0 and its corresponding hardware channel, sub-device 1 and its corresponding hardware channel, sub-device 2 and its corresponding hardware channel, and sub-device n and its corresponding hardware channel, etc. The parent physical peripheral is a hardware peripheral entity supporting concurrent access to multiple channels. Internally, it allocates an independent hardware channel to each sub-device through a hardware-level isolation mechanism. The physical address spaces of each hardware channel are independent, and they have independent register configuration spaces and dedicated interrupt lines, achieving hardware-level isolation between different sub-devices. Each sub-device hardware channel corresponds to an independent sub-device, and the sub-device and hardware channel are bound one-to-one.

[0094] It is understood that the hardware peripheral virtualization system 100 provided in this application is not limited to a single fixed hardware architecture and deployment form, and its product implementation can include a variety of feasible implementation methods. For example, the hardware peripheral virtualization system 100 can be integrated and deployed inside a multi-core SOC chip. Another example is that the hardware peripheral virtualization system 100 can also adopt a split architecture with a main control chip and independent peripheral chips. Yet another example is that the hardware peripheral virtualization system 100 can be implemented as a complete product form such as an embedded device, industrial control equipment, or in-vehicle intelligent terminal. Yet another example is that the hardware peripheral virtualization system 100 can be implemented in a modular form with software drivers and general standard hardware. Yet another example is that the hardware peripheral virtualization system 100 can also be deployed on computing hardware platforms such as servers and edge computing gateways, providing unified isolation, allocation, and virtualization scheduling capabilities for multi-physical channel hardware peripherals within a platform with a platform hardware and software adaptation approach, supporting multiple containers and multiple virtual machine environments. This application does not limit the specific hardware type, quantity, or integration method of the parent physical peripheral 101, nor does it limit the specific deployment location, compilation form, or loading method of the kernel-mode driver module 102. Any product form, such as chip embedding, board-level separation, whole-machine integration, modular adaptation, or computing platform deployment, falls within the protection scope of this application.

[0095] In one optional embodiment of this application, the hardware peripheral virtualization system 100 is implemented based on a multi-core SOC chip architecture and is used to carry out the execution of the hardware peripheral virtualization method provided in any embodiment of this application. It can achieve container-level high-performance, strongly isolated virtualization sharing of multiple physical channel hardware peripherals such as display output, graphics processor, and direct memory access with minimal hardware modifications, thereby solving the technical defects of existing virtualization solutions such as high hardware cost, poor access performance, and insufficient isolation.

[0096] Optionally, the hardware peripheral virtualization system 100 specifically includes a parent physical peripheral 101. The parent physical peripheral 101 is a hardware peripheral entity built into a multi-core SOC chip, integrating multiple independent physical channels with hardware-level isolation capabilities. Each physical channel is separated from the others in terms of address space, interrupt lines, and register configuration, and there is no cross-access or signal interference. Each physical channel corresponds to a unique sub-physical device, which is a software-mapped entity of the physical channel and only has hardware access permissions for the corresponding physical channel. Multiple physical channels share some hardware resources of the parent physical peripheral 101, including shared hardware resources such as a global clock unit, an electromagnetic interference suppression unit, and a bus arbitration unit. These shared resources are uniformly scheduled and managed by the system.

[0097] Optionally, the hardware peripheral virtualization system 100 further includes a kernel-mode driver module 102. The kernel-mode driver module 102 is deployed at the operating system kernel layer and establishes a communication connection with the parent physical peripheral 101. The communication interface includes a chip-embedded bus interface and a hardware register configuration interface. The kernel-mode driver module 102 is the core management unit of the system. It is used to execute the hardware peripheral virtualization method provided in any embodiment of this application, and can complete process operations such as configuration information parsing, hardware isolation rule configuration, sub-device and device file node creation, container isolation allocation, access permission verification, address validity verification, unauthorized access interception, and shared hardware resource scheduling, providing containers with pass-through access capabilities to hardware peripherals.

[0098] The hardware peripheral virtualization system 100 combines the hardware isolation of the parent physical peripheral 101 with the software management capabilities of the kernel-mode driver module 102 to achieve a hardware-software collaborative virtualization architecture. It can ensure isolated access and high-performance operation of multiple containers to hardware peripherals without relying on chipset-level hardware-assisted virtualization units, and has the characteristics of low cost, high compatibility and high stability.

[0099] Please see Figure 8 The parent physical peripheral 101 also includes a hardware configuration and isolation unit 1011 and a shared hardware resource pool 1012. The hardware configuration and isolation unit 1011 is used to configure independent address mappings, dedicated interrupt routes, and access permissions for each physical channel, and to verify the legitimacy of hardware access requests in real time, intercepting unauthorized access between physical channels. The shared hardware resource pool 1012 is shared by multiple physical channels and is configured and managed by the kernel-mode driver module 102.

[0100] Optionally, the hardware configuration and isolation unit 1011 is a core component for hardware-level isolation and control, integrated within the parent physical peripheral 101, and possesses independent configuration and verification capabilities. Its core functions include: configuring independent address mapping relationships for each physical channel, dividing the physical address space of each physical channel; allocating dedicated interrupt routes for each physical channel to achieve independent transmission and directed response of interrupt signals, avoiding interrupt interference, preemption, and false triggering between channels at the hardware level; and configuring hardware access permissions for each physical channel, limiting the operational scope and resource boundaries of each channel. Furthermore, the hardware configuration and isolation unit 1011 can perform real-time verification of the legality of all hardware access requests entering the parent physical peripheral 101. When abnormal behaviors such as unauthorized access or illegal address read / write are detected between physical channels, hardware-level instruction interception is executed to block abnormal data interaction, achieving strong isolation protection for multiple physical channels from the hardware level.

[0101] Optionally, the shared hardware resource pool 1012 provides common hardware support for multiple physical channels, integrating hardware resources that need to be shared by multiple physical channels, specifically including shared hardware modules such as a global clock unit, an electromagnetic interference suppression unit, a bus arbitration unit, and a global power supply management unit. The shared hardware resource pool 1012 is uniformly configured, parameter adjusted, and scheduled by the kernel-mode driver module 102. The kernel-mode driver module 102 dynamically allocates shared resources and configures resource working parameters according to the service type, priority, and operating status of each physical channel, ensuring that shared resources provide services to all physical channels in an orderly and efficient manner, avoiding conflicts or preemption when multiple channels share resources, and ensuring the overall stable operation of the system.

[0102] The hardware configuration and isolation unit 1011 provides hardware-level isolation and control, the shared hardware resource pool 1012 provides unified scheduling and management, and the kernel-mode driver module 102 provides software control capabilities, forming a software-hardware collaborative closed loop. This significantly improves the system's isolation security, resource utilization, and hardware access efficiency while minimizing hardware modifications, perfectly adapting to the container-level hardware peripheral virtualization requirements in multi-core SOC chip scenarios.

[0103] As can be seen, the hardware peripheral virtualization system 100 provided in this application embodiment undertakes isolation work such as address mapping, interrupt routing, and permission configuration through hardware configuration and isolation unit 1011, achieving strong isolation protection with hardware as a fallback, effectively improving security and anti-interference capabilities. Meanwhile, the shared hardware resource pool 1012 is uniformly configured and scheduled by the kernel-mode driver module 102, and can dynamically allocate resources according to container service priority and physical channel load, avoiding problems such as resource contention, timing disorders, or conflict stuttering during multi-channel concurrent access, ensuring the smoothness and reliability of multi-container services running in parallel.

[0104] In one specific embodiment of this application, the application scenario is described using a smart cockpit domain control system with four independent screens. The hardware architecture of the hardware peripheral virtualization system 100 adopts an automotive-grade multi-core smart cockpit system-on-a-chip (SOC). The SOC has a built-in display controller as the parent physical peripheral 101, which natively integrates four independent physical display channels that are hardware isolated from each other. Each channel corresponds to a different specification of in-vehicle display screen, and the specific mapping relationship is as follows: Channel CH0 corresponds to a 12.3-inch full LCD instrument panel, mainly used to display core data of the in-vehicle instrument such as vehicle speed, RPM, and alarm information, requiring the highest functional safety and real-time performance; Channel CH1 corresponds to a 14.6-inch central control touch screen, used to run core cockpit services such as vehicle control, navigation, and multimedia, and needs to support touch interaction and high-resolution display; Channel CH2 corresponds to a 12.3-inch passenger entertainment screen, mainly used to play entertainment content such as videos and audios, requiring high display smoothness; Channel CH3 corresponds to a 10.25-inch rear headrest screen, used for entertainment display for rear passengers, and supports multi-format video playback.

[0105] Among them, the above four physical channels share some hardware resources of the parent physical peripheral 101, including the global clock unit, electromagnetic interference suppression unit, and bus arbitration unit. These shared resources are uniformly configured and scheduled by the kernel-mode driver module 102 to ensure the stability and security of multi-channel concurrent access.

[0106] Furthermore, the software architecture of the hardware peripheral virtualization system 100 adopts the Linux 5.10 automotive-grade kernel and deploys four completely isolated service containers. Each container is bound to a physical channel, and the services in each container run independently without interfering with each other, meeting automotive-grade functional safety requirements. The specific binding relationships are as follows: Container A is the in-vehicle instrument safety container, bound to the CH0 channel, running instrument display-related services and having the highest service priority; Container B is the central control vehicle control service container, bound to the CH1 channel, running core services such as navigation and vehicle control settings; Container C is the passenger entertainment container, bound to the CH2 channel, running entertainment services such as online video and audio playback; Container D is the rear entertainment container, bound to the CH3 channel, running services such as children's animation and video-on-demand.

[0107] Furthermore, the kernel-mode driver layer is the only software layer with permission to access the global configuration and shared resources of the parent physical peripheral 101, and it is divided into two core modules: the parent physical peripheral 101 main control driver module and the child device abstract driver module.

[0108] Among them, the parent physical peripheral 101 main control driver module is the only software entity with permission to access the display output shared hardware resource pool 1012 and the hardware configuration and isolation unit 1011. Its core functions include completing the global initialization of the display output hardware during the system power-on phase, unified configuration and scheduling of the shared resource pool, resource allocation and isolation rule configuration of the 4 physical channels, hardware anomaly handling and full-link status monitoring.

[0109] The sub-device abstract driver module is implemented based on the Linux kernel standard character device driver model. It creates corresponding independent sub-device file nodes for each of the four physical channels CH0-CH3, with each device file strongly bound to a unique physical channel and device number. Core functions include access control for sub-devices, hardware interrupt routing and forwarding, and user-space memory mapping capabilities for physical register space.

[0110] Furthermore, the container adaptation and isolation layer is implemented based on the standard isolation mechanism native to Linux containers, without requiring modification to the core logic of mainstream containers, and is compatible with the existing automotive container ecosystem. The user-space driver layer within the container runs as sub-device function drivers within each business container. It runs in the isolated environment of the container, only aware of the dedicated sub-device files allocated within the container, and is unaware of the parent peripheral main control driver, global hardware configuration, and the existence of other channels or containers.

[0111] Please see Figure 10 . Figure 10 The architecture provided in this application serves as the core hardware carrier of the parent physical peripheral 101 in this embodiment. Its specific structure and module functions are as follows: The left side is the expandable interface master device, which acts as the main control interface for data input, providing a high-speed data reading channel for the entire display controller. The expandable interface master device connects to two sets of read arbiters, used to arbitrate and schedule read requests for multiple data streams. The upper read arbiter connects to Cursor Channel 0, Video Channel 0, Overlay Channel 0, and Overlay Channel 1; the lower read arbiter connects to Video Channel 1, Overlay Channel 2, Overlay Channel 3, and Cursor Channel 1. These channels are independent processing paths for display data, processing cursor, video stream, and multi-layer overlay data respectively. All channel data is input to the Layer Allocation module, which completes the compositing and allocation of each layer.

[0112] Furthermore, the layer allocation module output is connected to two display processing units: Display Panel Channel 0 (Panel 0) and Display Panel Channel 1 (Panel 1). Each display panel unit corresponds to an interface module: Interface 0 (Interface 0, Intf 0) and Interface 1 (Interface 1, Intf 1), used to adapt to different physical display interfaces. Simultaneously, Display Panel Channel 0 is connected to Write Back Channel 0, and Display Panel Channel 1 is connected to Write Back Channel 1, supporting write-back processing of screen data to achieve special display effects or debugging functions.

[0113] Furthermore, the output interfaces of the two display panel units are further connected to external display interface modules, including: Low-Voltage Differential Signaling (LVDS (2)) supporting two channels, Mobile Industry Processor Interface (MIPI (2)) supporting two channels, and Complementary Metal-Oxide-Semiconductor (CMOS) interface, to adapt to different types of automotive display screens.

[0114] Furthermore, the Timing Management Unit Configuration (TMU_CFG) module at the bottom serves as a global configuration module, providing unified configuration of timing, clock, and functional parameters for all the aforementioned modules, ensuring the coordinated operation and stable functioning of the entire display controller.

[0115] Furthermore, in this embodiment, the hardware peripheral virtualization method includes the following specific implementation steps: S1. Power-on of parent peripheral hardware and initialization of kernel main control driver; Specifically, this step inputs the system power-on reset signal, kernel boot image, and display output (VO) device tree configuration information, including the hardware base address of 4 physical channels, dedicated interrupt number, shared resource register address, and total hardware bandwidth parameters.

[0116] The process in this step includes: After the system powers on, the VO display controller completes a hardware reset and enters the default standby state. After the kernel completes the basic boot, it loads the VO parent peripheral master control driver module. The VO parent peripheral master control driver parses the device tree configuration to obtain the global hardware base address of the VO parent device, the independent register base addresses of the four channels, the shared resource register addresses, and the total available bandwidth specifications of the VO hardware. The driver performs global initialization of the hardware configuration and isolation unit 1011, configuring independent address access ranges and dedicated interrupt lines for each of the four channels to ensure that no channel can access the registers and hardware resources of other channels, achieving complete isolation of the four channels at the hardware level. The driver initializes the shared hardware resource pool 1012, configuring the default frequency of the phase-locked loop (PLL) clock, electromagnetic interference suppression parameters, and the basic weight of bus arbitration, enabling the VO hardware to enter normal working state. After the driver completes initialization, it registers the VO master control device node with the kernel. This node is only accessible in kernel mode and is completely shielded from user mode and all containers.

[0117] Furthermore, this step outputs the initialized VO display hardware, the running instance of the VO parent peripheral main controller driver, the hardware isolation configuration table for the 4 channels, and the initialization parameter set for the shared resource pool.

[0118] S2, Sub-device abstract driver initialization and device node creation; Specifically, this step involves inputting the 4-channel hardware isolation configuration table, the VO parent peripheral controller driver instance, and the total number of physical channels.

[0119] The process in this step includes: the VO parent peripheral controller driver calls the child device abstraction driver module to create independent child device instances for the four physical channels CH0-CH3. A unique device number is assigned to each child device; the major device number is uniformly assigned by the kernel, and the minor device number corresponds one-to-one with the physical channel number, achieving a strong binding between the child device and the physical channel. Based on the Linux standard character device model, corresponding device file nodes are created for the four child devices: / dev / vo0 (corresponding to CH0), / dev / vo1 (corresponding to CH1), / dev / vo2 (corresponding to CH2), and / dev / vo3 (corresponding to CH3). Default root access permissions are configured for all device files; subsequently, the container layer will assign dedicated access permissions based on business configurations. Standard file operation interfaces are also implemented for each child device.

[0120] Furthermore, this step outputs four device file nodes that are bound one-to-one with the physical channel, a sub-device-physical channel mapping table, and an example of the sub-device standard file operation interface.

[0121] S3. System ready state configuration complete; Specifically, this step involves inputting the set of sub-device file nodes and the sub-device-physical channel mapping table.

[0122] This step involves the following processes: The kernel completes full device driver initialization, enters user-mode runtime, and starts the Docker container runtime service. The Docker service loads the container service configuration files, confirms the exclusive access permissions for the four containers: container A can only access / dev / vo0, container B can only access / dev / vo1, container C can only access / dev / vo2, and container D can only access / dev / vo3, while pre-configuring bandwidth quotas for the four channels. The system completes the full initialization process, enters the peripheral virtualization ready state, and awaits container creation and service access requests.

[0123] Furthermore, this step outputs the ready-to-use operating system and container runtime environment, as well as the peripheral access permission configuration table for the four containers.

[0124] S4. Container creation and sub-device permission allocation; Specifically, this step involves inputting the container peripheral access permission configuration table and the set of sub-device file nodes.

[0125] The process in this step includes: powering on and starting the cockpit system; and the Docker service creating four business containers (Container A, Container B, Container C, and Container D) sequentially according to the configuration. For each container, Docker creates a dedicated device namespace based on the Linux namespace mechanism, mounting only the sub-device files allocated to that container to the ` / dev` directory within the container, completely shielding the device files of the other three channels from the VO master device node, achieving complete isolation of device access between containers. Docker configures resource quotas for each channel based on the cgroup mechanism: allocating higher bandwidth limits to the instrument and central control channels according to business priority, matching the bandwidth requirements of the passenger and rear channels to the entertainment scenarios, while limiting the maximum interrupt frequency of each channel to avoid interference between different services. After completing the resource configuration, Docker starts the system environment and business processes of the four containers, with each container only able to see the sub-device files allocated to it.

[0126] Furthermore, this step outputs the four running service container instances, the exclusive sub-device access permissions for each container, and the resource quota configuration parameters for the four channels.

[0127] S5, Loading of sub-device function drivers within the container; Specifically, this step involves inputting a running container instance and the unique sub-device file for each container.

[0128] The process in this step includes: After the four containers start, they load the display function drivers for their respective services: Container A loads the instrument display driver, Container B loads the central control display driver, Container C loads the passenger entertainment display driver, and Container D loads the rear entertainment display driver. Each driver is only aware of the sub-device files allocated within the container and is completely unaware of the parent device driver, other channels, and other containers. The display driver within each container calls the open interface to access the sub-device files within the container. After the kernel-mode sub-device abstraction driver completes the permission verification, it returns the corresponding file descriptor to the driver within the container. The driver in each container calls the memory mapping interface through the file descriptor to directly map the register space of the corresponding physical channel to the user-mode virtual address space within the container. After mapping, the driver can directly read and write hardware registers within the container without entering kernel mode and without context switching overhead.

[0129] Furthermore, this step outputs the sub-device file descriptor, the user-mode direct mapping address of the physical channel register, and the ready-to-use sub-device function driver for each container.

[0130] S6. The business process inside the container initiates a request to access a peripheral device. Specifically, this step involves inputting the ready-state sub-device function driver and the user-state register mapping address.

[0131] The processing steps in this step include: the business processes within the four containers generate display frame data for their respective business functions: Container A generates instrument UI frames containing vehicle speed, RPM, and alarm information; Container B generates central control UI frames for vehicle control and navigation interfaces; Container C generates online video playback screens; and Container D generates children's animation playback screens. The display driver for each container performs a validity check on the frame parameters, confirming that the resolution and frame rate match the hardware specifications of the corresponding channel. After successful verification, the frame data buffer is mapped to contiguous physical memory via DMA, preparing for hardware access.

[0132] Furthermore, this step outputs the four verified display service requests and the physical memory buffer address of the corresponding frame data for each channel.

[0133] S7, Direct Configuration of Physical Channel and Startup of Data Transmission; Specifically, this step involves inputting the service request parameters, the physical memory address of the frame data, and the user-mode register mapping address.

[0134] The process in this step includes: the display driver within each container directly configures the registers of the corresponding channel through the user-mode mapping address within the container. This entire process is completed in user mode within the container, without entering kernel mode and without any software forwarding overhead. The frame data buffer address, screen resolution, screen output format, frame rate control parameters, and layer overlay parameters are configured sequentially. After all registers are configured, the driver writes a startup command to the startup control register of the corresponding channel, triggering the hardware processing pipeline to start. The configuration and startup operations of the four channels are completely independent and do not affect each other. After receiving the startup command, the hardware directly reads the frame data from the corresponding physical memory address through the DMA controller and enters the hardware processing pipeline, without the Central Processing Unit (CPU) participating in data transfer throughout the entire process.

[0135] Furthermore, this step outputs the configured four physical channel hardware, the started four hardware data processing pipeline, and frame data read requests.

[0136] S8, Hardware Data Processing and Channel Isolation Execution; Specifically, this step involves inputting the frame data read request, channel configuration parameters, and shared resource pool initialization parameter set.

[0137] The processing in this step includes: the hardware pipelines of the four channels perform full-process processing on the corresponding frame data, completing operations such as layer overlay, cursor rendering, image format conversion, and EMI suppression, ultimately generating the output signal for the corresponding screen. During processing, the hardware isolation unit verifies the address validity of each hardware access request in real time, allowing only the channel to access its own valid address range. Any unauthorized access will be directly blocked by the hardware, ensuring complete isolation of the hardware processing of the four channels and preventing mutual interference. During processing, the four channels directly use the shared clock and EMI parameters configured by the parent driver during the initialization phase, without the need for driver intervention within the container or real-time processing in kernel mode. After the hardware completes processing, each channel outputs the processed display signal to the corresponding physical screen interface, completing the display output of a single frame.

[0138] Furthermore, this step outputs the display output signals of the four screens, the single-frame processing completion flag, and the status register update values ​​of the four channels.

[0139] S9. Complete the interruption report and container response; Specifically, this step involves inputting the frame processing completion flag and the corresponding physical channel number.

[0140] The processing steps in this step include: After each channel completes single-frame processing, a dedicated independent hardware interrupt is triggered. The interrupt signal is routed only to the interrupt handler function of the corresponding CPU core and kernel-mode sub-device driver. The four interrupts are completely independent and do not interfere with each other. The kernel-mode interrupt handler function only performs the most basic interrupt confirmation and clearing operations, without any business logic processing. Through the standard event notification mechanism, the interrupt event is directly forwarded to the display driver in the corresponding container. After receiving the interrupt notification, the driver in each container directly reads the status register of the corresponding channel through the user-mode mapped address in the container, confirms that the frame display is complete, and reports the result to the business process in the container.

[0141] Furthermore, this step outputs the hardware processing completion event and frame transmission completion confirmation signal received by each container.

[0142] S10, Loop processing of continuous service flows; Specifically, this step involves receiving a confirmation signal indicating completion of frame transmission and a continuous frame data request from the service process within the container.

[0143] The processing steps in this step include: after receiving the frame completion signal, each service process within the container generates the service screen data for the next frame and initiates display requests in a loop. All four service channels repeatedly execute steps S7 to S9 to achieve continuous and stable screen display. Throughout the entire loop, except for interrupt notifications, all hardware configuration and status query operations are completed directly in user space within the container, without kernel-mode context switching overhead. The service loops of the four channels are completely independent; fluctuations in the service of any one channel will not affect the display stability of the other channels, meeting the functional safety requirements of security scenarios such as instrumentation.

[0144] Furthermore, this step outputs a continuous and stable display stream across four screens, along with low-latency service processing results.

[0145] S11, Access request to shared hardware resources is triggered; Specifically, this step involves inputting the special business requests of the business processes within the container and the sub-device function driver instances.

[0146] The process in this step includes: the central control business process of container B initiates a navigation screen resolution switching request, which needs to switch from 1080P@60fps to 4K@60fps. This operation requires adjusting the global PLL clock frequency of VO. However, the PLL clock is a shared hardware resource shared by four channels and cannot be configured through the independent register of the CH1 channel. Therefore, the shared resource scheduling process is triggered.

[0147] Furthermore, this step outputs a shared hardware resource access request and a set of PLL clock frequency adjustment parameters.

[0148] S12, Explicit request processing for shared resources; Specifically, this step involves inputting a shared resource access request, a PLL adjustment parameter set, and the file descriptor of container B.

[0149] The process in this step includes: Container B's display driver recognizes the request as a shared resource adjustment request, which cannot be completed directly through user space. Using a standard system call interface, it sends the PLL adjustment request and parameters to the kernel-level VO parent peripheral controller driver via the dedicated interface / dev / vo1. Upon receiving the request, the parent driver performs a three-level validity check: first, it checks if the CH1 channel corresponding to Container B has permission to request PLL clock adjustment; second, it checks if the requested clock frequency is within the valid hardware specifications; and finally, it checks whether the frequency adjustment will affect the normal display output of the other three channels. After all checks pass, the parent driver directly configures the PLL registers of the shared resource pool to complete the clock frequency adjustment. After configuration, the parent driver returns the execution result to Container B's driver, which then reports the result to the central control business process to complete the resolution switching.

[0150] Furthermore, this step outputs the adjusted PLL clock configuration, the request execution result feedback, and the updated shared resource pool parameter set.

[0151] S13, Implicit handling of shared resources; Specifically, this step involves inputting VO hardware operating status monitoring data, the VO parent peripheral main controller driver instance, and the shared resource pool configuration parameter set.

[0152] The process in this step includes: the VO parent peripheral controller driver continuously monitors the hardware operating status in kernel mode, including SOC temperature, VO bus load, shared resource utilization, and the operating status of the four channels. When the driver detects that the SOC temperature exceeds the automotive-grade safety threshold, it needs to perform frequency reduction protection. Without any container initiating a request, the implicit adjustment process of shared resources is automatically triggered. The driver first verifies the parameters after frequency reduction to ensure that the adjusted clock frequency still meets the minimum service frame rate requirements of the four channels, without causing any service interruption, especially ensuring the safe and stable display of the instrument channel. After the verification is passed, the driver directly adjusts the shared PLL clock frequency to complete the frequency reduction operation. At the same time, through the interrupt notification mechanism, the frequency adjustment event is synchronized to the drivers in the four containers to ensure that the service process adapts to the new clock parameters and ensures the stability of the four-screen display.

[0153] Furthermore, this step outputs optimized shared resource configuration, hardware temperature safety assurance, and synchronized notifications of adjustment events.

[0154] S14. Container service cessation and resource release; Specifically, this step involves inputting a vehicle shutdown command, a request to stop the business process within the container, and a file descriptor and user-space mapping address.

[0155] The process in this step includes: After the vehicle is turned off, the business processes of the four containers stop running sequentially according to priority. Each container's display driver first releases the user-mode address mapping of the corresponding channel register. Each driver calls the shutdown interface to close the file descriptor of the corresponding sub-device, and the kernel-mode sub-device abstraction driver cleans up kernel-mode resources such as interrupt routes and event notifications for the corresponding channel. The four containers complete the release of all resources in sequence, and the driver exits operation.

[0156] Furthermore, this step outputs the released user-mode address space, the closed sub-device file descriptors, and the cleaned-up sub-device kernel-mode resources.

[0157] S15, Container Destruction and Global Resource Recycling; Specifically, this step involves inputting a container destruction request, the cleaned-up sub-device resources, and resource quota configurations.

[0158] The process in this step includes: The Docker service receives the container destruction command when the vehicle is powered down, destroys the four containers sequentially according to priority, unmounts the corresponding sub-device files for each container, and clears the corresponding cgroup resource quota configurations. Docker marks all four physical channels CH0-CH3 as idle and notifies the VO parent peripheral controller driver. The parent driver restores all registers of the four channels to their default configuration state, clears the channel permission configurations, and the VO hardware returns to standby mode, waiting for container allocation and use after the system powers on again. After the entire process is completed, the system returns to the peripheral virtualization ready state, and steps S4 to S15 can be repeated to provide peripheral virtualization services for new containers.

[0159] Furthermore, this step outputs the destroyed container instance, the four idle physical channels, and the ready system virtualization environment.

[0160] This embodiment, through the aforementioned hardware architecture, software architecture, and timing processing flow, achieves hardware peripheral virtualization in a smart cockpit four-screen independent display scenario. It utilizes a minimally optimized adaptation based on the SOC's native VO display controller IP core, eliminating the need for additional CPU / chipset-level hardware-assisted virtualization units. This ensures compatibility with automotive-grade hardware platforms and minimizes hardware modifications. Simultaneously, hardware-level isolation of physical channels is achieved through hardware configuration and isolation unit 1011. Combined with container isolation mechanisms, complete isolation between containers is achieved, preventing unauthorized access and business interference. Furthermore, user-mode memory mapping enables direct reading and writing of hardware registers by containers, eliminating kernel-mode context switching and software forwarding overhead, achieving access performance close to direct physical hardware connection, meeting the real-time requirements of four-screen display. Resource reuse is achieved through a shared hardware resource pool 1012, uniformly scheduled by the kernel-mode driver module 102, avoiding resource contention and improving hardware resource utilization. Moreover, the parent device driver and the child device driver within the container are completely decoupled, maintaining stable adaptation across hardware versions, thus effectively ensuring compatibility with the existing automotive container ecosystem.

[0161] In this application, the terms "embodiment" and "implementation" mean that a specific feature, structure, or characteristic described in connection with an embodiment can be included in at least one embodiment of this application. The appearance of these phrases in various locations throughout the specification does not necessarily refer to the same embodiment, nor are they independent or alternative embodiments mutually exclusive with other embodiments. Those skilled in the art will understand, explicitly and implicitly, that the embodiments described in this application can be combined with other embodiments. Furthermore, it should be understood that the features, structures, or characteristics described in the various embodiments of this application can be arbitrarily combined to form another embodiment that does not depart from the spirit and scope of the technical solution of this application, provided there is no contradiction between them.

[0162] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application and are not intended to limit it. Although this application has been described in detail with reference to the above preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions to the technical solutions of this application should not depart from the spirit and scope of the technical solutions of this application.

Claims

1. A hardware peripheral virtualization method, characterized in that, The method is applied to the kernel-mode driver module of a hardware peripheral virtualization system, and the method includes: Obtain hardware configuration information and container allocation configuration information, parse the hardware configuration information and container allocation configuration information to obtain peripheral channel parameters, shared resource parameters and container binding parameters; Based on the peripheral channel parameters and the shared resource parameters, hardware isolation rules are configured for multiple physical channels in the parent physical peripheral. The parent physical peripheral is a peripheral entity that integrates multiple mutually hardware-isolated physical channels and the multiple physical channels share some hardware resources. According to the hardware isolation rules, a corresponding sub-device is created for each physical channel, and a corresponding sub-device file node is created for each sub-device; According to the container binding parameters, the sub-device file nodes are allocated to the corresponding containers in an isolated manner, so that each container can only access the sub-device file nodes allocated to it. The container is controlled to directly access the corresponding physical channel through the sub-device file nodes and schedule the shared hardware resources of the parent physical peripheral, thereby realizing the isolated virtualization sharing of hardware peripherals by the container.

2. The hardware peripheral virtualization method as described in claim 1, characterized in that, The step of allocating the sub-device file nodes to corresponding containers in an isolated manner according to the container binding parameters, so that each container can only access the sub-device file nodes assigned to it, and controlling the containers to directly access the corresponding physical channels through the sub-device file nodes, includes: The binding relationship between the target container and the sub-device file node is determined based on the container binding parameters, and an independent device namespace is created for the target container according to the binding relationship; The sub-device file node corresponding to the target container is mounted to the independent device namespace to obtain an isolated container environment with a dedicated sub-device file node. Based on the isolated container environment, the target container's access permissions to other sub-device file nodes except for the dedicated sub-device file node are blocked, forming a container-specific node access permission, so that each container can only access the sub-device file nodes assigned to it. Based on the container-specific node access permissions, a dedicated hardware access link is established for the target container to directly access the corresponding physical channel through the dedicated sub-device file node, and the container is controlled to directly access the corresponding physical channel through the dedicated sub-device file node.

3. The hardware peripheral virtualization method as described in claim 2, characterized in that, The step of determining the binding relationship between the target container and the sub-device file node based on the container binding parameters, and creating an independent device namespace for the target container according to the binding relationship, includes: Based on the container binding parameters, the target container is matched with the corresponding sub-device file node, and the binding relationship between the target container and the sub-device file node is determined and generated; Based on the binding relationship, the container independent namespace mechanism is invoked to create a dedicated device namespace for the target container; Configure access isolation rules for the dedicated device namespace to prevent permission overlap between the dedicated device namespace and the device namespaces of other containers, thus creating an independent device namespace.

4. The hardware peripheral virtualization method as described in claim 3, characterized in that, The access isolation rules include: Within the dedicated device namespace, only the dedicated child device file node corresponding to the target container is retained, while the master control device node of the parent physical peripheral and other child device file nodes are hidden.

5. The hardware peripheral virtualization method as described in claim 2, characterized in that, The control container directly accesses the corresponding physical channel through a dedicated sub-device file node, including: The hardware access requests for the container are verified through the dedicated sub-device file node. Once the permission verification is successful, the control container directly accesses the corresponding physical channel and maps the register space of the corresponding physical channel to the user-mode virtual address space of the container, enabling the container to directly read and write the register data inside the physical channel at the user-mode level.

6. The hardware peripheral virtualization method as described in claim 1, characterized in that, The step of configuring hardware isolation rules for multiple physical channels in a parent physical peripheral based on the peripheral channel parameters and the shared resource parameters includes: Based on the peripheral channel parameters and shared resource parameters, obtain the basic hardware configuration information of multiple physical channels in the parent physical peripheral to obtain the physical channel hardware configuration baseline data; Based on the physical channel hardware configuration baseline data, an independent address access range is allocated to each physical channel to obtain the physical channel parameters configured with an independent address access range; Based on the physical channel parameters, a dedicated interrupt line is assigned to each physical channel, and an independent register base address is assigned to each physical channel, forming a hardware isolation rule for multiple physical channels in the parent physical peripheral.

7. The hardware peripheral virtualization method as described in claim 6, characterized in that, The step of creating a corresponding sub-device for each physical channel and a corresponding sub-device file node for each sub-device according to the hardware isolation rules includes: According to the hardware isolation rules, a device number is assigned to each physical channel through the kernel standard character device model, and the device number is bound to the physical channel number to form a channel device binding relationship. Based on the channel device binding relationship, a sub-device corresponding to each physical channel is created, and a corresponding sub-device file node is created for each sub-device.

8. The hardware peripheral virtualization method as described in claim 6, characterized in that, After allocating a dedicated interrupt line for each physical channel and an independent register base address for each physical channel, the method further includes: It verifies the address validity of all access requests in real time, intercepts unauthorized access operations between physical channels, and achieves hardware-level isolation of multiple physical channels.

9. A hardware peripheral virtualization system, characterized in that, The hardware peripheral virtualization system includes: The parent physical peripheral integrates multiple hardware-isolated physical channels, each physical channel corresponding to a child physical device, and the multiple physical channels share some hardware resources; A kernel-mode driver module, which is communicatively connected to the parent physical peripheral, is used to execute the hardware peripheral virtualization method according to any one of claims 1 to 8.

10. The hardware peripheral virtualization system as described in claim 9, characterized in that, The parent physical peripheral also includes: The hardware configuration and isolation unit is used to configure independent address mapping, dedicated interrupt routing and access permissions for each physical channel, and to verify the legality of hardware access requests in real time and intercept unauthorized access between physical channels. A shared hardware resource pool is provided for use by multiple physical channels and is configured and managed by the kernel-mode driver module.

Images