A cross-system USB high-performance transmission method based on hierarchical linkage shared memory pool

Abstract

The application discloses a cross-system USB high-performance transmission method based on a hierarchical linkage shared memory pool, a container application initiates a USB access request, a container business unit adds a pass-through identifier, and encapsulates a cross-kernel request and sends the cross-kernel request to a host; the host enumerates a device, collects a device descriptor and hardware resources, and after completing permission verification, sends a response packet with an exclusive token; the container creates a virtual USB node and binds the hardware resources; the host pass-through module locks the device for the container, constructs a hierarchical linkage shared memory pool according to batch, isochronous and interrupt hierarchical configuration parameters, and allocates physical memory, completes double-kernel address mapping to generate an address comparison table, and synchronizes memory configuration to the container; when the application initiates transmission, the business unit identifies the transmission type, applies for memory through an optimal size matching strategy based on the hierarchical memory pool and maps the memory to an application user state; when data is sent, the application writes in shared memory, the container encapsulates a transmission task packet and sends the transmission task packet to the host pass-through module to complete hardware transmission.

Description

Technical Field

[0001] This invention belongs to the field of computer software development technology, specifically relating to a cross-system USB high-performance transmission method based on a hierarchical linked shared memory pool. Background Technology

[0002] In a layered virtualization architecture consisting of a host operating system and client containers or virtual machines, when client applications access physical USB hardware through device emulation and user-space proxy forwarding, the overall transmission throughput and real-time response stability are far lower than in the native direct connection mode. This performance gap has become one of the main bottlenecks for containerized applications of large-volume USB services.

[0003] The existing approach suffers from the following technical problems: First, redundant transmission paths. Data transmission requires passing through USB physical hardware, the host kernel USB driver, the host user-mode forwarding agent process, the container kernel, the container USB subsystem, and the container application. Each layer of forwarding triggers kernel-to-user mode switching and independent memory buffer copying operations. The memory copying overhead alone causes significant bandwidth loss after multiple layers are stacked. Second, resource scheduling conflicts. The USB controller DMA transmission channel, hardware interrupt channel, and CPU computing core are all system-wide shared resources without virtualization-level exclusive isolation. The host native program or other parallel containers can preempt the hardware and computing resources required for transmission, leading to large fluctuations in transmission rate and unstable bandwidth output. Third, the USB transmission protocol lacks a unified forwarding strategy, resulting in a lack of differentiation. The existing forwarding layer uses a unified transmission strategy, which is not adapted to the different USB transmission types that container applications rely on. This may lead to frequent data packet retransmissions, further reducing transmission efficiency. Fourth, there is interrupt response latency. USB hardware interrupt signals need to be forwarded layer by layer, from the hardware controller, host kernel, user-space forwarding agent, container kernel, container kernel interrupt service, and finally to the container application business thread. The multi-layer forwarding and context switching overhead significantly increase the interrupt response time, making it difficult to meet the requirements of low-latency real-time services. Fifth, the memory scheduling efficiency is low. Cross-domain shared memory adopts a fixed capacity and fixed block design, which makes it difficult to dynamically adjust the memory allocation specifications according to the bandwidth of different USB device endpoints and the length of single data blocks of services. This leads to memory waste or frequent expansion, and additional transmission waiting latency.

[0004] In summary, existing optimization approaches all focus on tuning parameters at the forwarding proxy layer, such as expanding the forwarding buffer, increasing the system scheduling priority of the proxy process, and statically fixing USB protocol configurations. These approaches can only slightly alleviate performance issues and cannot bring the USB transmission performance within the container close to the native level. Summary of the Invention

[0005] In view of this, the present invention provides a cross-system USB high-performance transmission method based on a hierarchical linked shared memory pool. Through cross-kernel communication between the container and the host kernel, USB device permission verification, exclusive hardware binding, hierarchical construction of shared memory pools and address mapping according to transmission modes, and zero-copy DMA hardware transmission mechanism, it realizes secure exclusive pass-through access of containers to physical USB devices, efficient data transmission and reception, and automatic recycling management of transmission resources.

[0006] This invention provides a cross-system USB high-performance transmission method based on a hierarchical linked shared memory pool, which specifically includes the following steps:

[0007] When a container application initiates a USB device access request for the first time, the container business processing unit intercepts it, adds a pass-through access identifier, encapsulates it as a cross-kernel USB access request, and sends it to the host. The host triggers the USB controller to enumerate the target device, obtain the device descriptor set and hardware resource parameters, and store them in the USB device resource structure.

[0008] After verifying the container's USB access permissions, the host USB manager generates a response packet containing a device descriptor set, hardware resource parameters, and an exclusive access token. The container parses the response packet, creates a virtual USB device node, binds it to the controller and DMA channel, and saves the exclusive access token.

[0009] The host's container passthrough module marks the target USB device as exclusively used by the current container and binds the container identifier. It then sends hardware configuration instructions to the USB controller, enables exclusive access for the container, and sets the initial number of memory blocks and amplification factor according to three transmission modes: batch, isochronous, and interrupt. It constructs a hierarchical and interconnected shared memory pool, and obtains the required memory pool capacity by accumulating the initial number of memory blocks and the size of a single memory block, and allocates memory space. The host maps the memory pool to the host virtual address, allocates virtual address ranges for the container, binds each memory block in the memory pool to the container virtual address, configures access permissions, and generates an address lookup table that records the correspondence between physical addresses and the virtual addresses of the kernels on both sides. The host sends the memory pool configuration synchronization packet to the container, which stores it in the USB shared memory configuration cache and notifies the container's business processing unit.

[0010] When a container application initiates a USB data transfer request, the container business processing unit captures the request, determines the USB transfer mode, synchronizes the application data buffer address, and, based on the hierarchical linkage shared memory pool, uses an optimal size matching strategy to request a shared memory block and map it to the container application's user-space virtual address space corresponding to the current virtual USB device node. When the application sends data to the hardware, the data is first written to the shared memory block, and then the container business processing unit generates a transfer task packet and sends it to the host's container passthrough module to complete the transmission.

[0011] Furthermore, the size of a single memory block is calculated as the product of the maximum number of bytes that a single packet can carry at the endpoint and the amplification factor.

[0012] Furthermore, when requesting memory blocks, the size of the memory block is determined based on the transfer mode of the container application bound to the current virtual USB device node. The smallest memory block not smaller than the requested memory block size is selected first from the free memory blocks. When the capacity of a single memory block is smaller than the requested memory block size, multiple memory blocks of the same level are combined and the memory resource usage status is updated synchronously. When querying the address lookup table and converting the container kernel virtual address to a physical DMA address, the container identity is verified, and the conversion is performed only when the container's identifier matches the container identifier bound to the current virtual USB device node.

[0013] Furthermore, the method by which the container service processing unit generates a transmission task packet and sends it to the host's container pass-through module to complete the transmission is as follows:

[0014] The container passthrough module first verifies the integrity of the message, then compares the device exclusive access token in the transmission task packet with the device exclusive token cached on the host side. If the verification fails, the transmission task is directly rejected; if the verification passes, the DMA channel number bound to the virtual USB device node is read, the corresponding channel is bound, the DMA channel parameters are configured, a zero-copy URB software request block is constructed, and the DMA controller and the zero-copy URB complete the data transmission. The DMA controller marks the DMA transmission status and records the actual number of bytes transmitted, the USB controller generates a transmission completion status, and the container passthrough module generates a transmission completion response packet and sends it to the container.

[0015] After receiving the transmission completion response packet, if it is an input transmission, the container reads the data from the shared memory mapping address and sends it to the application buffer; if it is an output transmission, no read operation is performed. After the transmission is completed, the memory lock is released, the memory block is reset to an idle state and returned to the hierarchical memory pool. When the application closes the virtual USB device node file descriptor, hardware and memory resources are released, and the host synchronously removes the physical device exclusive mark.

[0016] Furthermore, the data transmission method completed by the DMA controller and the zero-copy URB is as follows: during outbound transmission, the USB hardware receives the scheduling task and triggers the DMA controller, which reads the original data in batches from the shared physical memory according to the scattering list, completes the USB packetization by the internal hardware cache, and then sends it to the peripheral device through the bus; during inbound transmission, the peripheral device returns the data and stores it in the USB hardware receive cache, and the DMA controller writes the data to the designated shared physical memory area.

[0017] Furthermore, the container service processing unit requests shared memory blocks according to the USB transmission mode, specifically: allocating a first-level memory block for batch transmission, a second-level memory block for isochronous transmission, and a third-level memory block for interrupt and control transmission; calculating the required number of memory blocks according to the data memory pool capacity, and completing the combined allocation of multiple types of resources; then mapping the kernel-side shared memory address to the service user address space and granting read and write access permissions.

[0018] Furthermore, after binding the target USB device to the corresponding container, the container passthrough module obtains the hardware interrupt descriptor and interrupt number corresponding to the USB hardware, converts them into offsets in the container kernel virtual interrupt vector table, and generates a one-to-one binding mapping relationship between hardware interrupts, host interrupts, container virtual interrupts, and target container identifiers, which is then written into the interrupt mapping structure. The container service processing unit sets up pre-processing for hardware interrupts, including interrupt flag clearing, hardware transmission status reading, and service transmission thread wake-up, as well as post-processing for asynchronous processing, including data integrity verification, hardware error type parsing, retry of recoverable transmission tasks, memory resource status update, and service layer completion event notification. The host reads the container calculation core number, generates a core binding mask, locks all USB interrupt signals to this core for operation, disables the deep sleep mechanism of this core, and retains only the shallow sleep mode.

[0019] Furthermore, the host obtains the total number of CPU cores in the system, iterates through all CPU cores to obtain the short-term load of each core, selects idle cores with loads below a threshold, and determines the number of container cores; the binding relationship between cores and containers is written into the container configuration storage area, and all USB-related business threads and interrupt handling processes within the container are synchronously constrained to run only in that core.

[0020] Increase the scheduling priority of container USB-related application threads and configure the highest scheduling static priority weight; enable real-time preemptive scheduling mode for USB transfer applications and enable mutex priority protection mechanism; set the highest real-time access priority for memory read and write I / O operations corresponding to USB, create an independent I / O scheduling queue for container USB applications, bind the queue to the corresponding compute memory node, and configure a low-latency scheduling strategy for the queue.

[0021] The container passthrough module sends an exclusive lock command to lock the USB controller and its associated DMA channels, and sets the maximum single transfer length of the channels; it also rebinds the interrupt handling logic, shielding the host kernel's native interrupt handling path and retaining only the container kernel's interrupt response.

[0022] Furthermore, a multi-device access priority scheduling queue is initialized, storing the access subject identifier, container static priority, request initiation time, and hardware device path. When multiple containers successively or simultaneously request the same USB hardware, the requests are sorted according to the preset container static priority and request initiation time. High-priority containers have priority to obtain the right to use the device, while low-priority containers enter the waiting queue. After the current container releases the hardware, the highest-priority waiting container in the queue is woken up, and the cached USB hardware and memory mapping configuration is reused.

[0023] Furthermore, the container reads the USB device endpoint descriptor to determine whether the transfer mode is control transfer, bulk transfer, isochronous transfer, or interrupt transfer, and simultaneously obtains the hardware characteristic parameters of each transfer mode; it generates transfer characteristic information from the transfer mode type and hardware parameters, and distributes it to the container passthrough module;

[0024] When the length of an application data packet is less than the maximum number of bytes that a single hardware packet can carry, the data packet is padded and sent; a data packet merging threshold is set, and when the length of an application data packet is less than the merging threshold, the application data packet is saved to a merging buffer, and transmission is initiated when the capacity of the merging buffer is greater than the threshold or the timeout is greater than the threshold; when the length of an application data packet is greater than the maximum threshold, it is split into multiple groups of data and sent in a pipeline mode through multiple created transmission tasks.

[0025] For isochronous transmission, the hardware timing identifier is read and written to the reserved storage area of ​​shared memory, the container synchronizes the timing reference, and corrects the timing offset of audio and video frames; a frame loss tolerance threshold is configured, and frame loss interpolation compensation is performed when the transmission delay is greater than the threshold; the scheduling priority of isochronous transmission tasks is increased, the required bandwidth is calculated from the frame size and frame rate, and corresponding bandwidth resources are reserved for real-time data streams;

[0026] For interrupt transmission, read the minimum hardware reporting interval and enable it, combine multiple interrupt data within the set time window and report them in batches, and configure a circular buffer to read data in batches.

[0027] For control transfers, configure the USB device with the highest scheduling priority, and merge zero-length instructions before transferring them.

[0028] Beneficial effects:

[0029] When a container application requests USB device access for the first time, the container USB service processing unit adds a unique passthrough identifier to the request. This identifier is then encapsulated by the container kernel into a cross-kernel access message and sent to the host kernel. The host kernel enumerates the target USB device, collects the device descriptor set and hardware resource parameters, and stores them in the device resource structure. After the USB manager completes permission verification, it returns a response packet carrying device information, hardware parameters, and an exclusive access token. The container kernel creates a virtual USB device node bound to physical resources and a transmission channel based on the response packet and caches the access token. Simultaneously, the host kernel updates the device occupancy status, marks the device as container-exclusive, and configures hardware switches and interrupt paths to implement device-oriented services. The host USB container passthrough driver module, based on different U... The SB transfer mode matches the corresponding amplification factor, calculates and allocates contiguous physical memory in the kernel to build a dedicated memory pool, configures memory attributes, establishes a memory pool status table and address mapping table, synchronizes memory pool configuration parameters with the container, and registers memory access interfaces. When the container application initiates a USB data transfer request, the container captures key transfer parameters, matches shared memory blocks and binds them to the application address space, encapsulates a task packet carrying a checksum and core transfer information, and sends it to the host. After the host verifies the message and access permissions, it binds the DMA channel, configures the URB to complete hardware-level data transfer, records the transfer status and actual data volume, and returns a transfer completion response. Finally, the container kernel reads the corresponding data according to the transfer type, unlocks and resets the memory block status, and completes a single USB pass-through data transfer. Attached Figure Description

[0030] Figure 1 This is a flowchart illustrating a cross-system USB high-performance transmission method based on a hierarchical linked shared memory pool, as provided by the present invention. Detailed Implementation

[0031] The present invention will be described in detail below with reference to the accompanying drawings and embodiments.

[0032] This invention provides a cross-system USB high-performance transmission method based on a hierarchical linked shared memory pool. The core idea is as follows: When a container application requests USB device access for the first time, the container's USB service processing unit adds a unique passthrough identifier to the request. The container kernel encapsulates this into a cross-kernel access message and sends it to the host kernel. The host kernel enumerates the target USB device, collects the device descriptor set and hardware resource parameters, and stores them in the device resource structure. After the USB manager completes permission verification, it returns a response packet carrying device information, hardware parameters, and an exclusive access token. The container kernel creates a virtual USB device node bound to physical resources and a transmission channel based on the response packet and caches the access token. Simultaneously, the host kernel updates the device occupancy status, marks the device as container-exclusive, and configures hardware switches and interrupt paths to implement device-oriented services. The host USB container passthrough driver module matches the corresponding amplification factor according to different USB transfer modes, calculates and allocates contiguous physical memory in the kernel to build a dedicated memory pool, configures memory attributes, establishes a memory pool status table and address mapping table, synchronizes memory pool configuration parameters with the container, and registers memory access interfaces. When the container application initiates a USB data transfer request, the container captures key transfer parameters, matches shared memory blocks and binds them to the application address space, encapsulates a task packet carrying a checksum and core transfer information, and sends it to the host. After the host verifies the packet and access permissions, it binds the DMA channel, configures the URB to complete hardware-level data transfer, records the transfer status and actual data volume, and returns a transfer completion response. Finally, the container kernel reads the corresponding data according to the transfer type, unlocks and resets the memory block status, and completes a single USB passthrough data transfer.

[0033] This invention provides a cross-system USB high-performance transmission method based on a hierarchical linked shared memory pool, the processing flow of which is as follows: Figure 1 As shown, the specific steps include:

[0034] Step 1: When the container application initiates a USB device access request for the first time, the container USB service processing unit intercepts the request and adds a unique identifier for pass-through access, which is recorded as the first identifier. The container kernel encapsulates the request into a cross-kernel USB access request message and sends the request message to the host kernel using a cross-kernel communication channel.

[0035] After the host kernel receives the request message, it triggers the USB controller to enumerate the target device. The host USB protocol stack collects the device descriptor set, including device descriptor, configuration descriptor, interface descriptor, endpoint descriptor and string descriptor. It synchronously reads the USB controller hardware register to obtain the hardware resource parameters such as the controller number, DMA channel number and hardware interrupt number corresponding to the device. If the device is online, it reads the cached device information and stores it in the host kernel's USB device resource structure.

[0036] The host's USB manager verifies the USB access permissions of the container and the container application. If the verification is successful, a permission response packet is generated, which contains the device descriptor set, hardware resource parameters, and exclusive access token.

[0037] The container kernel receives and parses the permission response packet, creates a virtual USB device node within the container kernel, and the file path of this node is completely consistent with the format of the native Android physical USB node; a physical hardware resource associated storage area is added within this virtual USB device node, and hardware parameters such as the controller, corresponding DMA transfer channel and interrupt issued by the host are bound, and file operations on this virtual USB device node are used as a unified entry point for zero-copy data transfer; and the exclusive access token carried in the response packet is stored in the USB device state cache area of ​​the container kernel.

[0038] The host kernel's USB container passthrough module updates the USB device occupancy status table, marks the target device as currently exclusively owned by the container and binds the corresponding container identifier; simultaneously, it sends controller hardware configuration instructions to the USB controller, enables the exclusive access hardware switch for the container, disables the interrupt handling path of the host native driver, and only allows hardware interrupt signals to be forwarded to the target container.

[0039] The cross-kernel USB access request message contains five types of fixed information: container unique identifier, device manufacturer code, device product code, business process identifier, and reserved extended fields.

[0040] Specifically, the host's USB manager verifies the USB access permissions of the container and its application. This includes: container instance permission verification, which reads the system container permission configuration node to verify that the target container has enabled USB passthrough access permissions; container application permission verification, which synchronously queries the container's permission management unit through the cross-instance communication channel to confirm that the application initiating the request has USB hardware access permissions; and hardware exclusivity verification, which retrieves the host's global device occupancy index table to confirm that the current target USB hardware is not occupied by other containers or the host's native services.

[0041] Step 2: The USB container passthrough driver module determines the corresponding amplification factor and initial memory block number according to the USB transmission mode based on the device descriptor set collected and synchronized to the virtual USB device node bound to the container side. For example, the amplification factor is 1024 for batch transmission, 2048 for isochronous transmission, and 512 for interrupt and control transmission. The size of a single memory block for each transmission mode is the product of the maximum number of bytes that a single packet can carry at the endpoint and the amplification factor. The total capacity of the required memory pool is obtained by adding the size of a single memory block to the initial memory block number.

[0042] The host allocates memory space in the contiguous physical memory region of the kernel according to the total capacity of the memory pool. The memory region is configured with hardware DMA access, kernel-specific and initial zeroing attributes. A memory pool status table is established to record the physical address, host virtual address, container virtual address, storage capacity, hierarchical partition type, resource occupancy status, bound container identifier, bound endpoint identifier, and concurrency mutual exclusion protection mechanism for each memory block, and a fast retrieval index is established for it.

[0043] The host maps the physical address of the memory pool to the virtual address of the host kernel, allocates a dedicated virtual address range for the container, binds the physical address of each memory block in the memory pool to the virtual address of the container one-to-one, and configures access permissions that allow reading and writing and prohibit program execution; generates an address lookup table to record the correspondence between the physical address and the virtual addresses of the kernel on both sides, performs integrity verification after mapping, and reclaims the allocated memory resources if the mapping fails.

[0044] Register memory access interfaces in the container kernel, including three types of interfaces: memory block allocation, memory block release, and address translation. When allocating resources, match the partition size of the transmission endpoint bound to the current virtual USB device node, use the optimal size matching strategy to combine multiple memory blocks, enable concurrency protection mechanism throughout the operation, and update the memory resource usage status synchronously. Add container identity verification during the address translation process, verify that the identity is consistent with the container identifier bound to the current virtual USB device node, and prohibit illegal address access across containers.

[0045] The host encapsulates parameters such as the total capacity of the memory pool, the size of each level of partition blocks, and the address mapping range into a memory pool configuration synchronization package, and sends it to the container through the cross-kernel communication channel. After receiving the package, the container stores all the configurations in the USB shared memory configuration cache and notifies the container's USB business processing unit. Subsequent applications can directly read the cached parameters when initiating transmission through the virtual USB device node.

[0046] Among them, there are three types of interfaces: memory block allocation, memory block release, and address translation. When allocating resources, the interface matches the partition specification of the transmission endpoint and uses the optimal size matching strategy to combine multiple memory blocks. The entire operation is protected by a concurrency protection mechanism and the memory resource occupancy status is updated synchronously. The address translation process adds container identity verification to prohibit unauthorized access across containers.

[0047] Furthermore, the memory pool in this invention can dynamically expand and shrink its capacity threshold. Specifically, the host coordination unit sets two levels of dynamic resource scheduling thresholds. When the proportion of idle resources in a certain level partition is lower than the first threshold, it automatically expands. The expansion capacity is a set proportion of the existing total capacity of the partition. The newly added memory block synchronously completes cross-kernel address mapping. The expansion operation does not interrupt the ongoing data transmission. Memory blocks that are in use or associated with the corresponding virtual USB device node transmission session are marked as locked. When the proportion of idle resources in a certain level partition exceeds the second threshold for a continuous set time, it automatically shrinks. Only the idle memory blocks exceeding the initial preset number are released. Before release, it is verified that the memory block is not bound to any active transmission task of any virtual USB device node.

[0048] Step 3: The container application initiates a USB data transfer request. The container kernel opens the created virtual USB device node. The container USB business processing unit captures the request, extracts key parameters such as the target transmission endpoint, data buffer, total data length, and transmission timeout threshold, determines the USB transmission mode, and synchronizes the application data buffer address.

[0049] The container USB service processing unit requests a shared memory block according to the USB transmission mode and maps the shared memory block to the container application's user-space virtual address space corresponding to the current virtual USB device node. When the application sends outbound data to the hardware, the container application writes the raw data to be sent to the mapped shared memory block address. The container USB service processing unit converts the virtual memory address into a physical memory address, generates a transmission task packet containing the container identifier, exclusive access token, endpoint address, transmission direction, total data length, list of physical addresses of memory blocks, and transmission timeout parameters, and attaches a CRC32 check value to it before sending it to the host's USB container passthrough module.

[0050] The USB container passthrough module first verifies the integrity of the message, then compares the device exclusive access token in the transmission task packet with the device exclusive token cached on the host side. If the verification fails, the transmission task is rejected directly; if the verification succeeds, the module reads the DMA channel number bound to the hardware resource storage area corresponding to the virtual USB device node, configures the DMA channel parameters, constructs a zero-copy URB software request block, and the DMA controller and the zero-copy URB complete the data transmission. The DMA controller marks the DMA transmission status and records the actual number of bytes transmitted. After the USB controller completes the sending and receiving of the entire batch of data packets, it generates a transmission completion status, and the USB container passthrough module generates a transmission completion response packet and sends it to the container kernel.

[0051] After the container kernel receives the transmission completion response packet, if it is an input transmission (i.e., the container application obtains external data), it reads the complete data from the shared memory mapping address and sends it to the application buffer; if it is an output transmission (i.e., the container application transmits data externally), it does not perform a read operation; it releases the memory lock state during the transmission, resets the memory block to an idle state and puts it back into the hierarchical memory pool; when the application closes the virtual USB device node file descriptor, it triggers a full-link resource reclamation process, releasing all hardware and memory resources such as DMA, interrupts, and shared memory, and the host synchronously removes the physical device exclusive mark.

[0052] The container USB service processing unit requests shared memory blocks according to the USB transmission mode in the following ways: it allocates a first-level memory block for batch transmission, a second-level memory block for isochronous transmission, and a third-level memory block for interrupt and control transmission; it calculates the number of memory blocks required according to the total data capacity and completes the allocation of multiple resource combinations; it maps the kernel-side shared memory address to the service user address space, opens read and write access permissions, and generates a shared memory access address that the service can directly operate.

[0053] The method for constructing a zero-copy dedicated URB software request block is as follows: the USB container passthrough module generates a dedicated copyless transfer description instance, binds the physical device identifier and transfer pipe type; disables the built-in temporary buffer configuration, directly associates the DMA scatter list address, and mounts the memory resource status and container associated context; multiple instances are written to the USB hardware scheduling queue in an orderly manner, and a concurrency protection mechanism is executed to avoid queue disorder.

[0054] Furthermore, the data transfer method completed by the DMA controller and the zero-copy URB is as follows: For outbound transfers, after the USB hardware receives the scheduling task, it triggers the DMA controller, reads the raw data in batches from the shared physical memory according to the scattering list, completes the USB standard packetization through the internal hardware cache, and sends it to the peripheral device through the bus; For inbound transfers, the peripheral device returns data and stores it in the USB hardware receive cache, and the DMA controller automatically fills the data back into the designated shared physical memory area.

[0055] Furthermore, to address issues such as excessively long interrupt forwarding links, high interrupt handling overhead, and latency caused by cross-core CPU scheduling, this invention establishes a hierarchical optimization mechanism for interrupt handling scheduling. The specific process is as follows:

[0056] After binding the target device to the corresponding container, the USB container passthrough module obtains the hardware interrupt descriptor and interrupt number corresponding to the USB hardware, converts them into offsets in the container kernel virtual interrupt vector table, and generates a one-to-one binding mapping relationship between hardware interrupts, host interrupts, container virtual interrupts, and target container identifiers, which is then written into the interrupt mapping structure. The container USB service processing unit is configured with pre-processing for hardware interrupts, including interrupt flag clearing, hardware transmission status reading, and service transmission thread wake-up, as well as post-processing for asynchronous processing, including data integrity verification, hardware error type parsing, retry of recoverable transmission tasks, memory resource status update, and service layer completion event notification. The host reads the container calculation core number, generates a core binding mask, locks all USB interrupt signals to this core for operation, disables the deep sleep mechanism of this core, and retains only the shallow sleep mode.

[0057] The method for generating a one-to-one binding mapping relationship between hardware interrupts, host interrupts, container virtual interrupts and target container identifiers is as follows: the host side replaces the native interrupt handling logic and binds the interrupt mapping association data to the interrupt descriptor; if the host has an advanced general interrupt controller, it issues a controller configuration instruction to route the hardware interrupt to the container computing core; after receiving the configuration notification, the container side rewrites the local interrupt vector table and mounts the container-specific USB interrupt unified processing entry.

[0058] Furthermore, the priority of the post-interrupt task scheduling is set as follows: the global scheduling priority of the USB post-interrupt task is increased, which is higher than the asynchronous tasks of general devices such as network and storage; the asynchronous task merging mechanism of the dedicated computing core is turned off to ensure that each hardware interrupt can trigger post-processing independently; the asynchronous scheduling channel is enabled immediately after the hardware interrupt pre-processing is completed to further reduce task waiting latency.

[0059] Furthermore, a high-frequency invalid interruption rate limiting protection mechanism is configured, specifically: configuring an interrupt reporting frequency threshold per unit time, and differentiating the upper limit of the threshold for three transmission modes: batch, time-based, and interrupt; when the interrupt reporting frequency exceeds the set proportion of the upper limit of the threshold, the hardware interrupt signal is temporarily blocked and the duration is continuously set, and the device hardware operating status is read synchronously; if abnormal states such as device offline are identified, a disconnection notification is pushed to the upper layer service; if the device is running normally, the interruption blocking is lifted and the normal path is restored.

[0060] To address the transmission rate fluctuation issue caused by multi-task resource contention, this invention implements multi-dimensional resource allocation and scheduling rule configuration across computing, I / O, and hardware dimensions, and constructs an independent resource scheduling isolation mechanism for containers, specifically including:

[0061] The host obtains the total number of CPU cores in the system, iterates through all CPU cores to obtain short-term load data for each core, and selects idle cores with loads below a threshold. Based on the total number of system cores, it executes differentiated allocation rules to determine the number of dedicated cores for containers. The binding relationship between cores and containers is written to the container configuration storage area, and all USB-related business threads and interrupt handling processes within the container are synchronously constrained to run only in dedicated cores, prohibiting cross-core scheduling.

[0062] Increase the scheduling priority of container USB-related application threads and configure the highest static priority weight; enable real-time preemptive scheduling mode for USB transfer applications, so that tasks can preempt computing resources first when they are ready; enable the mutex lock priority protection mechanism to avoid priority inversion problem caused by low-priority tasks holding locks and blocking high-priority USB transfer processes.

[0063] Set the highest real-time access priority for memory read and write I / O operations corresponding to USB, create an independent I / O scheduling queue for container USB applications, bind the queue to the corresponding compute memory node, and configure a low-latency scheduling policy for the queue to shorten the queuing time of I / O requests.

[0064] The USB container passthrough module sends an exclusive lock command to lock the USB controller and its associated DMA channels, setting the maximum single transfer length of the channels; it also rebinds the interrupt handling logic, blocking the host kernel's native interrupt handling path and retaining only the container kernel's interrupt response.

[0065] Furthermore, to address the issue of multiple containers accessing the same USB hardware, this invention initializes a multi-device access priority scheduling queue. The queue stores the access subject identifier, container static priority, request initiation time, and hardware device path. When multiple containers successively or simultaneously request the same USB hardware, the requests are sorted according to the preset container static priority and request initiation time. Higher-priority containers have priority in obtaining device usage rights, while lower-priority containers enter a waiting queue. After the current container releases the hardware, the highest-priority waiting container in the queue is automatically woken up, and the cached USB hardware and memory mapping configuration is reused to shorten device switching time.

[0066] Furthermore, the present invention pre-allocates USB bus bandwidth and dynamically and adaptively adjusts it, specifically by: calculating the theoretically available effective bandwidth according to the USB hardware specifications, writing a fixed bandwidth allocation value to the USB hardware controller and locking the bandwidth resources to prevent the bandwidth from being squeezed out by other applications; collecting the bus resource utilization rate in real time, increasing the bandwidth when the load is low and the application transmission demand increases, and reducing the low-priority control transmission bandwidth when the bus load is saturated.

[0067] For different types of USB transmission modes, this invention establishes different transmission optimization methods, specifically:

[0068] The container reads the USB device endpoint descriptor, distinguishes between four types of transfer modes: control, bulk, isochronous, and interrupt, and synchronously obtains the hardware characteristic parameters of each type of transfer mode; it generates transfer characteristic information from the transfer mode type and hardware parameters, and synchronously distributes it to the host USB container passthrough module.

[0069] When the length of the application data packet is less than the maximum number of bytes that a single hardware packet can carry, it is padded and then sent; a data packet merging threshold is set. When the length of the application data packet is less than the merging threshold, the application data packet is saved to the merging buffer, and transmission is initiated when the capacity of the merging buffer is greater than the threshold or the timeout is greater than the threshold; when the length of the application data packet is greater than the maximum threshold, it is split into multiple groups of data and sent in a pipeline mode through multiple created transmission tasks.

[0070] For isochronous transmission mode, the hardware timing identifier is read and written to the reserved storage area of ​​shared memory, the container synchronizes the timing reference, and corrects the timing offset of audio and video frames; a frame loss tolerance threshold is configured, and frame loss interpolation compensation is performed when the transmission delay is greater than the threshold; the scheduling priority of isochronous transmission tasks is increased, the required bus bandwidth is calculated according to the frame size and frame rate, and the corresponding bandwidth resources are reserved for real-time data streams;

[0071] For interrupt transmission mode, read the minimum hardware reporting interval and enable it, combine multiple interrupt data within a set time window and report them in batches, and configure a circular buffer to read data in batches.

[0072] For control transfer mode, configure the USB device configuration command to set the highest scheduling priority, and merge commands with zero length before transmission.

[0073] Example:

[0074] This embodiment employs a cross-system USB high-performance transmission method based on a hierarchical linked shared memory pool provided by the present invention. Using OpenHarmony as the host system and Android as the container system, it achieves zero-copy, low-latency data transmission through a fully optimized end-to-end architecture, eliminating redundant copying and context switching, and optimizing resource release efficiency. The specific process includes:

[0075] S1. By refactoring the USB enumeration process of OpenHarmony and Android containers, cross-layer enumeration and exclusive binding of USB devices are achieved.

[0076] Android applications initiate USB device access requests through Android's native USB Host APIs, such as UsbManager.requestPermission(). These requests are first intercepted by the USB subsystem framework layer of the Android container, which is implemented by modifying UsbService and adding a container-specific request flag field, containerDirectAccess, set to true. The Android container kernel then encapsulates this request into a cross-kernel USB access request packet, the packet structure of which is defined in the table below.

[0077] Table 1. Structure Definition of Cross-Kernel USB Access Request Packet

[0078] The request packet is sent to the OpenHarmony host kernel through the communication channel between the container runtime and the host kernel. This communication channel is based on the Netlink protocol extension, with the protocol type set to NETLINK_USB_CONTAINER and the multicast group ID set to 0x10.

[0079] Modify the USB core driver in the OpenHarmony host kernel. When the USB core driver receives a request packet, it triggers the USB controller to enumerate the target device. If the device is already connected, the enumeration is skipped and the cached device information is read directly. During the enumeration process, the host USB protocol stack collects the complete set of device descriptors, including device descriptors such as bDeviceClass, bDeviceSubClass, bMaxPacketSize0, configuration descriptors such as wTotalLength, bNumInterfaces, interface descriptors such as bInterfaceClass, bInterfaceSubClass, endpoint descriptors such as bEndpointAddress, bmAttributes, wMaxPacketSize, bInterval, and string descriptors. At the same time, it reads the USB controller registers such as the USB20_ROUTE_PORT and USB30_ROUTE_PORT registers of the xhci controller to obtain the controller number corresponding to the device, the DMA channel number mapped by the DMA_REQUEST_SELECTOR register, and the interrupt IRQ number parsed by the IRQ_ROUTING_TABLE register, and stores the hardware resource information such as the USB device resource information structure in the host kernel.

[0080] Modify the OpenHarmony host's USB manager to perform triple cross-layer permission verification, specifically: container permission verification, querying / sys / container / <containerid>The ` / permissions` node confirms that the container is registered and the `usb_direct_access` permission bit is 1. Application permission verification involves synchronously querying the Android container's permission management service, `PackageManagerService`, via the container runtime's IPC channel to confirm that the application has obtained USB usage permissions. Device exclusivity verification involves querying the USB device occupancy status table maintained by the host kernel. This USB device occupancy status table is a global hash table, with the key being the device path, such as ` / sys / bus / usb / devices / `. <devnum>The value is a occupancy status structure, confirming that the target device is not occupied by other containers or the host native application. After all three checks pass, a permission response packet is generated, containing the complete device descriptor set, hardware resource information, and an exclusive access token. The exclusive access token is a 16-byte random string, which can be generated using the get_random_bytes() function.

[0081] Container-side device information synchronization and virtual device creation: After receiving the response packet, the Android container kernel parses the descriptor set through the modified Android USB subsystem kernel layer code and calls the usb_create_device() function to create a virtual USB device node in the container kernel. Its path is consistent with native Android, such as / dev / bus / usb / 001 / 002. The struct usb_device structure of this node adds a phys_dev_res field to store physical device resource information, including controller number, DMA channel number, etc. Data read and write interfaces such as read() or write() point to the custom usb_container_direct_read() or usb_container_direct_write() functions, which serve as the entry point for subsequent zero-copy channels. At the same time, the Android container's USB subsystem stores the exclusive access token in the container kernel's USB device state buffer, such as struct usb_container_dev_state, and attaches it to the private_data field of struct usb_device for authentication during subsequent transmission.

[0082] Host-side device exclusive state locking: The OpenHarmony host kernel modifies the USB device occupancy status table through the newly added USB container passthrough driver module UCDD, marking the target device's state as Container Exclusive and associating it with the container ID; at the same time, the UCDD module sends configuration instructions to the USB controller: setting the EXCLUSIVE_ACCESS_EN bit to 1 through the DEVICE_CONTROL_REG register to disable the interrupt handling logic of the host's native USB driver, clearing the HOST_DRIVER_IRQ_EN bit of the IRQ_DISPATCHER register to 0, and setting the CONTAINER_IRQ_EN bit to 1 to ensure that interrupt signals are only forwarded to the target container.

[0083] S2. Hierarchical shared memory pool construction and address mapping: Based on the acquired device endpoint information, a hierarchical shared memory pool adapted to USB transmission characteristics is constructed, and direct address space mapping between the host and container kernel is achieved, providing a memory foundation for zero-copy transmission.

[0084] Dynamic calculation of memory pool parameters: The UCDD module traverses all configured endpoints based on the collected endpoint descriptor information and calculates the core parameters of the hierarchical shared memory pool.

[0085] Single endpoint memory block size calculation: Batch endpoint bmAttributes=0x02, its single block size is wMaxPacketSize*1024; Isochronous endpoint bmAttributes=0x01, its single block size is wMaxPacketSize*2048; Interrupt endpoint bmAttributes=0x03, its single block size is wMaxPacketSize*512; Control endpoint bmAttributes=0x00 reuses interrupt endpoint L3 block;

[0086] The total size of the memory pool is ∑ (size of each endpoint block * initial number of blocks). The initial number of blocks is configured according to the endpoint type: 16 blocks for batch endpoints, 8 blocks for isochronous endpoints, and 4 blocks for interrupt endpoints.

[0087] Memory block hierarchy: L1 blocks account for 60% of bulk transfers, L2 blocks account for 30% of isochronous transfers, and L3 blocks account for 10% of interrupt or control transfers. For example, if the USB 3.0 bulk endpoint wMaxPacketSize = 1024 bytes, the size of a single block is 1024 * 1024 = 1MB. With an initial 16 blocks, the total size of the L1 blocks is 16MB. When this accounts for 60% of the memory pool, the total size of the memory pool is approximately 26.67MB.

[0088] Host kernel-mode memory pool creation: The UCDD module calls the openHarmony kernel's kmalloc_node() function to specify the NUMA node corresponding to the USB controller, and allocates a hierarchical memory pool in the host kernel-mode contiguous physical memory. During allocation, the GFP_DMA32 | GFP_KERNEL | __GFP_ZERO flags are set to ensure DMA accessibility, kernel space allocation, and memory initialization to zero. At the same time, a memory block status table is created, such as the struct usb_shmem_block_state array, where each element records the information of a single memory block as shown in the table below.

[0089] Table 2 Single Memory Block Information Table

[0090] The memory block status table initializes the IDR index through idr_init(), which facilitates quick status lookup by block ID.

[0091] The UCDD module utilizes the IOVM (I / O Virtual Memory) subsystem, which modifies the kernel's IOMMU to perform address mapping. This includes: host kernel mapping, which is automatically completed via kmalloc_node() to map physical addresses to virtual addresses in the host kernel; and container kernel mapping, which allocates a dedicated virtual address range (e.g., 0x70000000 to 0x80000000) for the Android container kernel, traverses the memory block status table, and calls the iommu_map() function for each memory block to map phys_addr to the container virtual address range. This address range allocates container_virt_addr according to the block size offset. During mapping, IOMMU_READ, IOMMU_WRITE, and IOMMU_NOEXEC permissions are set, allowing read and write operations while disabling execution. An address mapping table, such as struct, is also generated. The usb_addr_map hash table has phys_addr as the key and host_virt_addr and container_virt_addr as the values. It is stored in the addr_map_cache cache of the UCDD module. After mapping, the validity of the mapping is checked. If it fails, memory is released and an error is returned.

[0092] Container kernel memory access interface registration: The modified USB subsystem of the Android container kernel adds a set of shared memory access interfaces, which are registered to the file_operations structure of the container kernel, creating the following interfaces:

[0093] The memory block allocation interface, usb_container_shmem_alloc(u8 endpoint_addr, size_tdata_len, struct usb_shmem_block **blocks, int *block_cnt), determines the level based on the endpoint address, protects the traversal of the memory block status table with a spinlock spin_lock_irqsave(), selects free blocks according to the best matching principle, prioritizes the smallest block with a size not less than data_len, and requests multiple blocks if there are not enough, stores the block information in the blocks array, returns the number of blocks block_cnt, updates the block status to ALLOC, and records the associated endpoint address;

[0094] The memory block release interface, usb_container_shmem_free(struct usb_shmem_block **blocks, int block_cnt), iterates through the block array, gets the block status, updates the status to FREE using a spinlock, and clears the associated endpoint address;

[0095] The address translation interface, usb_container_virt_to_phys(void *container_virt_addr,dma_addr_t *phys_addr), iterates through the address lookup table, finds the corresponding phys_addr through container_virt_addr, and verifies that the container_id matches to prevent cross-container address translation.

[0096] Memory pool state synchronization and caching: The UCDD module encapsulates the memory pool parameters, including total size, block size at each level, number of blocks, and address lookup table summary including the phys_addr range and container_virt_addr range, into a memory pool configuration synchronization package, which is then sent to the Android container kernel via the Netlink channel. After receiving the package, the container kernel stores the configuration information in the USB shared memory configuration cache, such as struct usb_shmem_config, creates a dedicated cache pool for storage using kmem_cache_create(), and notifies the Android container's USB subsystem framework layer through the usb_shmem_config_broadcast() function to provide parameter support for application layer memory block requests.

[0097] The UCDD module sets the thresholds for elastic expansion and contraction of the memory pool. For expansion, when the number of free memory blocks at a certain level is no more than 10% of the total number, expansion is triggered. The expansion size is 50% of the current total size at that level. During expansion, kmalloc_node() is called to allocate new blocks, automatically completing cross-kernel mapping. Spin_lock() protects the memory block status table updates without interrupting current transmissions, and allocated blocks are marked as LOCKED. For contraction, when the number of free memory blocks at a certain level is no less than 30% of the total number and remains free for 500ms, contraction is triggered, releasing free blocks exceeding the initial block count. Before releasing, it is confirmed that the blocks have no associated transmission tasks.

[0098] S3, a zero-copy data transfer channel built with dual kernel collaboration, reconstructs the USB data transfer logic between the host and the container, refines the implementation details such as URB construction, DMA configuration, and data flow, and builds a full-link zero-copy channel from hardware to shared memory to the application, eliminating redundant copying and context switching.

[0099] Application-layer data transfer request initiation and parameter parsing: Android applications initiate data transfer requests through APIs such as `UsbDeviceConnection.bulkTransfer()`, `UsbDeviceConnection.isochronousTransfer()`, and `UsbDeviceConnection.controlTransfer()`. Request parameters include: target endpoint address, data buffer, data length, and timeout. The request is intercepted by the USB subsystem framework layer of the Android container, which modifies the implementation of `UsbDeviceConnection`. The endpoint address is parsed through the `bmAttributes` field of the synchronized `struct usb_endpoint_descriptor` to obtain the endpoint type, and the application data buffer address, i.e., the user-space virtual address, is recorded.

[0100] Shared memory block allocation and user-space mapping: The container USB subsystem framework layer calls the usb_container_shmem_alloc() interface to allocate shared memory blocks.

[0101] For bulk transmission, calculate the required number of L1 blocks based on the length, i.e., block_cnt = ceil(length / L1_BLOCK_SIZE), and request the corresponding number of L1 blocks; for isochronous transmission, split the length according to the frame size iso_packet_size, calculate the required number of L2 blocks, and request L2 blocks; for interrupt or control transmission, request one L3 block. The maximum length of control transmission is usually no more than 64 bytes, so L3 blocks are generally used.

[0102] After successful application, the mmap() function maps the container kernel virtual address of the obtained shared memory block to the user-space virtual address space of the Android application, with the mapping flags set to PROT_READ | PROT_WRITE | MAP_SHARED, and returns the user-space virtual address user_shmem_addr.

[0103] Application-layer data direct write to shared memory: For output transfers from container applications to USB devices, the Android application calls the `memcpy(user_shmem_addr, data, length)` function to write the data to be transferred directly from the application's user-space buffer to the user-space mapped address in shared memory. Since this address is associated through a two-level mapping from the application's user space to the container's kernel space and then to physical memory, the data is written directly to the shared memory physical address without any kernel-space or user-space copying. The transmission latency depends only on the CPU memory write speed, which is typically no greater than 1μs / MB. For input transfers from USB devices to container applications, this step is skipped, and the application waits for the data to be written to shared memory before reading it directly.

[0104] Packet encapsulation and authentication for transfer tasks: The Android container kernel's USB subsystem calls the usb_container_virt_to_phys() interface to convert the container kernel virtual address of the shared memory block into the physical address phys_addr, and then encapsulates it into a zero-copy transfer task packet. The packet structure is defined in the table below.

[0105] Table 3. Structure Definition Table of Zero-Copy Transfer Task Packet

[0106] The task packet calculates the CRC32 checksum using the crc32_le() function and sends it to the host kernel UCDD module via the Netlink channel, i.e., the NETLINK_USB_CONTAINER protocol. After receiving it, the UCDD module first verifies the CRC32 value, then compares the token with the cached exclusive access token. If the verification is successful, processing continues; otherwise, an -EPERM error is returned.

[0107] DMA channel binding and parameter configuration: The UCDD module obtains the DMA channel number from step 1, and calls the dma_request_channel() function according to the transfer direction by passing DMA_DEV_TO_MEM or DMA_MEM_TO_DEV to bind the DMA channel and return a struct dma_chan handle; configure the DMA channel parameters, set the DMA address mask, which is 32-bit or 64-bit, to match the shared memory physical address width;

[0108] Create a DMA scatter aggregation table, i.e., the SG table, traverse the block_phys_addrs array, add an SG entry for each shared memory block, set the physical page, offset, and length; set the DMA transfer completion callback function usb_dma_complete_cb(), and submit the DMA task to the DMA controller.

[0109] URB Construction and USB Controller Submission: The UCDD module modifies the usb_alloc_urb() function of the OpenHarmony host USB protocol stack to construct a zero-copy custom URB, such as struct urb. Key field configurations include:

[0110] dev: Pointer to the enumerated physical USB device structure;

[0111] pipe: generated by functions such as usb_sndbulkpipe() / usb_rcvbulkpipe(), matching endpoint type and direction;

[0112] transfer_buffer: Setting it to NULL indicates zero-copy mode, where the buffer is not used;

[0113] transfer_buffer_length: set to data_len;

[0114] transfer_dma: Set to the DMA address in the SG table, such as the return value of dma_map_sg();

[0115] transfer_flags: Sets URB_NO_TRANSFER_DMA_MAP | URB_NO_TRANSFER_MEMORY | URB_ALLOC_BUFFER to skip kernel DMA mapping, not allocate transfer memory, and automatically allocate URB buffers;

[0116] complete: Sets the usb_urb_complete_cb() callback function;

[0117] context: Points to a custom struct usb_container_urb_ctx structure, which stores the shared memory block status table pointer, container ID, and other context information;

[0118] After the URB is constructed, the usb_submit_urb() function is called to submit the URB to the USB controller. During submission, the USB controller queue is protected by spin_lock_irqsave() to ensure that the URB is submitted in an orderly manner.

[0119] DMA and USB controller coordinated transfer:

[0120] For output transmission, after receiving the URB, the USB controller sends a transmission trigger signal to the DMA controller. The DMA controller reads the data from the shared memory physical address according to the SG table and transmits it to the transmit FIFO buffer of the USB controller through the AXI bus. The USB controller encapsulates the data into USB packets, divides them into packets according to the endpoint wMaxPacketSize, and sends them to the target device through the USB bus.

[0121] For input transmission, data sent by the USB device arrives at the USB controller's receive FIFO buffer via the USB bus. The controller sends a trigger signal to the DMA controller, which reads the data from the FIFO and writes it to the shared memory physical address according to the SG table. The entire process is completed without CPU intervention and is entirely hardware-coordinated. The transmission delay depends only on the USB bus speed and the DMA transfer rate.

[0122] Transmission completion callback and status synchronization:

[0123] After the DMA controller completes the transfer, it triggers the usb_dma_complete_cb() callback, marks the DMA transfer status as successful or failed, and records the actual number of bytes transferred.

[0124] After the USB controller completes the transfer, it triggers the usb_urb_complete_cb() callback, reads the status field of the URB, where 0 indicates success and non-zero indicates an error code, such as -ETIMEDOUT for timeout and -EPIPE for pipe error. It then combines the DMA status to generate a transfer completion status. The UCDD module encapsulates the transfer completion response packet, which includes the container ID, task packet ID, transfer status, actual number of bytes transferred, and error code, and sends it to the Android container kernel through the Netlink channel.

[0125] After the application layer data read-through and memory block locking are released, and the Android container kernel receives the response packet, if the transmission is successful:

[0126] For input transmission, the application calls the memcpy(data, user_shmem_addr, actual_len) function to directly read data from the shared memory user-space mapped address, without performing a copy operation; for output transmission, no data reading is required.

[0127] After the transfer is complete, the container kernel calls the usb_container_shmem_free() interface to release the shared memory block. Before releasing, the block's LOCKED state is removed by spin_lock_irqrestore(), and the block state is updated to FREE.

[0128] S4. Interrupt Vector Table Passthrough and Lightweight Response Mechanism: For interrupt triggering and response during USB transmission, this embodiment implements interrupt vector table mapping, interrupt handling function optimization, interrupt scheduling, etc., shortening the interrupt response path and reducing latency fluctuations.

[0129] The interrupt vector table cross-kernel mapping parameter calculation is performed as follows: After completing the exclusive binding of the device, the UCDD module obtains the interrupt IRQ number irq_num corresponding to the USB device, obtains the interrupt descriptor struct irq_desc through the irq_desc_get() function, and reads desc->irq_data.hwirq to obtain the hardware IRQ number; the offset of the container kernel virtual interrupt vector table is calculated. The base address of the container kernel interrupt vector table container_irq_vector_base is obtained through the container_get_irq_vector_base() function, such as 0xFFFF0000. The virtual interrupt vector number (container_irq_vec) = irq_num + CONTAINER_IRQ_VEC_OFFSET. The offset of CONTAINER_IRQ_VEC_OFFSET is set to 1024 to avoid conflicts with the container's native interrupts. The mapping relationship is stored in the struct irq_direct_map structure, which includes hwirq, host_irq, container_irq_vec, and container_id.

[0130] Interrupt vector table direct mapping configuration is specifically completed by the UCDD module through the newly added interrupt vector direct mapping module. This includes: host kernel configuration, modifying the handle_irq function pointer of struct irq_desc to point to the custom usb_container_irq_handler() to replace the native interrupt handling function; storing the struct irq_direct_map structure into the private data of the interrupt descriptor through the irq_set_chip_data() function; hardware interrupt controller configuration, if it is a GICv3 controller, sending an SGI interrupt notification to the container kernel that the interrupt mapping is ready through the ICC_SGI1R register; configuring interrupt routing through the GICD_IROUTERn register n=hwirq to route the hardware IRQ to the container's dedicated CPU core; container kernel configuration, after receiving the mapping notification, the container kernel modifies its own interrupt vector table container_irq_vector_base + container_irq_vec * sizeof(void*), setting the interrupt handling function pointer at the corresponding position to the container-side interrupt handling entry usb_container_irq_handler.

[0131] The Android container kernel modifies the interrupt handling logic of the USB subsystem, registers the container-specific USB interrupt handler function usb_container_irq_handler(), and performs lightweight assembly-level optimizations. Specifically:

[0132] The top half, i.e., the hard interrupt, is implemented in assembly, with an embedded asm volatile code block, retaining only 3 core instructions: interrupt confirmation, writing the clear interrupt flag IRQ_ACK_BIT to the IRQ_STATUS_REG register of the USB controller; status reading, reading the transfer completion status from the TRANSFER_STATUS_REG register and storing it in register R1; thread wake-up, calling the wake_up_process() function to wake up the application's transfer thread, and the task structure can be found by the thread PID.

[0133] After assembly code optimization, the top half execution time is strictly controlled within 2μs, while the native Android execution time is approximately 5μs. All log printing, debug information output, and unnecessary status verification logic have been removed, retaining only the core processes of interrupt confirmation, status reading, and thread wake-up.

[0134] Interrupt affinity is bound to the CPU core: The OpenHarmony host kernel scheduler completes interrupt affinity configuration, obtains the allocated container-specific CPU core ID (container_cpu_id), creates a CPU affinity mask (cpu_set_t), initializes it using CPU_ZERO(), and sets the mask using CPU_SET(container_cpu_id, &mask); it calls the irq_set_affinity(irq_num, &mask) function to bind the USB interrupt to the dedicated CPU core, ensuring that interrupt handling is only executed on that core; and it uses the sysfs node / sys / devices / system / cpu / cpu<container_cpu_id> Writing 0 to / cpuidle / state0 disables the C0 sleep state (deep sleep) of this core, leaving only the C1 shallow sleep state. The wake-up latency is no more than 1μs, avoiding interrupt response delay caused by core sleep.

[0135] The top half of the hardware interrupt and the bottom half of the soft interrupt are separated, and a top-half and bottom-half interrupt handling model is adopted. Specifically: Top half, hardware interrupt usb_container_irq_handler_top(): execution time is no more than 2μs, only interrupt confirmation is completed and the interrupt flag is cleared, the USB controller transfer status register TRANSFER_STATUS and ERROR_CODE are read; the soft interrupt trigger flag set_softirq_pending(1 << USB_CONTAINER_SOFTIRQ) is set; the interrupt handling is returned as complete.

[0136] The bottom half, the soft interrupt usb_container_irq_handler_bottom(), is registered via open_softirq(USB_CONTAINER_SOFTIRQ, usb_container_irq_handler_bottom) and executes asynchronously after the hard interrupt returns. It primarily handles time-consuming operations including: data integrity verification (for devices without hardware CRC checksums, it calls crc32_le() to perform CRC32 verification on the shared memory data, comparing the checksum value with the CRC value sent by the USB device); error code parsing (resolving error types such as CRC errors, timeout errors, and bus errors based on the ERROR_CODE register value); error recovery (for recoverable errors such as CRC errors, it triggers usb_urb_retry_submit() to resubmit the URB, retrying a maximum of two times; for unrecoverable errors such as bus errors, it notifies the application of transmission failure); memory block status update (if transmission is complete, it uses spin_lock() to protect and update the shared memory block status to FREE); and application notification (calling kill_fasync() to send a SIGIO signal to the application, notifying it of data transmission completion).

[0137] Soft interrupt scheduling timing optimization: Modify the soft interrupt scheduling logic of the container kernel to ensure timely execution of the bottom half, set the soft interrupt scheduling priority to the highest softirq_priority[USB_CONTAINER_SOFTIRQ] = 0, which is higher than network and block device soft interrupts; disable soft interrupt merging (disable_softirq_merging(USB_CONTAINER_SOFTIRQ)) on the dedicated CPU core to ensure that each soft interrupt triggered by a hard interrupt can be scheduled independently; enable soft interrupts immediately after the top half of the hard interrupt ends using local_bh_enable(), shortening the scheduling latency by no more than 1μs.

[0138] To avoid interrupt storms caused by USB device malfunctions, i.e., high-frequency invalid interrupts, a new suppression mechanism has been added:

[0139] Count the number of interruptions per unit time, with each unit time being 10ms. Set thresholds, such as 1000 times / 10ms for batch transmission, 10000 times / 10ms for isochronous transmission, and 100 times / 10ms for interrupted transmission.

[0140] When the number of interrupts exceeds 150% of the threshold, interrupt rate limiting is triggered: interrupts are temporarily masked through the IRQ_MASK_REG register for 1ms, while the USB device status is read and checked through DEVICE_STATUS_REG; if the device status is abnormal, such as DEVICE_DISCONNECTED, the application is notified to disconnect; if the status is normal, the masking is lifted and interrupts are resumed.

[0141] S5, a container-specific resource isolation scheduling pool is built to address the performance fluctuations caused by resource preemption. It implements the allocation and scheduling logic of CPU, IO, and hardware resources, and builds a container-specific resource isolation scheduling pool to ensure that USB transmission resources are not preempted.

[0142] Container-specific CPU core allocation algorithm implementation: When the OpenHarmony host container runtime is created in Android, it dynamically allocates dedicated CPU cores using the following algorithm:

[0143] Call get_nr_cpu_ids() to get the total number of CPU cores in the system, total_cpus;

[0144] Scan all CPU cores, obtain the load of each core using the cpu_load() function, the length of the run queue within 10ms, and filter idle cores with a load of no more than 10%.

[0145] Allocate based on the number of idle cores:

[0146] total_cpus ≥4: Allocate 2 cores, i.e. cpu0 is used for interrupt handling and cpu1 is used for USB transfer threads;

[0147] total_cpus=2: Allocate 1 core, which is used for both interrupt and transfer threads;

[0148] total_cpus=1: Allocate this core and set the USB transfer priority flag;

[0149] The `container_set_exclusive_cpus(container_id, cpu_list)` function sets the core list to be container-specific and writes it to ` / sys / container / `.<container_id> / exclusive_cpus node;

[0150] Call the sched_setaffinity() function to set the CPU affinity of all USB-related processes within the container, including the Android application transfer thread, the container USB subsystem thread, and the interrupt handling thread, to a dedicated core list, preventing them from being scheduled to other cores.

[0151] CPU scheduling priority and scheduling policy optimization:

[0152] Prioritize to the top, modify the OpenHarmony kernel, set the static priority of container USB-related processes to 99, which is the maximum real-time priority in Linux, and set the process nice value to -20, which is the highest static priority, using the set_user_nice(pid, -20) function;

[0153] The scheduling policy is configured by setting the SCHED_FIFO real-time scheduling policy for the USB transfer thread through the sys_sched_setscheduler(pid, SCHED_FIFO, ¶m) function, i.e., param.sched_priority=99, to ensure that the thread immediately preempts the CPU once it is ready, without scheduling delay.

[0154] Priority inheritance mechanism: Enable the scheduler's priority inheritance (PI) mechanism, and set the priority inheritance attribute of USB transfer-related mutex locks through the pthread_mutexattr_setprotocol(&attr, PTHREAD_PRIO_INHERIT) function to avoid low-priority threads holding locks and causing high-priority USB threads to be blocked, such as the priority inversion problem.

[0155] IO resource priority exclusive access and scheduling queue optimization:

[0156] IO priority settings: Modify the OpenHarmony kernel to the IO operations corresponding to container USB transfer, map shared memory read / write to block device IO, and set the IO priority to IOPRIO_CLASS_RT for real-time class, with a priority value of 0 being the highest level. This can be configured using the ioprio_set(IOPRIO_WHO_PROCESS, pid, IOPRIO_PRIO_VALUE(IOPRIO_CLASS_RT, 0)) function.

[0157] A dedicated IO queue is created by modifying the block device IO scheduler to create a dedicated IO queue (struct request_queue *usb_container_io_queue) for container USB transmission. This queue is allocated using the blk_alloc_queue_node() function and bound to the NUMA node of the dedicated CPU core.

[0158] The scheduling strategy is selected by setting the MQ-Deadline scheduling strategy for the dedicated IO queue through the elevator_set() function and adjusting the scheduling parameters: read request timeout read_expire=1ms, write request timeout write_expire=1ms, and front_merges=1 to reduce IO request queuing latency.

[0159] Hardware resource locking and register-level configuration:

[0160] USB controller locking: The UCDD module locks the USB controller through the usb_controller_lock(controller_id) function, sets the controller's EXCLUSIVE_MODE register bit to 1, and prevents other devices such as the host native device or other container devices from using the controller's transmission channel;

[0161] The DMA channel is exclusively used. The dma_channel_lock(chan) function is called to lock the DMA channel and set the DMA_CHANNEL_EXCLUSIVE register bit to 1 to prevent other DMA tasks from preempting the channel. The maximum burst length of the DMA is set by the dma_set_maxburst(chan, maxburst) function, which matches the wMaxPacketSize of the USB endpoint, such as 1024 for USB 3.0.

[0162] Interrupt channel isolation is achieved by rebinding the interrupt chip handler function using the irq_set_chip_and_handler() function, thus shielding the host kernel from all processing of this IRQ and retaining only the container kernel's interrupt response.

[0163] Multi-container USB device access conflict arbitration mechanism:

[0164] The arbitration queue is initialized by creating a USB device access request queue struct usb_access_queue, which is implemented using a priority queue struct prio_queue. The queue element is struct usb_access_req containing container ID, priority, request timestamp, and device path.

[0165] The arbitration strategy, when multiple containers simultaneously request access to the same USB device, sorts them according to a static container priority and a dynamic request timestamp. Static priority is determined by ` / sys / container / `.<container_id> The / priority node configuration ranges from 0 to 9, with 0 being the highest; it represents dynamic priority, where the earlier the request timestamp, the higher the dynamic priority; high-priority containers have priority in obtaining device access rights, while low-priority containers enter the waiting queue, i.e., the TASK_INTERRUPTIBLE state;

[0166] When the current container calls usb_device_release() to release the device, the arbitration module wakes up the highest priority container in the waiting queue through the wake_up_next_waiter() function, reuses the previous device descriptor information and memory mapping configuration, and only updates the container ID association, which significantly reduces the switching latency.

[0167] USB transmission bandwidth pre-allocation and dynamic adjustment: The UCDD module calculates the maximum transmission bandwidth based on the USB device type, including:

[0168] USB 2.0 bulk transfer: 480Mbps * 80% = 384Mbps, where 480Mbps is the theoretical value and 80% is the actual utilization rate;

[0169] USB 3.0 bulk transfer: 5Gbps * 90% = 4.5Gbps;

[0170] Isochronous transmission: calculated based on device wMaxPacketSize*1000 / bInterval. For example, if bInterval=1ms and wMaxPacketSize=1024 bytes, the bandwidth is 8.192Mbps.

[0171] Pre-allocation: The bandwidth is pre-allocated to the container through the BANDWIDTH_ALLOC_REG register of the USB controller. The calculated bandwidth value is written and the BANDWIDTH_LOCK bit is set to 1 to ensure that the bandwidth is not preempted.

[0172] Dynamic adjustment: The real-time acquisition of USB bus bandwidth utilization is read through BUS_UTILIZATION_REG. When the utilization is less than 50% and the application transmission demand increases, the pre-allocated bandwidth is increased by 10% each time, not exceeding the maximum bandwidth. When the utilization is greater than 95%, the bandwidth allocation for non-critical applications such as control transmission is reduced to ensure the bandwidth for batch and time-of-use transmissions.

[0173] Memory bandwidth optimization:

[0174] Shared memory NUMA node binding allocates hierarchical shared memory pools to the corresponding NUMA nodes of the USB controller, reducing cross-NUMA node memory access latency. The cross-node latency is about 200ns, and the same node latency is about 50ns.

[0175] Memory prefetch configuration uses the ARCH_SET_CACHE_ATTR system call to set the cache attributes of the shared memory region to Write-Back and Prefetch, enables the CPU prefetcher such as the PREFETCH_ENABLE register bit, and sets the prefetch length to 64 bytes, which is the CPU cache line size, to improve memory read and write speed.

[0176] Resource monitoring and overload protection:

[0177] Monitoring metrics are collected by embedding resource monitoring probes in the host kernel and container kernel to collect the following metrics in real time:

[0178] CPU, dedicated core utilization, scheduling latency, and context switch count;

[0179] IO, IO queue length, IO response time, IO error rate;

[0180] Hardware metrics include DMA channel busy rate, interrupt response time, and bus utilization.

[0181] Overload detection: Set overload thresholds, such as CPU utilization greater than 95%, IO queue length greater than 20, and interrupt response time greater than 20μs. When any of these indicators exceeds the threshold for 10ms, it is considered an overload.

[0182] The protection measures include prioritizing the suspension of non-USB transfer processes, such as background applications within containers, when overload protection is triggered to reduce resource consumption. If overload still occurs, the priority of non-critical USB transfers, such as control transfers, will be reduced to ensure normal batch and time-series transfers.

[0183] S6. Differentiated Adaptation and Parameter Calibration for Transmission Types: Optimizes transmission protocol details and improves transmission efficiency and stability through static adaptation strategies and dynamic parameter calibration, taking into account the characteristics of different USB transmission types.

[0184] The Android container kernel's USB subsystem accurately identifies the transmission type by parsing the bmAttributes field of the endpoint descriptor, and also parses key endpoint parameters, as shown in the table below.

[0185] Table 4 Endpoint Key Parameters

[0186] The identification results and parameters are stored in the struct usb_transfer_type_info structure and synchronized to the UCDD module and the container USB subsystem framework layer.

[0187] Batch transmission differentiation adaptation refinement:

[0188] Buffer alignment optimization involves modifying the container kernel's USB subsystem code to ensure that the shared memory block size and application data length are strictly aligned with the endpoint wMaxPacketSize, such as data_len % wMaxPacketSize == 0. If the application data length does not meet this requirement, the usb_pad_data() function will pad it with zeros. If the padding length is less than wMaxPacketSize, it will prevent the generation of small data packets, as the transmission efficiency of small data packets is only 30% of that of full packets.

[0189] The packet merging mechanism adds the usb_bulk_packet_merge() function to the container USB subsystem framework layer, sets the merging threshold to wMaxPacketSize*80%, and stores the data packets sent by the application in the merging buffer, which is wMaxPacketSize in size. Transmission is triggered when the threshold is met or a timeout occurs, and the full packet rate is significantly improved after merging.

[0190] Software CRC check is disabled by modifying the usb_hcd_submit_urb() function. When the bDeviceProtocol field of the USB device indicates that hardware CRC is supported, the URB_NO_CRC flag is set to disable software CRC check and reduce CPU overhead.

[0191] URB batch submission and pipelined transmission: When the amount of data to be transmitted exceeds the maximum length of a single URB, USB_MAX_XFER_SIZE, multiple URBs are created in batches, i.e., urb_cnt = ceil(data_len / USB_MAX_XFER_SIZE), and submitted to the USB controller in batches through the usb_submit_urb_batch() function, enabling pipelined mode. That is, while the previous URB is being transmitted, the next URB is already waiting in the queue to improve bus utilization.

[0192] Refinement of isochronous transmission differential adaptation:

[0193] The timestamp synchronization mechanism involves the UCDD module obtaining the hardware timestamp by reading the TIMESTAMP_REG register of the USB controller and writing it into a reserved field in the shared memory block, such as the first 8 bytes. The container kernel reads this timestamp and synchronizes it to the AudioTrack / MediaCodec component of the Android application to correct the playback timestamps of audio and video frames and solve the problem of out-of-order isochronous data frames.

[0194] Frame loss tolerance and error hiding: A new parameter, frame_loss_tolerance, has been added, with a value from 0 to 10. It represents the proportion of frames that can be lost. When the transmission delay exceeds the threshold, the current frame is discarded and an error hiding algorithm, such as audio and video frame interpolation, is used to avoid subsequent frames piling up and causing stuttering.

[0195] Real-time URB scheduling and prioritization: The priority field of isochronous URBs is set to USB_URB_PRIORITY_ISO, which is higher than batch and interrupt URBs. The URB scheduling logic of the USB controller is modified so that isochronous URBs have the highest priority in the scheduling queue, ensuring that each frame of data is transmitted on time.

[0196] Bandwidth reservation optimization: The required bandwidth is calculated based on the frame size and frame rate of isochronous transmission, such as bandwidth = frame_size * frame_rate * 8. The usb_set_interface_bandwidth() function is added to reserve dedicated bandwidth for isochronous interfaces to avoid being preempted by other transmissions.

[0197] Interrupt and control transmission differential adaptation refinement:

[0198] Interrupt transmission is optimized, interrupt intervals are minimized, and the endpoint bInterval field is read. For example, the minimum interrupt interval is 1ms for USB 2.0 and 125μs for USB 3.0. The interrupt interval is set to the minimum value supported by the device by adding the usb_set_interrupt_interval() function, which significantly improves the data update frequency.

[0199] Interrupt aggregation: The container kernel adds the usb_interrupt_aggregate() function to merge multiple interrupt requests within 1ms into a single transmission, reducing the number of URB submissions;

[0200] Interrupt data is buffered, storing interrupt data in a circular buffer with a size of wMaxPacketSize*8. Applications can read the data in batches using the read() function, reducing the number of system calls.

[0201] Control transmission optimization:

[0202] Prioritize short packets and set the control transmission URB to the highest priority to ensure a fast response to device configuration commands such as SET_CONFIGURATION and SET_INTERFACE;

[0203] The number of handshakes is reduced by modifying the three-stage process of control transmission: SETUP, DATA, and STATUS. When the data length is 0, such as in the GET_STATUS command, the STATUS stage is merged into the SETUP stage, reducing one bus handshake and shortening the transmission delay.

[0204] Control the transmission bandwidth limit, limiting the maximum transmission bandwidth to no more than 5% of the total bus bandwidth, to avoid occupying the bandwidth for batch and time-series transmissions.

[0205] The transmission parameter dynamic calibration algorithm collects transmission performance indicators in real time, including: batch transmission, transmission time per packet, full packet rate, bus utilization, and error rate; isochronous transmission, frame delay, frame out-of-order rate, and frame loss rate; and interrupted transmission, interrupt response time and data update frequency.

[0206] Calibration strategy:

[0207] For batch transmission, if the transmission time of each packet is greater than 50μs, increase the shared memory block size, such as increasing it by 256KB each time, with a total size not exceeding 4MB; if the packet full rate is less than 90%, decrease the packet merging threshold, such as reducing it by 10% each time.

[0208] For isochronous transmission, if the frame delay is greater than 20μs, reduce the number of URBs; if the frame out-of-order rate is greater than 0.5%, adjust the timestamp synchronization frequency from 100Hz to 1000Hz.

[0209] If the transmission is interrupted and the response time is greater than 10μs, reduce the interrupt interval, such as by 10% each time.

[0210] Calibration period and convergence: The calibration period is set to 100ms. The gradient descent algorithm is used to adjust the parameters to ensure that the parameters converge to the optimal value within 3 periods.

[0211] Device feature adaptation library and hot loading:

[0212] The adapter library is built by predefining adapter parameter libraries for common USB device classes such as USB Mass Storage, USB CDC, USB HID, USB Audio, and USB Video. These libraries are stored in the / system / etc / usb_adapt_lib / directory. Each device class corresponds to a *.adapt file in binary format, and the optimal parameters contained therein are shown in the table below.

[0213] Table 5 Optimal Parameters for USB Device Classes

[0214] Adapter library loading: During device enumeration, the UCDD module identifies the device class based on the device's bInterfaceClass field, calls the usb_adapt_lib_load() function to load the corresponding adapter library, and applies the parameters to the transmission configuration;

[0215] Hot reloading and updating: Supports hot updating of the adaptation library via the usb_adapt_lib_update() function without restarting the container. New parameters take effect on the next transfer. When adapting to a new device, only the corresponding *.adapt file needs to be added, without modifying the code.

[0216] S7. End-to-end status verification, anomaly self-healing and efficient resource release: This embodiment implements status verification logic, optimizes the order and efficiency of resource release, and achieves rapid resource reclamation for status confirmation, anomaly recovery and resource recycling after transmission is completed.

[0217] End-to-end transmission status verification, five-level verification mechanism: After transmission is completed, the container kernel and UCDD module work together to perform five-level verification to ensure transmission reliability.

[0218] First-level verification, hardware layer: The UCDD module reads the USB controller status registers such as DEVICE_STATUS, TRANSFER_COMPLETE, and ERROR_CODE to confirm that there are no bus errors, such as BUS_ERROR bit being 0 and transfer completion bit being 1; it reads the DMA controller status registers (DMA_COMPLETE, DMA_ERROR) to confirm that the DMA transfer was successful.

[0219] Secondary verification, memory layer: The DMA cache is synchronized through the dma_sync_sg_for_cpu() function to check the data integrity of the shared memory block. If it is an input transfer, the data length is compared with actual_len; if it is an output transfer, the memory block is checked for write errors.

[0220] Level 3 verification, protocol layer: Check the status field of the URB, such as 0 to indicate success, and parse the error code, such as -ETIMEDOUT for timeout and -EPIPE for pipe error;

[0221] Level 4 verification, container layer: The container kernel verifies the status of shared memory blocks and the validity of address mappings. Verifying the status of shared memory blocks involves verifying whether the number of allocated blocks matches the transmission task packet.

[0222] Five-level verification, application layer: The Android application verifies the length and CRC value of the received data, confirms that the data is correct, and compares the CRC value with the hardware verification value.

[0223] Anomaly type identification and self-healing: Based on the five-level verification results, anomaly types are identified and graded self-healing is performed.

[0224] Level 1 exception, which is a minor error such as a CRC error: triggers URB resubmission, with a maximum of 2 retries. Before retrying, the DMA cache is resynchronized and the error flag is cleared.

[0225] Level 2 exception, a medium error, such as timeout: The UCDD module resets the USB endpoint through the ENDPOINT_RESET_REG register, reconfigures the transmission parameters such as increasing the timeout period, and resubmits the URB;

[0226] Level 3 exceptions are serious errors, such as bus errors: the USB controller is lightly reset through the CONTROLLER_SOFT_RESET register, the DMA channel and interrupt mapping are reinitialized, the shared memory pool is reused, the self-healing delay is reduced, and the self-healing success rate is increased.

[0227] Level 4 exception, fatal error, such as device disconnection: Notify the application of transmission failure and trigger the resource fast release process.

[0228] Application layer transmission result feedback and asynchronous notification optimization: A dual notification mechanism of asynchronous signals and event file descriptors (fds) is adopted to reduce application polling overhead. Specifically: Signal notification: The container kernel calls the kill_fasync() function to send a SIGIO signal to the application to notify that the transmission is complete; Event file descriptor notification: The application creates an event file descriptor (fd) through eventfd(), and after the transmission is completed, the container kernel writes 1 to the event file descriptor. The application listens for the event file descriptor through epoll_wait() to achieve polling-free waiting.

[0229] Result data transmission: Store the transmission result, such as success or failure, actual length, and error code, to / sys / container / <container_id> The / usb / transfer_result node can be quickly read by the application using the read() function.

[0230] Efficient resource release is achieved by releasing resources in the order of software resources, memory resources, and then hardware resources, enabling batch and parallel release.

[0231] In the first stage, software resources are released in batches, including URBs. The usb_free_urb_batch() function is called to release all transport URBs in batches, avoiding the loop overhead of releasing them one by one. The DMA SG table is destroyed by calling the dmaengine_unmap_sg() function to unmap the SG table in batches. The transport context is cleared by delaying the release of the transport context structure through the kfree_rcu() function to avoid RCU lock blocking.

[0232] In the second phase, memory resources are released in parallel, shared memory blocks are released, the shared memory block status table is traversed, and the block status is updated to FREE in batches through spin_lock_bh(), soft interrupts are disabled to avoid concurrent conflicts; memory pool shrinkage check, if the shrinkage threshold is met, the expanded temporary memory block is released asynchronously through workqueue without blocking the current release process; address lookup table is cleaned up, and the address mapping entries associated with the current container are removed.

[0233] In the third stage, hardware resources are released rapidly. DMA channel release calls the dma_release_channel() function to release the DMA channel and clears the DMA_CHANNEL_EXCLUSIVE bit. Interrupt resources are released by clearing the interrupt vector table direct mapping, removing interrupt affinity binding, and enabling host native interrupt handling. USB controller release involves clearing the EXCLUSIVE_ACCESS_EN bit and releasing the USB controller lock. Release optimization involves creating a dedicated work queue, usb_resource_release_wq, and executing all release operations in parallel through the work queue to avoid the cumulative delay caused by serial execution.

[0234] Resource release status monitoring and leak detection:

[0235] Release status monitoring, setting status flags such as SOFT_RELEASE_DONE, MEM_RELEASE_DONE, and HW_RELEASE_DONE at each release stage, via / sys / container / <container_id> The / usb / release_status node provides real-time feedback on the release progress;

[0236] Leak detection involves creating a resource allocation and release hash table with the resource ID as the key and the allocation timestamp as the value. Upon release, the corresponding entry is removed. After the transfer ends, the hash table is checked 500ms later. If any unreleased resources exist, they are logged. The resource ID and allocation stack are output using dmesg, and a forced release is triggered.

[0237] Device idle state reset and preparation for the next transmission:

[0238] Device state reset: The UCDD module sends the SET_INTERFACE command to the USB device to reset the interface to the default state; sends the CLEAR_FEATURE command to clear the device error flag; memory pool reset: all blocks in the shared memory block status table are marked as FREE, and the associated container ID and endpoint address are cleared; configuration cache retention: the device descriptor, address mapping, adapter library parameters and other configuration information are retained in the cache, so that the same container can reuse them directly when accessing the device again, avoiding re-enumeration and configuration.

[0239] Lightweight logging is implemented, recording only critical events such as successful enumeration, successful or failed transmission, and resource release completion. A circular buffer and asynchronous disk flushing mechanism are used: Log storage: Logs are stored in a kernel-mode circular buffer to avoid console output overhead; Asynchronous disk flushing: A log flushing thread is created using kthread, flushing logs to the ` / var / log / usb_container.log` file every second or when the buffer is full; Log level control: By default, only INFO level and above logs are recorded. During debugging, DEBUG level logging is enabled via the sysfs node without affecting normal transmission performance.

[0240] In summary, the above are merely preferred embodiments of the present invention and are not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.< / devnum> < / containerid>

Claims

1. A cross-system USB high-performance transmission method based on a hierarchical linked shared memory pool, characterized in that, Specifically, the following steps are included: When a container application initiates a USB device access request for the first time, the container business processing unit intercepts it, adds a pass-through access identifier, encapsulates it as a cross-kernel USB access request, and sends it to the host. The host triggers the USB controller to enumerate the target device, obtain the device descriptor set and hardware resource parameters, and store them in the USB device resource structure. After verifying the container's USB access permissions, the host USB manager generates a response packet containing a device descriptor set, hardware resource parameters, and an exclusive access token. The container parses the response packet to create a virtual USB device node, records the controller number and DMA channel number issued by the host in the virtual USB device node, and saves the exclusive access token; The host's container passthrough module marks the target USB device as currently exclusive to the container and binds the container identifier. It sends hardware configuration instructions to the USB controller, enables exclusive access to the container, sets the initial number of memory blocks and amplification factor according to three types of transmission modes: batch, isochronous, and interrupt, and builds a hierarchical and interconnected shared memory pool. The required memory pool capacity is obtained by the product of the initial number of memory blocks and the size of a single memory block, and memory space is allocated. The host maps the memory pool to the host virtual address, allocates virtual address ranges to the container, binds each memory block in the memory pool to the container virtual address, configures access permissions, and generates an address lookup table that records the correspondence between physical addresses and the virtual addresses of the kernels on both sides. The host sends the memory pool configuration synchronization package to the container, the container stores it in the USB shared memory configuration cache, and notifies the container business processing unit. When a container application initiates a USB data transfer request, the container service processing unit captures the request, determines the USB transfer mode, and records the container application's data buffer address in the container kernel context corresponding to this transfer. Based on the hierarchical linkage shared memory pool, it requests a shared memory block and then maps the allocated shared memory block to the container application's user-space virtual address space corresponding to the current virtual USB device node. When the application sends data to the hardware, the data is first written to the shared memory block, and then the container service processing unit generates a transfer task packet and sends it to the host's container passthrough module to complete the transmission. The method for requesting shared memory blocks based on hierarchical linkage shared memory pool is as follows: the smallest memory block among the free memory blocks that is not smaller than the target size is selected first. If the capacity of a single free memory block cannot meet the target size, multiple memory blocks of the same level are combined.

2. The cross-system USB high-performance transmission method according to claim 1, characterized in that, The size of a single memory block is calculated as the product of the maximum number of bytes that a single packet can carry at the endpoint and the amplification factor.

3. The cross-system USB high-performance transmission method according to claim 1, characterized in that, When requesting a memory block, the size of the memory block is determined based on the transfer mode of the container application bound to the current virtual USB device node. The smallest memory block not smaller than the requested size is selected from the available memory blocks. When the capacity of a single memory block is smaller than the requested size, multiple memory blocks of the same level are combined and the memory resource usage status is updated synchronously. When querying the address lookup table and converting the container kernel virtual address to a physical DMA address, the container identity is verified. The conversion is performed only if the container's identifier matches the container identifier bound to the current virtual USB device node.

4. The cross-system USB high-performance transmission method according to claim 1, characterized in that, The method by which the container service processing unit generates a transmission task packet and sends it to the container pass-through module of the host to complete the transmission is as follows: The container pass-through module first verifies the integrity of the message, and then compares whether the device exclusive access token in the transmission task packet is consistent with the device exclusive token cached on the host side. If the verification fails, the transmission task is directly rejected. If the verification passes, the DMA channel number recorded by the virtual USB device node is read, the binding with the channel corresponding to the channel number is completed, the DMA channel parameters are configured, a zero-copy URB software request block is constructed, and the DMA controller and the zero-copy URB complete the data transmission; the DMA controller marks the DMA transmission status and records the actual number of bytes transmitted, the USB controller generates the transmission completion status, and the container passthrough module generates a transmission completion response packet and sends it to the container; After receiving the transmission completion response packet, if it is an input transmission, the container reads the data from the shared memory mapping address and sends it to the application buffer; if it is an output transmission, no read operation is performed. After the transmission is completed, the memory lock is released, the memory block is reset to an idle state and returned to the hierarchical memory pool. When the application closes the virtual USB device node file descriptor, hardware and memory resources are released, and the host synchronously removes the physical device exclusive mark.

5. The cross-system USB high-performance transmission method according to claim 4, characterized in that, The data transmission method completed by the DMA controller and the zero-copy URB is as follows: During outbound transmission, the USB hardware receives the scheduling task and triggers the DMA controller, which reads the original data in batches from the shared physical memory according to the scattering list, completes the USB packetization by the internal hardware cache, and then sends it to the peripheral device through the bus; During inbound transmission, the peripheral device returns data and stores it in the USB hardware receive cache, and the DMA controller writes the data to the designated shared physical memory area.

6. The cross-system USB high-performance transmission method according to claim 1, characterized in that, The container service processing unit requests shared memory blocks according to the USB transfer mode. Specifically, it allocates a level 1 memory block for batch transfers, a level 2 memory block for isochronous transfers, and a level 3 memory block for interrupt and control transfers. It also calculates the required number of memory blocks according to the data memory pool capacity and completes the combined allocation of multiple types of resources. Finally, it maps the kernel-side shared memory address to the service user address space and grants read and write access permissions.

7. The cross-system USB high-performance transmission method according to claim 1, characterized in that, After binding the target USB device to the corresponding container, the container passthrough module obtains the hardware interrupt descriptor and interrupt number corresponding to the USB hardware, converts them into the offset of the container kernel virtual interrupt vector table, and generates a one-to-one binding mapping relationship between hardware interrupts, host interrupts, container virtual interrupts and target container identifiers, which is written into the interrupt mapping structure. The container business processing unit sets up hardware interrupt pre-processing including interrupt flag clearing, hardware transmission status reading and business transmission thread wake-up, and post-asynchronous processing including data integrity verification, hardware error type parsing, retry of recoverable transmission tasks, memory resource status update and business layer completion event notification. The host reads the container's calculation core number, generates a core binding mask, locks all USB interrupt signals to that core for operation, disables the core's deep hibernation mechanism, and retains only the shallow hibernation mode.

8. The cross-system USB high-performance transmission method according to claim 1, characterized in that, The host obtains the total number of CPU cores in the system, iterates through all CPU cores to obtain the short-term load of each core, selects idle cores with loads below the threshold, and determines the number of container cores; writes the binding relationship between cores and containers into the container configuration storage area, and synchronously constrains all USB-related business threads and interrupt handling processes within the container to run only in that core. Increase the scheduling priority of container USB-related application threads and configure the highest scheduling static priority weight; enable real-time preemptive scheduling mode for USB transfer applications and enable mutex priority protection mechanism; set the highest real-time access priority for memory read and write I / O operations corresponding to USB, create an independent I / O scheduling queue for container USB applications, bind the queue to the corresponding compute memory node, and configure a low-latency scheduling strategy for the queue. The container passthrough module sends an exclusive lock command to lock the USB controller and its associated DMA channels, and sets the maximum single transfer length of the channels; it also rebinds the interrupt handling logic, shielding the host kernel's native interrupt handling path and retaining only the container kernel's interrupt response.

9. The cross-system USB high-performance transmission method according to claim 1, characterized in that, Initialize a multi-device access priority scheduling queue, which stores the access subject identifier, container static priority, request initiation time, and hardware device path. When multiple containers successively or simultaneously request the same USB hardware, the requests are sorted according to the preset container static priority and request initiation time. High-priority containers have priority to obtain the right to use the device, while low-priority containers enter the waiting queue. After the current container releases the hardware, the highest-priority waiting container in the queue is woken up, and the cached USB hardware and memory mapping configuration is reused.

10. The cross-system USB high-performance transmission method according to claim 1, characterized in that, The container reads the USB device endpoint descriptor to determine the transfer mode as control transfer, bulk transfer, isochronous transfer, or interrupt transfer, and synchronously obtains the hardware characteristic parameters of each transfer mode. Transmission characteristic information is generated from the transmission mode type and hardware parameters and distributed to the container pass-through module; When the length of the application data packet is less than the maximum number of bytes that a single hardware packet can carry, pad the data packet before sending it. Set a data packet merging threshold. When the length of an application data packet is less than the merging threshold, the application data packet is saved to a merging buffer. Transmission is initiated when the capacity of the merging buffer is greater than the threshold or the timeout exceeds the threshold. When the length of an application data packet is greater than the maximum threshold, it is split into multiple groups of data and sent in a pipelined mode through multiple created transmission tasks. For isochronous transmission, the hardware timing identifier is read and written to the reserved storage area of ​​shared memory, the container synchronizes the timing reference, and corrects the timing offset of audio and video frames; Configure a frame loss tolerance threshold; when the transmission delay exceeds this threshold, perform frame loss interpolation compensation. Increase the scheduling priority of isochronous transmission tasks; calculate the required bandwidth based on the frame size and frame rate; and reserve corresponding bandwidth resources for real-time data streams. For interrupt transmission, read the minimum hardware reporting interval and enable it, combine multiple interrupt data within the set time window and report them in batches, and configure a circular buffer to read data in batches. For control transfers, configure the USB device with the highest scheduling priority, and merge zero-length instructions before transferring them.

Images