A method and system for tlp request shunting for firmware emulation

Abstract

The present application relates to the technical field of firmware simulation, and in particular to a TLP request shunting processing method and system for firmware simulation. The method comprises: dividing register access of each virtual device into direct response type, hardware direct writing type and firmware processing type during initialization, and registering corresponding processing strategies in a hardware shunting rule table; receiving a TLP request and obtaining a UUID, a function number and an offset through address resolution; querying the shunting rule table with three elements, and executing hardware direct response, hardware direct register access or sending the TLP request into a TLP queue for firmware processing according to the matched processing strategy. Through three-level classification and shunting, high-frequency data plane operations and invalid traffic are offloaded to hardware processing, and the firmware processing pressure is reduced by more than 90%, while supporting dynamic strategy adjustment at runtime.

Description

Technical Field

[0001] This invention relates to the field of firmware emulation technology, and more specifically to a TLP request routing processing method and system for firmware emulation. Background Technology

[0002] During the operation of a firmware-emulated PCIe (Peripheral Component Interconnect Express) device, the host-side driver performs numerous read and write operations on various registers of the emulated device. These register accesses are sent as memory-type TLP (Transaction Layer Packet) requests via the PCIe bus, and after address resolution, they reach the firmware processing unit.

[0003] These register accesses can be categorized into different types based on access frequency and logical complexity. First, there are control registers, including device configuration registers, status query registers, and interrupt control registers. These registers have a low access frequency (milliseconds to seconds) but their processing logic is relatively complex. Second, there are high-frequency data plane registers, such as the Doorbell register and DMA (Direct Memory Access) address registers. These registers have an extremely high access frequency, with accesses per second (PPS) reaching the megabyte level.

[0004] In existing firmware emulation device solutions, all register accesses—whether low-frequency control or high-frequency data—are sent to the firmware through the same processing channel, where they are parsed and processed one by one.

[0005] However, this undifferentiated processing method has the following technical drawbacks: First, high-frequency access will overwhelm the firmware's processing capabilities. Registers such as Doorbell can reach 5 MPS, while firmware, as sequentially executed software running on an ARM (Advanced RISC Machine) core, typically has a single-core processing capacity of 1 to 2 MPS. Facing a traffic of 5 MPS, it will inevitably cause backlog.

[0006] Second, invalid traffic consumes a significant amount of firmware computing power. Standard commands such as lspci on the host side traverse the entire 4KB range of the PCIe configuration space during execution, while the actual valid registers of the emulated device only occupy a small portion of it. The firmware wastes a lot of processing power by responding to these invalid requests one by one.

[0007] Third, critical and non-critical traffic interfere with each other. All register accesses follow the same path, and the firmware cannot select different processing channels for differentiated processing based on register type.

[0008] Therefore, how to offload high-frequency data register accesses and invalid traffic from the firmware processing path to direct hardware processing while ensuring the firmware's ability to fully process complex control registers is an urgent technical problem to be solved. Summary of the Invention

[0009] To address one of the aforementioned technical problems, the present invention adopts the following technical solution: According to one aspect of the present invention, a TLP request offloading processing method for firmware emulation is provided, comprising the following steps: Step S1: During the initialization phase, the firmware divides all register accesses of each virtual device into at least three categories according to a preset plan, and registers corresponding processing strategy entries for each category of access in the hardware traffic distribution rule table; the at least three categories include direct response category, hardware write-through category, and firmware processing category; Step S2: Receive the TLP request sent by the host, and obtain the UUID, function number and offset corresponding to the TLP request through address resolution; Step S3: Query the traffic splitting rule table using the UUID, function number, and offset, and execute the corresponding processing operation according to the processing strategy indicated by the matched entry: If a direct response is matched, the hardware directly returns a preset response to the host, and the process ends. If a hardware write-through class is matched, the hardware directly accesses the target hardware register and returns the result to the host, ending the process; If a firmware processing class is matched, the request data will be encapsulated and sent to the specified TLP queue for processing by the firmware.

[0010] According to a second aspect of the present invention, a TLP request offloading processing system for firmware emulation is provided, comprising: The policy registration module is used during the initialization phase to divide all register accesses of each virtual device into at least three categories according to a preset plan, and register corresponding processing policy entries for each type of access in the hardware traffic distribution rule table; the at least three categories include direct response category, hardware write-through category, and firmware processing category; The address resolution module is used to receive TLP requests sent by the host and obtain the UUID, function number and offset corresponding to the TLP request through address resolution; The traffic splitting execution module is used to query the traffic splitting rule table using UUID, function number, and offset, and execute the corresponding processing operation according to the processing strategy indicated by the matched entry: If a direct response class is matched, the hardware directly returns the preset response to the host; If a hardware write-through class is matched, the hardware directly accesses the target hardware register and returns the result to the host; If a firmware processing class is matched, the request data will be encapsulated and sent to the specified TLP queue for processing by the firmware.

[0011] This invention has at least one of the following beneficial effects: This invention, through step S1, categorizes register accesses into three types during the initialization phase: direct response, hardware write-through, and firmware processing, and registers corresponding processing strategies in the traffic splitting rule table. Step S2 receives TLP requests and parses them to obtain the UUID, function number, and offset. Step S3 queries the traffic splitting rule table using these three elements and executes the corresponding three types of processing operations based on the matching results. This constitutes a complete traffic splitting technology solution from traffic classification to differentiated processing, producing the following beneficial effects: First, it significantly reduces firmware processing pressure. Since high-frequency register accesses are categorized as hardware-to-write operations in step S1, when a hardware-to-write match is found in step S3, the hardware directly accesses the target hardware register and returns the result. High-frequency data plane operations such as Doorbell writes and DMA address settings can achieve a PPS of up to 5 Mbps. The hardware performs read / write operations directly at the circuit level, reducing processing latency from microseconds in firmware processing to nanoseconds in hardware processing. The firmware only needs to handle low-frequency control operations corresponding to the firmware processing category, thus reducing overall processing pressure.

[0012] Second, invalid traffic is filtered with zero overhead. Since invalid register accesses are classified into direct response categories in step S1, the hardware directly returns a preset response when a direct response category is matched in step S3. Read and write requests for invalid addresses in the full range of configuration space enumeration, periodic polling of unimplemented registers by the driver, and other operations are directly intercepted by the hardware and a preset response is returned, without consuming TLP queue bandwidth or firmware computing power.

[0013] Third, it supports dynamic adjustment at runtime. Since the firmware can dynamically add, delete, or modify entries in the traffic splitting rule table during runtime in step S1, the processing strategies for different types of access can be adjusted at different stages of the device lifecycle. When a new device is hot-added, its register access traffic splitting rules can be dynamically registered, and the whole process does not require shutdown or restart. Attached Figure Description

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

[0015] Figure 1 This is a flowchart of a TLP request routing method for firmware emulation provided in an embodiment of the present invention.

[0016] Figure 2 This is a structural block diagram of a TLP request routing processing method and system for firmware simulation provided in an embodiment of the present invention. Detailed Implementation

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

[0018] As a first possible embodiment of the present invention, such as Figure 1 As shown, a TLP request splitting processing method for firmware emulation is provided.

[0019] In this embodiment, the method is applied to a firmware-emulated PCIe device system in a cloud computing scenario. During the operation of the firmware-emulated device, the host-side driver performs numerous read and write operations on various registers of the emulated device. These accesses are sent as TLP requests through the PCIe bus, and after address resolution, they reach the firmware processing unit. Different types of register accesses have vastly different processing requirements—some require complex logic processing, some are high-frequency but logically simple repetitive operations, and some are completely ineffective accesses.

[0020] In this embodiment, the method includes the following steps: Step S1: During the initialization phase, the firmware divides all register accesses of each virtual device into at least three categories according to a preset plan, and registers corresponding processing strategy entries for each category of access in the hardware's traffic distribution rule table. The at least three categories include: Direct response class, corresponding to invalid address access or register access type of unimplemented address space; Hardware write-through class corresponds to high-frequency and logically simple data plane register access types; Firmware processing class, corresponding to the register access type that requires firmware logic processing.

[0021] During system initialization, the firmware first obtains the PCIe configuration space information for each virtual device to determine which registers the device implements and the address range of each register. Based on this, the firmware categorizes the registers according to their access characteristics.

[0022] Direct response scenarios primarily target two types of situations. First, host-side standard commands (such as lspci) enumerate the entire PCIe configuration space, where many address registers are not actually implemented. Second, drivers make unexpected accesses to unused address spaces. For these types of accesses, the most reasonable approach is for the hardware to directly return a pre-defined response (e.g., an invalid access response or a UR response) to inform the host that "the address is invalid," without sending the request to the firmware for processing.

[0023] Hardware-to-write operations primarily target high-frequency and logically simple data plane register accesses. Typical examples include write operations to the Doorbell register and set operations to the DMA address register. Doorbell writes can reach 5 Mbps, and their operation logic is very simple—each write only updates a hardware register or triggers a DMA operation. If such accesses were handled by firmware, each process would incur overhead such as TLP queue caching, ARM core scheduling, and firmware context switching. At an access rate of 5 Mbps, the firmware simply cannot handle this. A more reasonable approach is to directly read and write the target hardware register within the hardware acceleration unit and return the result to the host. The firmware would be completely unaware of these operations.

[0024] Firmware processing primarily targets accesses to control registers with complex logic. This includes reading and writing to the device configuration space, querying the device status register, and operating the interrupt control register. Handling these accesses often requires the firmware to perform multi-step logical judgments and state transitions based on the current device state and protocol specifications, which cannot be implemented through simple hardware circuits. These requests are sent to the TLP queue and processed by the firmware running on the ARM core.

[0025] The firmware registers corresponding processing policy entries for each type of access in the traffic splitting rule table. Entries in the traffic splitting rule table use three elements—UUID, function number, and offset—as matching keywords, and different entries cover different register address spaces.

[0026] The structure of a typical entry in the traffic splitting rule table is shown in Table 1: Table 1

[0027] It should be noted that offset matching can be done using either exact matching or range matching. For example, the offset of the Doorbell register could be any value in the range of 0x0100 to 0x01FF. In this case, the flow control rule table supports offset range matching, covering all accesses within that range.

[0028] Step S2: Receive the TLP request sent by the host, and obtain the UUID, function number and offset corresponding to the TLP request through address resolution.

[0029] Address resolution in this step refers to the process of device identification and address resolution completed through the BDF-to-UUID mapping table and KV address mapping table before the TLP request reaches the traffic splitting rule table. Specifically, the TLP request first passes through the BDF-to-UUID mapping table, looking up the UUID of the target virtual device based on the BDF (Bus / Device / Function) information in the TLP request; then it passes through the KV address mapping table, matching the address range based on the address information in the TLP request to obtain the corresponding function number FuncNo and offset. This step receives the triple output of the above preprocessing: UUID, function number FuncNo, and offset.

[0030] Step S3: Query the traffic splitting rule table using UUID, function number, and offset, and execute the corresponding processing operation according to the processing strategy indicated by the matched entry.

[0031] If a direct response is matched, the hardware directly returns a preset response to the host, and the process ends.

[0032] If a hardware write-through class is matched, the hardware directly accesses the target hardware register and returns the result to the host, ending the process.

[0033] If a firmware processing class is matched, the request data will be encapsulated and sent to the specified TLP queue for processing by the firmware.

[0034] The following example illustrates the traffic splitting decision process. Assume a virtual network interface card (NIC) device (UUID=3) has a Doorbell register offset of 0x0200. This offset is registered in the traffic splitting rule table with a hardware write-through policy. When the host driver writes data to the Doorbell, the TLP request, after address resolution, yields (UUID=3, FuncNo=5, Offset=0x0200). The hardware uses this triple to query the traffic splitting rule table and matches the hardware write-through policy. The hardware then directly performs a write operation on the Doorbell register and returns the result to the host. The entire process is completed in nanoseconds, with zero firmware awareness.

[0035] Let's assume that the processing strategy corresponding to the configuration space offset 0x0010 of this virtual network interface device is firmware processing. When the host reads the value of this register, the TLP request is parsed and matched to the firmware processing class. The request data is encapsulated and sent to the specified TLP queue. The firmware reads the device configuration information according to the request content and returns the result.

[0036] During device operation, the firmware can dynamically add, delete, or modify entries in the traffic distribution rule table based on changes in workload characteristics to adjust the processing strategy for different types of access. For example, during device initialization, access to certain configuration registers requires firmware processing; after the device enters a stable operating state, access to these configuration registers may no longer require firmware intervention, and the firmware can dynamically change its processing strategy from firmware processing to hardware write-through, further improving processing efficiency.

[0037] As a second possible embodiment of the present invention, based on step S3 in the first embodiment where firmware processing requests are sent to the TLP queue for firmware processing, a dynamic traffic migration and order preservation scheme for the TLP queue is further provided.

[0038] The first embodiment implements the classification and processing of TLP requests through a traffic splitting rule table. Requests for direct response and hardware write-through are processed directly at the hardware level, without going through the TLP queue. Requests for firmware processing are sent to the TLP queue, awaiting retrieval and processing by the ARM core. This classification mechanism allows the firmware to handle only about 10% of the requests, significantly reducing processing pressure.

[0039] However, in actual operation, the load between different TLP queues is naturally unbalanced. Each TLP queue carries firmware processing requests for multiple virtual devices, and the traffic characteristics of different virtual devices may be quite different. At any given time, the TLP queues corresponding to some popular virtual devices may be under high load, with a large backlog of requests; while the TLP queues corresponding to other less popular devices may be relatively idle. If this load imbalance persists, the processing latency of requests in the high-load queues will continue to increase. When the latency exceeds the TLP response timeout threshold specified in the PCIe specification, the host will trigger a PCIe transaction timeout error, which can lead to host crashes or virtual machine crashes in severe cases.

[0040] This embodiment provides a dynamic migration and order preservation scheme to address the aforementioned problem of unbalanced load in the TLP queue.

[0041] In this embodiment, after step S3, the method further includes the following steps: Step S4: The firmware continuously monitors the number of pending messages in each TLP queue.

[0042] The firmware obtains the current depth information of each TLP queue by reading the hardware status register of the TLP queue. The depth information represents the number of pending packets. Specifically, it represents the number of packets that have been queued but not yet processed by the ARM core. The firmware reads the depth of all TLP queues at a fixed monitoring period (e.g., every 100 microseconds) and records the depth values ​​in the queue status table. An example of the current depth record for each TLP queue in the queue status table is shown in Table 2. Table 2

[0043] Step S5: When the number of pending messages in the first TLP queue exceeds a preset threshold, determine the virtual devices to be migrated out from the virtual devices carried by the first TLP queue, and select the second TLP queue as the migration target.

[0044] Both the first TLP queue and the second TLP queue are currently existing TLP queues. The number of pending messages in the second TLP queue is less than the number of pending messages in the first TLP queue.

[0045] Taking Table 2 as an example, the preset threshold is set to 80. The firmware detects that the current depth of TLPQ1 is 85, which exceeds the preset threshold of 80, so TLPQ1 is identified as the first TLP queue. The firmware checks that the current depth of TLPQ2 is 8, which is significantly less than the 85 of TLPQ1, and the ARM core load rate bound to TLPQ2 is only 12% (that is, the ARM core load rate bound to TLPQ2 is less than the preset idle threshold), so TLPQ2 is selected as the second TLP queue (migration target).

[0046] The methods for determining virtual devices to be migrated out include at least one of the following: Method 1: Identify the single virtual device with the highest request frequency as the virtual device to be migrated out. The firmware identifies the device with the highest request frequency by counting the number of requests generated by each virtual device within the most recent time window (e.g., the last second). This method is suitable for scenarios where a single popular device causes queue overload.

[0047] Method 2: Identify all instances of the virtual device category with the highest total request volume as virtual devices to be migrated out. For example, migrate all virtual network interface devices (VirtualNet) as a whole. This method is suitable for scenarios where a certain type of device generates a large number of requests concentrated in a specific period of time.

[0048] Method 3: When the traffic share of a single virtual device exceeds the first traffic threshold, that single virtual device is identified as a virtual device to be migrated out. When the cumulative traffic share of similar virtual devices exceeds the second traffic threshold, all instances of that type of virtual device are identified as virtual devices to be migrated out. This hybrid judgment method takes into account the traffic characteristics of both single devices and similar devices, resulting in more accurate migration decisions.

[0049] Method 4: Predict future trends based on the traffic patterns of each virtual device within historical time windows, identifying potentially overloaded virtual devices as those to be migrated out. The firmware records the request frequency of each virtual device over multiple past time windows. By analyzing the changing trends of request frequency, the firmware can predict which devices are likely to experience traffic surges in the near future. Before overload actually occurs, the firmware proactively migrates these devices out of the idle queue. This predictive migration mechanism elevates load balancing from a passive response to proactive prevention.

[0050] Step S6: The firmware reads the remaining number K of virtual devices to be migrated out in the first TLP queue.

[0051] The firmware can query the hardware status register of the TLP queue to determine the number of unprocessed packets belonging to a specific UUID in the current queue. Assuming the virtual device to be migrated out has UUID=5, the remaining number of packets for that device in TLPQ1 is K=10.

[0052] Step S7: The firmware modifies the entry corresponding to the virtual device to be migrated out in the traffic splitting rule table so that subsequent new TLP requests from the virtual device to be migrated out are routed to the second TLP queue.

[0053] Specifically, each entry in the traffic splitting rule table contains a processing policy field (indicating whether the request belongs to the direct response, hardware write, or firmware processing category) and a target TLP queue routing information field, indicating the TLP queue number to which the request should be sent when a firmware processing category is matched. The firmware modifies this routing information field to change the target TLP queue for the virtual device to be migrated out from the first TLP queue to the second TLP queue, without modifying the entry's processing policy field. Simultaneously, the firmware records the state of the entry in the traffic splitting rule table for the virtual device to be migrated out before and after modification as a migration log to support subsequent migration status tracking and troubleshooting.

[0054] Step S8: The first TLP queue continues to process the remaining K messages of the virtual device to be migrated out. After receiving a new request from the virtual device to be migrated out, the second TLP queue stores it in the buffer without executing it immediately.

[0055] This is the core design of the order-preserving migration. Since there are still 10 unprocessed packets belonging to devices to be migrated out in the first TLP queue, if the second TLP queue starts processing new requests immediately upon receiving them, the new requests would be processed before the old ones, causing packet order disorder. Therefore, upon receiving a new request, the second TLP queue only stores the request in a dedicated buffer area and does not immediately execute it. The buffer area is a buffer space allocated in memory by the firmware and organized in FIFO order.

[0056] During this period, the first TLP queue continues to process messages from all virtual devices within it in normal FIFO order—including the remaining K messages from the device to be migrated out and messages from other non-migration devices. Requests from other non-migration devices are processed normally in both the first and second TLP queues and are unaffected by the migration.

[0057] The order-preserving mechanism during the migration process is illustrated in Table 3 below using a sequence diagram: Table 3

[0058] Step S9: When it is detected that all K packets of virtual devices to be migrated out in the first TLP queue have been processed, send a migration completion notification to the second TLP queue.

[0059] The firmware continuously tracks the number of remaining packets for the device to be migrated out through the status register of the first TLP queue. When the number of remaining packets drops to 0, it indicates that there are no more pending packets for that device in the first TLP queue.

[0060] Step S10: After receiving the notification, the second TLP queue processes the requests for virtual devices to be migrated out of the cache in sequence. After the cache is cleared, newly arriving requests enter real-time processing mode.

[0061] The second TLP queue processes requests from devices awaiting migration one by one according to the FIFO order of the buffer. Once all requests in the buffer have been processed, the device enters normal operation on the second TLP queue. Subsequent new TLP requests no longer pass through the buffer and directly enter the real-time processing flow.

[0062] After the migration is complete, the firmware updates the real-time processing status of the virtual devices to be migrated out in the second TLP queue to the queue management table. The queue management table records the TLP queue currently bound to each virtual device and its processing status, for use in subsequent load monitoring and migration decisions.

[0063] Through the order-preserving migration mechanism described in steps S4 to S10, the system seamlessly migrates some devices from the high-load queue to the low-load queue. During the migration, old packets are processed in order in the source queue, while new packets are buffered and waiting in the target queue. Once all old packets have been processed, new packets begin execution in order. The entire process is completely transparent to the host, with no packet loss or out-of-order delivery. Combined with a traffic prediction mechanism, the system can proactively adjust the load distribution before an overload actually occurs, achieving preventative load balancing.

[0064] As a third possible embodiment of the present invention, such as Figure 2 As shown, based on the method described in steps S1 to S3 of the first embodiment, a TLP request splitting processing system for firmware emulation is also provided.

[0065] In this embodiment, the system includes: The policy registration module is used during the initialization phase to classify all register accesses of each virtual device into at least three categories according to a preset plan, and register corresponding processing policy entries for each type of access in the hardware traffic distribution rule table. The at least three categories include: direct response category, corresponding to invalid address access or register access types with unimplemented address spaces; hardware write-through category, corresponding to high-frequency and logically simple data plane register access types; and firmware processing category, corresponding to register access types requiring firmware logic processing.

[0066] The address resolution module is used to receive TLP requests sent by the host and obtain the UUID, function number and offset corresponding to the TLP request through address resolution.

[0067] The traffic splitting execution module is used to query the traffic splitting rule table using UUID, function number, and offset, and execute the corresponding processing operation according to the processing strategy indicated by the matched entry: if a direct response class is matched, the hardware directly returns a preset response to the host; if a hardware write class is matched, the hardware directly accesses the target hardware register and returns the result to the host; if a firmware processing class is matched, the request data is encapsulated and sent to the specified TLP queue for processing by the firmware.

[0068] The functions of each module described above correspond completely to the methods described in steps S1 to S3 of Embodiment 1. The data flow and working relationships between the modules are consistent with the step sequence in Embodiment 1, and will not be repeated here.

[0069] Furthermore, although the steps of the method in this disclosure are described in a specific order in the accompanying drawings, this does not require or imply that the steps must be performed in that specific order, or that all the steps shown must be performed to achieve the desired result. Additional or alternative steps may be omitted, multiple steps may be combined into one step, and / or a step may be broken down into multiple steps.

[0070] Furthermore, the accompanying drawings are merely illustrative of the processes included in the method according to exemplary embodiments of the present invention and are not intended to be limiting. It is readily understood that the processes shown in the above drawings do not indicate or limit the temporal order of these processes. Additionally, it is readily understood that these processes may be executed synchronously or asynchronously, for example, in multiple modules.

[0071] It should be noted that although several modules or units for the device used to perform actions have been mentioned in the detailed description above, this division is not mandatory. In fact, according to embodiments of this disclosure, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.

[0072] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A TLP request routing processing method for firmware emulation, characterized in that, Includes the following steps: Step S1: During the initialization phase, the firmware divides all register accesses of each virtual device into at least three categories according to the preset plan, and registers corresponding processing strategy entries for each type of access in the hardware traffic distribution rule table. At least the three categories mentioned include: Direct response class, corresponding to invalid address access or register access type of unimplemented address space; Hardware write-through class corresponds to high-frequency and logically simple data plane register access types; Firmware processing class, corresponding to the register access type that requires firmware logic processing; Step S2: Receive the TLP request sent by the host, and obtain the UUID, function number and offset corresponding to the TLP request through address resolution; Step S3: Query the traffic splitting rule table using the UUID, function number, and offset, and execute the corresponding processing operation according to the processing strategy indicated by the matched entry: If a direct response is matched, the hardware directly returns a preset response to the host, and the process ends. If a hardware write-through class is matched, the hardware directly accesses the target hardware register and returns the result to the host, ending the process; If a firmware processing class is matched, the request data will be encapsulated and sent to the specified TLP queue for processing by the firmware. The method further includes: Step S4: The firmware continuously monitors the number of pending messages in each TLP queue; Step S5: When the number of pending messages in the first TLP queue exceeds a preset threshold, determine the virtual devices to be migrated out from the virtual devices carried by the first TLP queue, and select the second TLP queue as the migration target; wherein the first TLP queue and the second TLP queue are both currently existing TLP queues, and the number of pending messages in the second TLP queue is less than the number of pending messages in the first TLP queue. Step S6: The firmware reads the remaining number K of virtual devices to be migrated out in the first TLP queue; Step S7: The firmware modifies the entry corresponding to the virtual device to be migrated out in the traffic splitting rule table, so that subsequent new TLP requests arriving from the virtual device to be migrated out are routed to the second TLP queue; Step S8: The first TLP queue continues to process the remaining K packets of the virtual device to be migrated out, and the second TLP queue stores the new request for the virtual device to be migrated out in the buffer without immediate execution. Step S9: When it is detected that all K packets of virtual devices to be migrated out in the first TLP queue have been processed, send a migration completion notification to the second TLP queue; Step S10: After receiving the notification, the second TLP queue processes the requests for virtual devices to be migrated out of the cache in sequence. After the cache is cleared, the newly arrived requests enter the real-time processing mode.

2. The method according to claim 1, characterized in that, The entries in the traffic splitting rule table use UUID, function number, and offset as matching keywords, and different entries cover different register address spaces.

3. The method according to claim 1, characterized in that, Register accesses for the direct response class include invalid address accesses and unimplemented configuration space enumeration requests; register accesses for the hardware write-through class include Doorbell writes and DMA address setting operations; register accesses for the firmware processing class include device configuration, status queries, and interrupt control operations.

4. The method according to claim 1, characterized in that, In step S1, the firmware dynamically adds, deletes, or modifies entries in the traffic splitting rule table based on changes in workload characteristics during device operation, in order to adjust the processing strategy for each type of access.

5. The method according to claim 1, characterized in that, The method for determining the virtual device to be migrated out in step S5 includes at least one of the following: The single virtual device with the highest request frequency is identified as the virtual device to be migrated out; All instances of the virtual device with the largest total request volume are identified as virtual devices to be migrated out; When the traffic share of a single virtual device exceeds the first traffic threshold, that single virtual device is identified as a virtual device to be migrated out; when the cumulative traffic share of similar virtual devices exceeds the second traffic threshold, all instances of that type of virtual device are identified as virtual devices to be migrated out. Based on the traffic patterns of each virtual device within a historical time window, future trends are predicted, and virtual devices that may be overloaded are identified as virtual devices to be migrated out.

6. The method according to claim 1, characterized in that, The methods for selecting the second TLP queue in step S5 include: Step S5.1: Query the number of pending messages in all TLP queues and select the queue with the smallest number of pending messages as the migration target; Step S5.2: When there are multiple queues with the same number of pending messages, select the queue with the lowest processing core load rate.

7. The method according to claim 1, characterized in that, Step S7 also includes: Step S7.1: Record the status of the entries in the traffic splitting rule table corresponding to the virtual device to be migrated out before and after modification as a migration log.

8. The method according to claim 1, characterized in that, After the migration is completed, the method further includes: Step S11: The firmware updates the real-time processing status of the virtual device to be migrated out in the second TLP queue to the queue management table.

9. A TLP request routing processing system for firmware emulation, characterized in that, include: The policy registration module is used during the initialization phase to divide all register accesses of each virtual device into at least three categories according to a preset plan, and register corresponding processing policy entries for each category of access in the hardware's traffic distribution rule table. At least the three categories mentioned include: Direct response class, corresponding to invalid address access or register access type of unimplemented address space; Hardware write-through class corresponds to high-frequency and logically simple data plane register access types; Firmware processing class, corresponding to the register access type that requires firmware logic processing; The address resolution module is used to receive TLP requests sent by the host and obtain the UUID, function number and offset corresponding to the TLP request through address resolution; The traffic splitting execution module is used to query the traffic splitting rule table using UUID, function number, and offset, and execute the corresponding processing operation according to the processing strategy indicated by the matched entry: If a direct response class is matched, the hardware directly returns the preset response to the host; If a hardware write-through class is matched, the hardware directly accesses the target hardware register and returns the result to the host; If a firmware processing class is matched, the request data will be encapsulated and sent to the specified TLP queue for processing by the firmware. Also includes: Step S4: The firmware continuously monitors the number of pending messages in each TLP queue; Step S5: When the number of pending messages in the first TLP queue exceeds a preset threshold, determine the virtual devices to be migrated out from the virtual devices carried by the first TLP queue, and select the second TLP queue as the migration target; wherein the first TLP queue and the second TLP queue are both currently existing TLP queues, and the number of pending messages in the second TLP queue is less than the number of pending messages in the first TLP queue. Step S6: The firmware reads the remaining number K of virtual devices to be migrated out in the first TLP queue; Step S7: The firmware modifies the entry corresponding to the virtual device to be migrated out in the traffic splitting rule table, so that subsequent new TLP requests arriving from the virtual device to be migrated out are routed to the second TLP queue; Step S8: The first TLP queue continues to process the remaining K packets of the virtual device to be migrated out, and the second TLP queue stores the new request for the virtual device to be migrated out in the buffer without immediate execution. Step S9: When it is detected that all K packets of virtual devices to be migrated out in the first TLP queue have been processed, send a migration completion notification to the second TLP queue; Step S10: After receiving the notification, the second TLP queue processes the requests for virtual devices to be migrated out of the cache in sequence. After the cache is cleared, the newly arrived requests enter the real-time processing mode.

Images