An enumeration and routing method, device and medium for PCIe switch software emulation

Abstract

The application provides a PCIe Switch soft simulation enumeration and routing method, device and medium, relates to the PCIe Switch technical field, and comprises the following steps: constructing a PCIe Switch virtual module; intercepting a first CFG TLP to extract a Usp bus ID, and forcing all Dsp bus IDs to be Usp+1; provisioning each port device number and function number, and establishing a Dsp array; when routing, judging whether a TLP bus ID matches the Dsp_bus, if yes, directly taking the device number as an index to address the Dsp[n]; configuring a Watcher to monitor reading and writing, and synchronizing the software and hardware CSR states; configuring a proxy answering logic; and splicing a target port actual BDF and an internal function number into the high 4 bytes of a returned FEP message for hardware identification and auxiliary service message routing; and the application improves the stability of the virtualization enumeration process.

Description

Technical Field

[0001] This invention relates to the field of PCIe Switch technology, and in particular to an enumeration and routing method, device and medium for PCIe Switch software emulation. Background Technology

[0002] In traditional PCIe software-emulated switch solutions, existing technologies typically require simulating the complete hardware enumeration interaction process. During the host enumeration phase, the host discovers devices by scanning BDF combinations through cascading CFG TLPs. However, existing virtual switches lack the ability to actively intercept the host's first TLP and coordinate with the global bus ID (Bus), easily leading to discrepancies between the software-emulated uplink and downlink port topologies and the host's expectations. Simultaneously, traditional software forwarding mechanisms rely on reading routing tables within the configuration space or performing traversal comparisons. As the number of ports increases, forwarding efficiency drops significantly, and there is a lack of efficient real-time linkage between the software-emulated configuration space and the underlying actual hardware CSR registers, making state desynchronization prone to occur. Furthermore, when the host enumerates and scans a virtual DSP port without an attached EP device, if it directly returns a standard PCIe error state (such as UR), the host's PCIe enumeration driver may determine enumeration failure or even cause system anomalies in some server environments, severely impacting the stability of the virtualization enumeration process. Summary of the Invention

[0003] To address the aforementioned technical problems, the technical solution adopted by this invention is as follows:

[0004] According to a first aspect of this application, an enumeration and routing method for PCIe Switch software emulation is provided, comprising:

[0005] Construct a virtual PCIe Switch software module; the software module includes a topology of one uplink port Usp and N downlink ports DSP;

[0006] Initialize the Usp and wait for the first CFG TLP to be accessed. When the Usp receives the first CFG TLP, extract the Usp bus ID allocated by the host and record it as Usp_bus. Then set the bus ID of all DSP ports in the next level to Dsp_bus, satisfying Dsp_bus=Usp_bus+1.

[0007] Pre-configure the device number Device_ID and function number Function_ID for each Usp and each DSP, and construct an array of DSP software structures that correspond one-to-one with each DSP in the software module;

[0008] Parse the target BDF in the subsequent CFG TLP. If the target bus ID is equal to Dsp_bus, extract the Device_ID field in the corresponding CFG TLP as index n, and locate the nth downlink port Dsp[n] in the Dsp software structure array.

[0009] Configure the Watcher mechanism to attach callbacks before and after reading and writing to the Usp / Dsp configuration space, identify fields that need to be linked to the underlying hardware CSR and write them synchronously;

[0010] Configure the response logic to return an SC status code and all F data for CFG TLP pointing to an invalid BDF or a DSP port that is not connected to an EP in order to avoid enumeration exceptions.

[0011] After processing the CFG TLP, the BDF value determined by the target port and the hardware function number are concatenated into the high 4 bytes of the Data field of the returned FEP message.

[0012] According to another aspect of this application, a computer-readable storage medium is also provided, on which a computer program is stored, which, when executed by a processor, implements the enumeration and routing method for PCIe Switch soft emulation as described in the first aspect.

[0013] According to another aspect of this application, a PCIe Switch virtualization device is also provided, including an underlying hardware FEP and a software module and processor running on the hardware. The underlying hardware FEP has a built-in hardware CSR register and a physical channel interface that supports PCIe TLP message transmission and DMA data pass-through interaction. The software module is configured to execute the enumeration and routing method of PCIe Switch soft emulation as described in the first aspect.

[0014] The present invention has at least the following beneficial effects:

[0015] The enumeration and routing method for PCIe Switch software emulation in this invention firstly intercepts the first CFGTLP and extracts Usp_bus, forcibly assigning the lower-level Dsp_bus to Usp_bus+1, thus achieving complete software-driven control of the bus topology logic. This bypasses the traditional enumeration process based on physical hardware negotiation, ensuring the deterministic presentation of the Switch topology on the host side. Secondly, by pre-setting the device number of each port and constructing a Dsp structure array, the Device_ID field in the CFGTLP is directly extracted as the array index during routing forwarding, achieving fast routing with O(1) complexity and no traversal, greatly reducing the CPU computing power overhead of virtual port addressing. Thirdly, a Watcher mechanism for mounting callbacks before and after configuration space read / write is introduced to accurately intercept configuration actions that need to be linked to the hardware CSR and write them synchronously, effectively solving the logical conflict caused by the separation of software configuration space and underlying hardware state. Meanwhile, by returning a successful SC status code and a full F data response logic, it not only adapts to the enumeration process of various server host PCIe drivers, but also effectively avoids the potential risk of triggering host enumeration exceptions due to accessing DSP ports not connected to EPs. Finally, after processing the CFG TLP, the determined BDF value and hardware function number are concatenated into the high 4 bytes of the Data field of the return message. This eliminates the need for the underlying FEP hardware to adapt the BDF mapping itself, greatly simplifying the hardware-side send / receive processing logic and improving the stability of the virtualization enumeration process. Attached Figure Description

[0016] 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.

[0017] Figure 1 A flowchart of the enumeration and routing method for PCIe Switch soft emulation provided in an embodiment of the present invention. Detailed Implementation

[0018] 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.

[0019] It should be noted that, based on this disclosure, those skilled in the art will understand that one aspect described herein can be implemented independently of any other aspect, and two or more of these aspects can be combined in various ways. For example, any number of aspects set forth herein can be used to implement the device and / or practice the method. Furthermore, this device and / or practice the method can be implemented using other structures and / or functionalities besides one or more of the aspects set forth herein.

[0020] The following will refer to Figure 1 The flowchart shown illustrates an enumeration and routing method for PCIe Switch software emulation, introducing such a method.

[0021] The enumeration and routing method for the PCIe switch software emulation may include the following steps:

[0022] S100, construct a virtual PCIe Switch software module; the software module includes a topology of one uplink port Usp and N downlink ports Dsp.

[0023] In this embodiment, this step does not rely on a specific physical hardware link, but rather builds an independent software runtime environment based on a user-space device emulation framework (e.g., using the open-source framework libvfio-user or a similar library that supports PCIe device emulation). In this environment, a virtual PCI bus device object needs to be registered as the entry point for the entire switch; this entry point will capture MMIO and CFG TLP messages sent by the host through the PCIe bus (or the emulated bus channel) in subsequent steps.

[0024] To achieve hardware-software decoupling and fast addressing, data structures for the uplink port (Usp) and downlink port (Dsp) need to be defined separately in the software memory space in S100. The specific implementation is as follows:

[0025] Define a struct pcie_usp structure, which contains at least the following: a 256-byte PCIe Type 1 Header configuration space buffer, the bus number (bus), device number (dev), and function number (func) currently assigned to the port, and a pointer to the underlying hardware CSR interaction interface.

[0026] Define a struct pcie_dsp ​​structure, which also contains a 256-byte Type1 Header configuration space, bus number (bus), device number (dev), function number (func), as well as an attached flag (attached_flag) to record the connection status of the attached EP device and a pointer to the attached EP device.

[0027] When defining the data structure, the function ID of Usp and all DSPs is pre-written as 0, and the device ID is pre-numbered according to the N value required by the actual product (such as 32 for Crystal architecture or 64 for Andes architecture).

[0028] After defining the data structure, S100 will instantiate one Usp object and N DSP objects in memory. Specifically, an array of DSP software structures is constructed: a pointer array of dimension N, struct pcie_dsp ​​× dsp_ports[N], is created (or an array of objects is declared directly). The indices of each element in this array form a fixed one-to-one mapping with the preset Device_ID. For example, if the current solution requires 32 DSPs (Crystal scenario), during loop initialization, the device number of the i-th DSP structure is directly set to i, and the pointer is added to dsp_ports[i].

[0029] Simultaneously, during instantiation, a callback function for receiving TLP messages needs to be registered for the Switch module, enabling it to receive CFG TLP messages from the host in real time during subsequent steps. Before and after reading and writing to the configuration space, watcher mechanisms also need to be pre-attached to ensure that subsequent steps can directly identify configuration fields requiring hardware linkage.

[0030] For example, taking the Crystal scenario with 1 Usp and 32 DSPs as an example. When the S100 starts: Usp.device_id=0; Usp.func_id=0; The DSP array is constructed through a loop statement, and values ​​are assigned sequentially: For(int i=0;i<32;i++){Dsp_ports[i].device_id=i;Dsp_ports[i].func_id=0;}, and the default bus number of the DSP structure element is initialized to 0.

[0031] At this point, the software module already has 32 virtual downlink port objects that correspond to physical layer hardware resources, but it has not yet established enumeration interaction with the host and is in a state of waiting for the first CFG TLP.

[0032] This step standardizes the definition of the Usp and DSP software architectures and pre-instantiates them as arrays during the initialization phase, transforming the actual downlink physical ports of the hardware chip into a linearly arranged address space in software memory. This static data structure mapping directly provides the physical storage foundation for the subsequent high-speed routing mapping of TLP packets. Furthermore, by forcibly fixing the Function_ID to 0 during initialization and pre-setting the Device_ID according to a set pattern, topological ambiguity caused by random ID allocation in the standard PCIe stack during subsequent enumeration is eliminated. This ensures that each Usp / DSP port and the EP subtree below it possesses highly deterministic and easily traceable index logic when facing host enumeration requests, laying a well-isolated data structure foundation for the subsequent implementation of high-response-speed hardware-software collaborative forwarding and hot-plug state machines.

[0033] S200 initializes the Usp and waits for the first CFG TLP to be accessed. When the Usp receives the first CFG TLP, it extracts the Usp bus ID allocated by the host and records it as Usp_bus, and sets the bus ID of all DSP ports in the next level to DSP_bus, satisfying DSP_bus=Usp_bus+1.

[0034] In this embodiment, after the software structure of the virtual port is instantiated in step S100, the Usp port in the software module does not immediately report the "device ready" status to the host, but is in a silent waiting (blind waiting) mode. In actual implementation, a TLP message reception callback function has been registered on the underlying communication channel corresponding to the Usp in stage S100. At this time, the callback function is in a probing state: if no CFG TLP has been received, the Usp does not actively intervene in the enumeration requests of each bus, and is only responsible for intercepting and parsing the first CFG configuration space access message delivered by the host through the underlying hardware FEP (usually the initial configuration read request initiated by the host BIOS or operating system PCIe enumeration driver to the downstream of the root port).

[0035] When the host sends the first CFG TLP for the Usp, the callback function is triggered. The software module parses the BDF information of the target device from the header of the TLP message. The key action is that, without relying on the specific read / write data of the TLP, it extracts the target bus number (Bus ID) carried in the TLP and records this value into the software-maintained global variable Usp_bus. In actual engineering, this means that the Usp has been assigned a specific physical topology number by the host, and at this time, the primary bus field in the Usp structure will be filled with the extracted Usp_bus value.

[0036] After obtaining and assigning a value to Usp_bus, the software module performs a fixed calculation based on the topology logic in the PCIe protocol that "when a bridged device extends the bus downward, the lower-level bus number is usually the upper-level bus number plus 1". Dsp_bus = Usp_bus + 1.

[0037] Subsequently, the software module directly traverses the array of Dsp structures (i.e., dsp_ports[0] to dsp_ports[N-1]) constructed in step S100, and synchronously forces the bus number field (bus_id) of each Dsp software structure in the array to be calculated as Dsp_bus.

[0038] After this assignment is completed, no matter which DSP the host subsequently issues an enumeration request to, its bus ID will logically match this uniformly set DSP_bus, so that the addressing logic of the DSP port has completed all preparations in the early stage of enumeration.

[0039] For example, taking a Crystal hardware architecture with 1 Usp + 32 DSPs as an example, the host sends the first CFG read TLP with a target BDF of 00:00.0. This message reaches the software module through the underlying channel, and the software module parses the bus number 00. The software module assigns the Usp_bus variable to 00. The software module calculates Dsp_bus = 00 + 1 = 01 according to the formula. Then, the software module enters a loop for(i=0;i<32;i++){dsp_ports[i].bus_id=01;}, setting the soft bus number of all 32 DSP ports to 01. At this point, in the host's subsequent enumeration, as long as the target bus number of the CFG TLP it sends is 01, the software module can clearly determine that this is an access to a DSP port.

[0040] By intercepting the first CFG TLP and extracting the bus number obtained by the Usp, the bus numbers of all lower-level DSPs are forcibly preset to Usp_bus plus 1. This step directly establishes a lower-level bus structure that conforms to the PCIe specification and is free from branch ambiguity for the virtual Switch topology at the software level. Since the DSP bus number is uniformly assigned a fixed value, and this value is strictly incrementally related to the Usp bus number, the software module can quickly make routing decisions based on the matching results when the host enumerates each DSP port and the attached EP device. This fundamentally avoids the problem of random bus number allocation caused by host enumeration timing, interrupts, or differences in underlying hardware. It also provides a definite bus ID comparison base value for the subsequent steps to achieve fast array index mapping using the target Device_ID.

[0041] S300 pre-configures the device number Device_ID and function number Function_ID for each Usp and each DSP, and constructs an array of DSP software structures that correspond one-to-one with each DSP in the software module.

[0042] This step is crucial for building the foundation for virtual PCIe Switch routing and enumeration. The core of this step is to statically pre-configure the Device_ID and Function_ID in the BDF triplet for all virtual port objects (Usp and N DSPs) in the software module according to the actual project architecture, and to establish the corresponding software array to provide data structure support for subsequent steps.

[0043] Furthermore, in the pre-configured device number Device_ID and function number Function_ID for each Usp and each DSP, the Function_ID for each port is fixedly configured to 0.

[0044] When initializing the Usp structure, the software module strictly adheres to the requirements of the current hardware project and writes the corresponding fields into the hardware registers or software configuration space: for Crystal or Andes projects, the Device_ID of Usp is forcibly preset to 00, and the Function_ID is forcibly preset to 0. During host enumeration, the complete BDF corresponding to Usp is [allocated bus number]:00.0.

[0045] If based on the Andes hardware architecture, the Device_ID of the Usp is fixed at 00, and the device numbers of the 64 DSPs are assigned from 00 to 31 according to the preset mapping. That is, each device number in the 64 DSPs corresponds to two DSPs.

[0046] If based on the Crystal hardware architecture, the Device_ID of the Usp is fixed at 00, and the device numbers of the 32 DSPs are assigned sequentially from 00 to 31 according to the port index.

[0047] When configuring Device_ID and Function_ID for N DSPs, different allocation strategies are adopted based on the actual chip hardware architecture targeted by the project:

[0048] Based on the Crystal hardware architecture (N=32): Since the total number of ports perfectly matches the maximum value of the 5-bit Device_ID (0~31), the initialization process is relatively straightforward. The software module iterates through the DSP array indices from 0 to 31, directly assigning each array index i to the corresponding DSP's Device_ID, and uniformly fixing the Function_ID of all DSPs to 0. At this point, the BDF corresponding to Dsp[i] is [Dsp_bus]:[i].0.

[0049] Based on the Andes hardware architecture (N=64): Since there are 64 downstream ports, and the Device_ID field in the PCIe configuration space only supports values ​​from 0 to 31, the Function_ID space needs to be used to distinguish ports. Specifically, when the software module traverses the DSP indices from 0 to 63, it uses an algorithm that divides the index by 2 and then rounds down. When the DSP index is even (e.g., 0, 2, 4...), its Device_ID is set to index / 2, and its Function_ID is set to 0; when the DSP index is odd (e.g., 1, 3, 5...), its Device_ID is also set to (index - 1) / 2 (i.e., integer division), and its Function_ID is set to 1.

[0050] After completing the ID allocation, the software module requests or initializes an index-based DSP software structure array in memory. The length of this array is N, and the array index n is strictly bound to the logical sequence number of the DSP port managed by the software.

[0051] During construction, the calculated Device_ID and Function_ID are written as member variables into the corresponding struct pcie_dsp ​​structure of each array element. Simultaneously, the memory mapping address or control handle corresponding to the underlying hardware is pre-associated to the corresponding element of this structure array.

[0052] This step decouples the virtual switch structure from the BDF number in the standard PCIe enumeration process by pre-configuring the Device_ID and Function_ID of the Usp and each DSP deterministically and statically at software module startup. Since there is a deducible linear mapping between the software array index and the configured Device_ID and Function_ID, subsequent steps can directly convert the device number extracted from the TLP into an array index when processing CFG TLP access on any DSP, without consuming any computing power to maintain a hash table or lookup table. Simultaneously, two sets of PCIe protocol-compatible device number arrangement algorithms were developed for Andes and Crystal products with different hardware scales, ensuring seamless compatibility of a single software framework across multiple projects with varying numbers of physical ports.

[0053] S400, parse the target BDF in the subsequent CFGTLP. If the target bus ID is equal to Dsp_bus, extract the Device_ID field in the corresponding CFGTLP as index n, and locate the nth downlink port Dsp[n] in the Dsp software structure array.

[0054] This step is the substantive triggering stage for the virtual PCIe Switch software module to complete the routing and forwarding function. Its core lies in simplifying the parsing process of CFG TLP packets directly into array offset calculation, thereby achieving zero-overhead port location.

[0055] Furthermore, when locating the nth downlink port Dsp[n] in the Dsp software structure array, the formula n = Device_ID in the current CFG TLP message is used for mapping. The pre-established fixed mapping relationship between the device number and the Dsp structure index is used to directly locate the corresponding Dsp software structure.

[0056] When the underlying hardware or communication channel receives a subsequent CFG TLP message from the host, it triggers the message reception callback function registered by the software module. The software first parses the header information of the TLP message according to the PCIe protocol specification, and extracts the bus number, device number, and function number of the target device.

[0057] Subsequently, the software module directly compares the parsed target bus number with the global variable Dsp_bus that was calculated and saved in step S200.

[0058] If the comparison results are not equal, it is determined to be an access to the Usp port or an illegal access outside the scope of this Switch, and enters other logical branches (such as an exception return).

[0059] If the comparison results are equal, it is confirmed that the target of this access is located in the downstream port area of ​​the DSP, and the next step of the positioning logic is immediately initiated.

[0060] After the target bus number is confirmed as Dsp_bus, the software module directly extracts the previously parsed target device number (Device_ID).

[0061] According to the pre-configured ID rules in step S300, the software has already established a fixed association between Device_ID and DSP port array index during the startup phase (for example, in the Crystal architecture, Device_ID is the absolute port index, while in the Andes architecture, it carries a logical mapping of Index=Device_ID). Here, the software module directly executes the arithmetic assignment instruction n=Device_ID in the current TLP message, and uses the obtained n value as the memory index.

[0062] Subsequently, the software module directly reads the Dsp structure array [n] (i.e., dsp_ports[n]) from memory and passes the memory address of the structure directly to the configuration space processing function. The entire location process is completed entirely by simple numerical operations and memory indexing instructions, without needing to query any additional routing tables or hash tables, or execute a for loop to traverse the array.

[0063] Taking Crystal hardware architecture (1 Usp + 32 DSPs) as an example: Suppose the host sends a CFG TLP, and the target BDF is 01:05.0 (bus number 01, device number 05, function number 0).

[0064] The first step of S400 extracts the target bus number as 01. After comparison, it is found that 01 is equal to the Dsp_bus set in step S200.

[0065] The second step of S400 extracts the target device number as 05, and immediately executes n=05.

[0066] The software directly hands the processing stream to dsp_ports[5] (i.e., the DSP port with index 5 in the array) for response processing.

[0067] If the host sends a TLP with a target BDF of 01:15.1 (in the Andes architecture, the Dsp is mapped to Function_ID=1), the software still extracts device number 15 and directly locates dsp_ports

[15] without needing to perform additional logical branch judgment.

[0068] This step abandons the routing matching method that relies on lookup tables and mapping tables for item-by-item traversal, as used in existing physical PCIe switches or traditional software emulation solutions. Instead, it utilizes the linear, fixed mapping relationship between the device number and the memory array pre-defined in step S300 to transform the complex configuration space routing request into a purely mathematical address offset calculation. Since the entire target port location process involves only one numerical extraction and one memory index read at the assembly instruction level, it completely eliminates the risks of loop jumps and hash collisions. Therefore, even under microsecond-level dense enumeration access requests, the software module can maintain a constant and extremely short response cycle, fundamentally avoiding deadlocks or routing failures caused by lookup table overflows or disordered routing rules.

[0069] The S500 is configured with a Watcher mechanism to attach callbacks before and after reading and writing to the Usp / Dsp configuration space, identify fields that need to be linked to the underlying hardware CSR and write them synchronously.

[0070] This step is crucial for achieving strong consistency between the software virtual configuration space and the underlying physical hardware CSR register states. In a real system, the host's control over devices (such as address resource allocation, interrupt enabling, and bus control switching) is accomplished through reading and writing to the configuration space. The underlying hardware chip must simultaneously perceive these configuration changes to correctly route subsequent data. This step achieves bidirectional interception and verification by registering hooks on the configuration space read / write interface of existing user-space simulation frameworks (such as libvfio-user).

[0071] Furthermore, the Watcher mechanism employs a two-way interception structure with both a pre-observation point and a post-observation point.

[0072] When initializing the Usp and DSP structures in the software module, two custom watcher callback functions, pre_watcher_cb and post_watcher_cb, are pre-registered in the memory-mapped configuration space read / write operation functions (such as region_access or similar read / write callbacks). The scope of these two callback functions covers the 256-byte configuration space region of the Usp and all DSP ports.

[0073] In the front-end observation point, when the host initiates a write operation to the Usp or DSP configuration space, the operation is monitored and intercepted, the offset address of the configuration register to be written and the specific written value are identified, and if the written value corresponds to the configuration switch that needs to be linked to the underlying hardware CSR, the written value is directly written to the hardware configuration register synchronously through the hardware interface.

[0074] When the host issues a CFG TLP write operation (i.e., a configuration space write request), the hardware or emulation framework first parses the message into "target port, offset address (offset), write length (len), and write value (data)". Before actually writing the data to the configuration space buffer in software memory, the system calls the pre-watcher callback pre_watcher_cb.

[0075] Within the forward observation point, the software module performs the following operations:

[0076] It resolves whether the target port is a Usp or a specific Dsp[x].

[0077] Based on offset and len, locate the preset "hardware CSR linkage mapping table". For example, offset=0x04 (PCIe command register), the change of its Bus Master Enable bit (Bit2) belongs to the linkage field; or offset belongs to a specific extended capability register segment within the configuration space.

[0078] If the target offset to be written is located in the linkage table, the software module reads the specific value data to be written and calls the dedicated CSR write interface provided by the underlying hardware (such as hw_write_csr(port_id,offset,data)) to directly write the state synchronously into the physical CSR register corresponding to the underlying hardware.

[0079] It should be noted that this stage of operation occurs before or in parallel with the actual update of the software configuration space, and can effectively control the hardware to complete the configuration state switch before processing subsequent business messages.

[0080] In the post-observation point after the write operation is completed, the software configuration space and the corresponding underlying hardware CSR are read back in reverse. If it is found that the synchronous write of the pre-observation point has not taken effect or the hardware CSR is abnormal, the underlying hardware CSR is rewritten according to the actual state read back from the post-observation point to ensure that the software and hardware configuration states are consistent.

[0081] Once the "pre-watchpoint" completes the linked write and the software framework successfully saves the written data to the local software configuration space memory, the system calls the post-watchpoint callback post_watcher_cb.

[0082] Within the post-observation point, the software module performs the following verification and compensation actions:

[0083] Readback state: Read the value just written from the local software configuration space structure (denoted as val_sw), and read back the actual configuration value in the hardware CSR register (denoted as val_hw) through the underlying hardware interface.

[0084] Status comparison: Compare val_sw and val_hw. If they are completely identical, it means that the synchronous write of the previous observation point was successful, and this configuration operation is complete.

[0085] Compensatory rewrite: If an inconsistency is found between the two (for example, the underlying hardware is not updated in time due to channel busyness, or the process of the front observation point returns prematurely due to an anomaly), the software module will actively call the hardware CSR write interface again based on the val_sw obtained from the back observation point to initiate a compensatory rewrite operation, forcibly calibrating the state of the underlying hardware CSR to be the same as that of the software configuration space.

[0086] Taking the Bus Master function enabled on the Usp port by the host as an example: The host issues a CFG TLP write request, targeting Usp, with a write offset of 0x04, writing 2 bytes of data 0x0006 (representing setting bit 2 to 1, enabling Bus Master). The pre-watch point is triggered, intercepting offset=0x04, data=0x0006, and identifying this field as belonging to the linked target. The software immediately calls hw_write_csr(Usp,0x04,0x0006), and the underlying hardware status register is modified synchronously. After the software framework completes the update of its local configuration space, the post-watch point is triggered. The software reads: the software local value 0x0006, and the hardware register value 0x0000 (assuming there is a momentary hardware response delay, or the previous write did not take effect).

[0087] After determining the inconsistency, the software calls hw_write_csr(Usp,0x04,0x0006) again to rewrite and compensate until the next time the host accesses the hardware, ensuring that the hardware has responded correctly.

[0088] This step introduces a two-way interception mechanism of pre-synchronization and post-compensation in the standard PCIe configuration space read / write process, effectively eliminating the timeliness discrepancy between the underlying hardware state management and the upper-layer driver control instructions. Because the configuration space write operation is strongly bound to the actual hardware CSR state change, the underlying hardware can directly determine permissions based on the synchronized registers when routing data packets or reporting interrupts. This completely eliminates the risk of hardware filtering failure or system deadlock caused by inconsistencies between configuration space memory data and physical hardware register data. Simultaneously, the automatic compensation mechanism at the post-observation point significantly improves system stability under extreme abnormal hardware response scenarios.

[0089] S600 is configured with a proxy response logic. For CFG TLP pointing to an invalid BDF or an EP-unconnected DSP port, it returns an SC status code and all F data to avoid enumeration exceptions.

[0090] In this embodiment, when the host scans for devices via the PCIe bus, if it encounters an invalid BDF (e.g., the device number does not exist), or if it encounters an existing DSP port but no EP device is connected to that port, the chip or hardware cannot provide a physical response. In this case, the virtual switch software module generates a response conforming to the protocol specifications and sends it to the host; this is called a proxy response.

[0091] Returning the SC (Success Completion) status code tells the host that "this configuration space access has been completed successfully without any errors."

[0092] Returning all F data (i.e., all 0xFF): The returned data content is all 1s. In the PCIe protocol, reading a configuration space with all Fs usually means "no device here".

[0093] By returning the soft solution of SC+all F, the host driver will think, "Although no device is connected here, my access is successful." Therefore, it will safely skip this port and continue enumerating the next one, thus ensuring that the entire PCIe bus enumeration process is completed smoothly and without errors.

[0094] Furthermore, the response message returned by the proxy logic includes the following routing backfilling rules:

[0095] If the CFG TLP initiated by the host accesses the port of Dsp[x] itself with index x, then the high 4 bytes of the Data field in the returned message are filled with the BDF value and hardware function number of Dsp[x] itself; x is an integer from 0 to N-1.

[0096] If the accessed device is a secondary bus connected to Dsp[x] and no EP device is connected to Dsp[x], the high 4 bytes of the Data field in the returned message will still be filled with the BDF value and hardware function number of Dsp[x] itself, so that the host recognizes it as a response from Dsp[x].

[0097] If the accessed device is a secondary bus connected to Dsp[x], and an EP device is already connected to Dsp[x], then the CFG TLP is passed to the corresponding EP device for processing according to normal routing logic.

[0098] In this embodiment, after completing the virtual addressing of the target port, step S600 is responsible for providing a "software proxy" service for empty ports or invalid links. Simultaneously, it constructs differentiated return messages based on the identity recognition requirements of the underlying hardware FEP. Its core logic includes branch processing at two levels: target determination and high 4-byte backfilling.

[0099] 1. The decision tree for the target object in the proxy response logic is as follows:

[0100] When the software module receives a CFG TLP initiated by the host, it first parses the target BDF from the header and separates the target bus number (TLP_Bus), target device number (TLP_Dev), and target function number (TLP_Func). Based on the configuration parameters (its own bus number, device number, function number, and status records of its subordinate devices) preset for each DSP[x] in S200 and S300, the software internally maintains a decision tree to determine whether to enable proxy answering and which entity the routing information in the returned data should belong to.

[0101] Accessing Dsp[x]'s own port: If TLP_Bus equals Dsp[x]'s own bus number, TLP_Dev equals Dsp[x]'s own device number, and TLP_Func equals Dsp[x]'s own function number, then it is determined as an access to Dsp[x]'s own port. In this case, the software responds normally to the local configuration space data of Dsp[x].

[0102] Accessing the next-level bus, and no EP is attached: If TLP_Bus is greater than the bus number of Dsp[x] itself (i.e., the secondary bus below the Dsp bridge device), but the software module internally queries the attached_flag of the current Dsp[x] and it shows "false" (no EP device is attached), then it is determined that the request points to an empty next-level slot. At this time, it enters the "responding" state.

[0103] Accessing the next-level bus, where an EP is already connected: If TLP_Bus is greater than the bus number of Dsp[x], and the attached_flag of Dsp[x] is true, and TLP_Dev and TLP_Func in TLP match the ID of the connected EP, then the target is determined to be an actual existing EP device. In this case, the proxy logic is not entered; the software directly routes the TLP message to the software processing flow corresponding to the EP device.

[0104] 2. The routing backfilling logic for the high 4 bytes of the returned message data field is as follows:

[0105] After completing the target determination and generating response data (including both the full F data for a proxy response and the configuration space data for a normal response), the software module also needs to specially fill in the high 4 bytes of the Data field during the message construction phase returned to the underlying hardware FEP. The underlying hardware FEP relies on the information in these 4 bytes to identify the sender of the message, so that it can correctly associate the corresponding physical object during subsequent interrupt reporting and DMA data transfer.

[0106] The specific backfilling logic is as follows:

[0107] Scenario 1 (Self-access): If the target is Dsp[x] itself, the BDF value of Dsp[x] obtained from the lookup table and the hardware function number of Dsp[x] are directly combined and written into the high 4 bytes of the Data field of the returned message. For example, if the BDF of Dsp[5] is 01:05.0 and the hardware function number is 0x66, then the high 4 bytes are written with a specific value containing this information.

[0108] Scenario 2 (Response on Behalf, Access from a DSP Not Connected to an EP): In this case, the returned Data field contains all F's, but to meet the FEP hardware's requirement for identifying the data source, the high 4 bytes are still filled with the BDF value and hardware function number of the DSP[x] currently participating in the response. This is equivalent to telling the hardware: "Although this response is empty, it was sent on behalf of the DSP[x] port." After receiving the all-F data, the host driver will determine that there is no device below it, thus safely skipping the port and continuing the enumeration.

[0109] Scenario 3 (Normal routing, access from a downstream device already connected to an EP): If a connected EP is hit, the high 4 bytes of the Data field of the returned message are filled with the BDF value and hardware function number of the EP device to ensure that subsequent hardware interruptions and service flows can be correctly routed to the processing unit of the EP.

[0110] This step effectively bypasses the enumeration interrupt or kernel crash issues that may occur when some server PCIe drivers handle abnormal UR responses by distinguishing between accessing the DSP's own port and accessing the connected secondary bus, and establishing a clear "SC status code + all F data" response strategy for accesses pointing to null EP ports. Simultaneously, for the underlying mechanism of device identification using the high 4 bytes of the FEP hardware-dependent message, a specific rule was designed to backfill the DSP's own BDF and hardware function number in the response scenario. This ensures that the upper-layer host driver can obtain a standardized basis for null device determination, and allows the underlying hardware to continuously maintain accurate interrupt and DMA association channels without adding extra mapping tables, reducing the synchronization overhead of the software and hardware interface layer in the absence of a link.

[0111] Furthermore, the method also includes:

[0112] When the service layer needs to connect an EP device to a DSP port, the software module modifies the slot status register in the DSP port configuration space, setting the presence status change bit, card insertion status bit, and physical link layer status change bit in the register to 1 simultaneously.

[0113] When a business layer (such as a management plane application) decides to attach a new EP device (such as a VIRTIO network device) to an idle DSP[x] port, it will invoke this hot-plug software interface.

[0114] The software module first addresses the slot status register (offset address is usually 0x1A or located according to the Capability chain position) within the configuration space structure corresponding to Dsp[x] constructed in step S300. The software then directly modifies specific fields of this register through bit operations.

[0115] Setting the Presence Detect Changed (Bit 0) to 1 indicates that the state of the slot has fluctuated.

[0116] Setting the Presence Detect State (Bit 1) to 1 indicates to the driver that the current slot is occupied by a device.

[0117] Set the Data Link Layer State Changed (Bit4) bit to 1 to indicate that the data link layer state has also changed.

[0118] The order of these three steps must be strictly maintained; the software only needs to write this specific binary mask once.

[0119] Modify the link status register of the DSP port to configure the current link rate and negotiated link bandwidth to preset fixed values, and set the link layer activation status to 1.

[0120] Since this is a purely virtualized Switch module, there is no real physical link layer negotiation process (such as physical link training, rate degradation, etc.), so the software module adopts the method of directly preset parameters.

[0121] The software modifies the link status register (offset address is usually 0x12) under the same Capability structure, and then:

[0122] The current link speed (Bits 0-3) is forced to be written to a fixed value (e.g., 0x3 corresponds to 16.0GT / s).

[0123] Negotiated link bandwidth (Bits 4-9) is forced to be written to a fixed value (e.g., 0xF corresponds to x16).

[0124] The Data Link Layer Link Active (Bit13) bit is set to 1.

[0125] After this step is completed, the virtual PCIe link simulated by the software is in a state of "fully trained and normally activated" at the host software level.

[0126] After the registers are configured, an MSI-X interrupt request for the DSP port is initiated to the host through the DMA channel of the underlying hardware. This triggers the host PCIe hot-plug driver to respond to the interrupt, enabling the host to perform device enumeration and corresponding EP device driver loading for the DSP port.

[0127] After the register state was modified, the host was not notified. To implement interrupt reporting, the software module called the interrupt triggering interface provided by the underlying hardware driver.

[0128] After receiving the interface call, the underlying hardware chip will initiate a "memory write operation" to the MSI-X interrupt vector address registered in the host memory through the on-chip DMA pass-through channel, based on the vector address and data in the MSI-X table entry pre-configured in the Dsp[x].

[0129] After the host receives the MSI-X interrupt, the Linux kernel's low-level interrupt handler recognizes that this is a hot-plug interrupt belonging to the PCIe Root Port, and then wakes up the pciehp (PCIe Hotplug) kernel driver thread.

[0130] After the PCIe HP driver responds to an interrupt, it immediately reads back the slot status register of the DSP port. When it reads "Presence Detect Changed=1" and "Presence Detect State=1", it determines that a new device insertion event has occurred, and then triggers PCIe bus scanning, enumeration, configuration space resource allocation, and finally successfully loads the PCIe kernel driver for the corresponding EP device.

[0131] Through this step, the system actively modifies and forcibly presets key flags in the slot status register and link status register defined by the PCIe standard directly at the pure software control level, completely eliminating the dependence on real physical link training and hardware trigger latency. Since the insertion of the DSP port is entirely based on software manipulation of the configuration space data structure and the underlying DMA interrupt channel, the host can promptly and accurately capture hot-plug events during any service operation period, driving the PCIehp process to automatically complete subsequent hardware enumeration and driver binding. This method, independent of changes in physical signals and hardware link handshakes, significantly reduces the system's dependence on physical hardware and complex debugging costs, ensuring the flexible scalability of the dynamic resource pool in virtualization scenarios.

[0132] Furthermore, the method also includes:

[0133] When the business layer needs to remove an EP device connected to a DSP port, the software module sets the status of the attention button in the corresponding DSP port slot status register to 1.

[0134] When the business management interface needs to remove an EP device connected to a DSP[x] (e.g., migrate or destroy a virtual function), it first calls the hot-plug interface corresponding to that DSP port. After receiving the removal command, the software module addresses the corresponding slot status register in the configuration space within the DSP[x] structure and directly sets the Attention Button Pressed (usually Bit 5 in the standard definition) to 1. This operation sends a pre-notification to the host signal at the PCIe standard level that "the slot is intended to be physically removed," avoiding non-standard operations caused by direct disconnection.

[0135] The software module calls the underlying hardware interface to initiate an MSI-X interrupt for the DSP port to the host through the DMA channel. At the same time, the software module immediately blocks all business logic processes related to the DSP port and enters a waiting state.

[0136] After successfully modifying the status bit, the software module calls the underlying hardware interrupt triggering interface and uses the hardware DMA channel to send an MSI-X interrupt request to the host for the vector corresponding to Dsp[x].

[0137] Meanwhile, within microseconds of the interrupt trigger, the software module performs strict resource locking and state blocking operations: it sets a dsp_state[x] flag to "unplugging"; it internally intercepts all access requests from upper-layer services to the EP and its associated memory resources and returns a busy state, blocking any new business data flow from entering the path; the software module starts its own timeout timer (usually set to 30-35 seconds in engineering to adapt to the response latency of various servers) and enters an asynchronous waiting state. This timeout mechanism is a safety fallback measure to prevent the software from deadlocking itself when the underlying driver is unresponsive for a long time.

[0138] The host PCIe hot-plug driver responds to the interrupt and recognizes that the attention button is set. After the set timer wait period ends and it is confirmed that there is no cancellation of the unplugging action, the driver corresponding to the EP device is uninstalled, the device tree structure is removed, and the power indicator control position in the slot control register is set to off.

[0139] After receiving the aforementioned MSI-X interrupt, the host triggers the interrupt handling routine of the pciehp driver in the Linux kernel. When the pciehp driver reads the slot status register of the DSP port, it finds that the attention button is set.

[0140] According to the standard PCIe hot-plug specification, the pciehp driver does not immediately perform the unloading, but instead starts a 5-second timer waiting window. During this period, if the software module does not reset the attention button to 0 to "cancel unplugging," the timer times out. After the timeout, the pciehp driver strictly follows the steps: calling the corresponding PCI driver.remove() interface to unload the device driver for the EP device; completely removing the EP device node from the Linux kernel's PCI device tree; and finally, setting the Power IndicatorControl (Bits 0-1) in the Slot Control Register to off (corresponding to binary 00), indicating that the slot is now powered off and allows for final physical removal.

[0141] The software module intercepts and listens for configuration space write operations when the power indicator control bit is set to off through the Watcher mechanism, triggering the release of the waiting state and resuming the blocked business logic.

[0142] Before the software initiates the unplugging process, the configuration space Watcher callback hook configured in step S500 plays a crucial "gatekeeping" role at this time. When the host executes the last step (writing the power indicator control bit to off), because the Watcher mechanism is attached to the write channel of this configuration space, the software module can monitor and intercept the write command at that offset address in real time.

[0143] Once the software module detects that the target port corresponding to the write command is the Dsp[x] currently in the "unplugged" state, and the write value is indeed in the off state, the software module confirms that the system's safe removal process has been completed. At this time, the software module performs the following actions: cancels the 35-second timeout timer set in step two; resets the internal status flag of Dsp[x] to the idle state; releases the service flow blocking for this Dsp port and resumes the service flow (at this time, the service layer can be notified not to access the EP device before the next reinsertion).

[0144] This step, without physical layer switch status awareness, triggers and simulates a complete PCIe hot-plug state machine through the attention button status bit in the software configuration space, and utilizes the hardware DMA interrupt channel to establish a complete notification and feedback loop with the host hot-plug driver. Because synchronous blocking of the service flow is set simultaneously with interrupt reporting, it effectively prevents memory dangling access or system crashes caused by the service layer continuing to initiate data access to the EP during host driver unloading. Furthermore, by intercepting the "power indicator control bit off" status actively written by the host after hot-plugging is completed through the Watcher mechanism as a signal feedback, an asynchronous handshake protocol is successfully established between the software and the host driver without a direct control channel, ensuring the timing consistency, security, and engineering robustness of the downstream EP device removal process in the virtualization system.

[0145] Furthermore, the underlying hardware interface is invoked to initiate an MSI-X interrupt for the DSP port to the host via the DMA channel. The underlying hardware receives the hardware interrupt trigger request from the software module, encapsulates the current DSP port slot status register change information and attention button status into a standard PCIe TLP message format, and pushes it to the host's PCIe controller via the on-chip DMA channel, driving the host kernel to request an interrupt and execute the corresponding hot-plug processing thread.

[0146] This step precisely encapsulates the hot-plug state changes at the software level into a standard PCIe memory write (MWr) transaction through underlying hardware, and delivers it to a specific interrupt vector address in host memory using DMA pass-through capability. This completely bypasses complex software-simulated interrupt line operations and directly triggers the host kernel to respond to the event using a real hardware interrupt. The specific implementation is as follows:

[0147] After the software module completes the setting operation of the Attention Button Pressed bit in the Slot Status Register of a specific DSP[x], the software calls the hardware interrupt triggering interface function exposed by the underlying hardware (e.g., hw_trigger_msix(dsp_index)). The input parameter of this function explicitly specifies the target port index. After receiving the function call instruction, the underlying hardware immediately locks the hardware resource state corresponding to the current DSP[x] from inside the chip to prevent it from being tampered with or overwritten by the software before the DMA transfer is completed. At the same time, it prepares to read the pre-configured interrupt vector address and interrupt data of the DSP[x] from the MSI-X Configuration Table inside the hardware.

[0148] After obtaining the interrupt vector target address and data, the internal TLP assembly engine (usually a protocol encoding / decoding module in a hardware logic gate array) does not directly send the raw data, but encapsulates it strictly according to the PCIe bus protocol specification. Specifically, the engine fills the interrupt vector address into the address field of the TLP header, fills the interrupt data (usually a specific 32-bit or 64-bit value) into the payload field of the TLP, and marks flags such as Fmt=0b000 (no data) or 0b010 (data present) and Type=0b00000 (Memory Write) in the TLP header, thus constructing a standard PCIe memory write TLP message. Simultaneously, the initiator's Requester ID (i.e., the BDF value of the DSP[x]) is filled into the TLP header to allow the host to accurately identify the source port of the interrupt.

[0149] After encapsulation, the internal DMA data transfer engine places the TLP message into the send queue as a data transfer task. Since this DMA engine is directly connected to the host-side physical layer link (PCIe Root Complex), the TLP message will be directly pushed to the host's PCIe controller via the PCIe physical layer channel of the chip's upstream port. In engineering implementation, this push process is transparent to the software, requiring no additional polling or intervention from the software.

[0150] When the host PCIe root port receives the memory write TLP, it resolves the physical target address of the memory write transaction at the hardware level. At this point, the address happens to match the interrupt vector entry address allocated by the host Linux kernel for MSI-X interrupts during initialization. After successful hardware verification, the host PCIe controller directly initiates the corresponding hardware interrupt request (IRQ) to the local interrupt controller. Subsequently, the host's Linux kernel interrupt subsystem receives the interrupt signal, finds the handler function corresponding to the interrupt number, and wakes up the PCIe hot-plug driver thread (pciehp) attached to the interrupt. Thus, from the software-side state change to the host kernel process's response, a complete hardware interrupt triggering loop is completed.

[0151] This step achieves complete physical decoupling between "software state changes" and "real hardware interrupt reporting" by directly encapsulating the simulated hardware hot-plug state into a standard PCIe memory write TLP message and physically pushing it to the interrupt vector location in host memory using the DMA channel. Since the interrupt response relies on the real hardware's PCIe controller pass-through mechanism, rather than using software-simulated low-level pulling or virtual interrupt lines, the host can respond to virtualized port plugging / unplugging events with standard hardware interrupt latency, avoiding the risk of guest OS interrupt loss or driver hang-up due to software handshake delays. Simultaneously, the explicit Requester ID (BDF) carried in the TLP header allows the host hot-plug driver to immediately know which DSP port the interrupt belongs to when it is triggered, avoiding the extra time spent by the host on reverse scanning to locate the interrupt source, further improving the overall processing efficiency of the host kernel and the accuracy of device state synchronization in hot-plugging mode.

[0152] After processing the CFG TLP, the S700 concatenates the BDF value determined by the target port and the hardware function number into the high 4 bytes of the Data field of the returned FEP message.

[0153] When a CFG TLP (Configuration Space Read / Write Request) initiated by the host has been executed within the software module (through routing, Watcher interception, proxy answering, or normal processing) and is ready to respond to the host, the software extracts the BDF (Bus Number: Device Number.Function Number) of the target port that was actually processed by the request, as well as the internal hardware function number corresponding to that port. These two sets of data are combined into a single word (usually 32 bits) and directly filled into the "high 4 bytes" (i.e., the first 4 bytes) of the Data field (data payload) of the message returned to the underlying FEP. The message, carrying these 4 bytes of additional information, is then sent to the underlying hardware FEP.

[0154] This step precisely maps the routing information controlled by the virtual software to the underlying hardware, enabling the hardware to autonomously forward data streams compliant with the PCIe standard without going through the software when processing high-throughput data services.

[0155] 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.

[0156] Embodiments of the present invention also provide a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the method provided in the above embodiments.

[0157] The program product may employ any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0158] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable signal medium may also be any readable medium other than a readable storage medium, capable of sending, propagating, or transmitting programs for use by or in conjunction with an instruction execution system, apparatus, or device.

[0159] The program code contained on the readable medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof.

[0160] Program code for performing the operations of this application can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can execute entirely on the user's computing device, partially on the user's device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0161] Embodiments of the present invention also provide a PCIe Switch virtualization device, including an underlying hardware FEP and a software module and processor running on the hardware. The underlying hardware FEP has a built-in hardware CSR register and a physical channel interface that supports PCIeTLP packet transmission and DMA data pass-through interaction. The software module is configured to execute the enumeration and routing method of PCIe Switch soft emulation as described in the above embodiments.

[0162] The electronic device is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments in this application.

[0163] Electronic devices are manifested in the form of general-purpose computing devices. Components of an electronic device may include, but are not limited to: at least one processor, at least one memory, and a bus connecting different system components (including memory and processor).

[0164] The memory stores program code that can be executed by the processor, causing the processor to perform the steps in the various embodiments described in this specification.

[0165] The memory may include readable media in the form of volatile memory, such as random access memory (RAM) and / or cache memory, and may further include read-only memory (ROM).

[0166] The memory may also include programs / utilities having a set (at least one) of program modules, including but not limited to: an operating system, one or more application programs, other program modules, and program data, each or some combination of these examples may include an implementation of a network environment.

[0167] A bus can represent one or more of several types of bus structures, including a memory bus or memory controller, a peripheral bus, a graphics acceleration port, a processor, or a local bus that uses any of the various bus structures.

[0168] Electronic devices can also communicate with one or more external devices (e.g., keyboards, pointing devices, Bluetooth devices, etc.), one or more devices that enable user interaction with the electronic device, and / or any device that enables the electronic device to communicate with one or more other computing devices (e.g., routers, modems, etc.). This communication can be achieved through input / output (I / O) interfaces. Furthermore, electronic devices can communicate with one or more networks (e.g., local area networks (LANs), wide area networks (WANs), and / or public networks, such as the Internet) via network adapters. The network adapter communicates with other modules of the electronic device via a bus. It should be understood that other hardware and / or software modules can be used in conjunction with the electronic device, including but not limited to: microcode, device drivers, redundant processors, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0169] From the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this disclosure can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, terminal device, or network device, etc.) to execute the methods according to the embodiments of this disclosure.

[0170] Embodiments of the present invention also provide a computer program product including program code, which, when the program product is run on an electronic device, causes the electronic device to perform the steps of the methods described above in various exemplary embodiments of the present invention.

[0171] While specific embodiments of the invention have been described in detail by way of examples, those skilled in the art should understand that the examples are for illustrative purposes only and are not intended to limit the scope of the invention. Those skilled in the art should also understand that various modifications can be made to the embodiments without departing from the scope and spirit of the invention.

Claims

1. A PCIe Switch software emulation enumeration and routing method, characterized in that, include: Construct a virtual PCIe Switch software module; the software module includes a topology of one uplink port Usp and N downlink ports DSP; Initialize the Usp and wait for the first CFG TLP to be accessed. When the Usp receives the first CFG TLP, extract the Usp bus ID allocated by the host and record it as Usp_bus. Then set the bus ID of all DSP ports in the next level to Dsp_bus, satisfying Dsp_bus=Usp_bus+1. Pre-configure the device number Device_ID and function number Function_ID for each Usp and each DSP, and construct an array of DSP software structures that correspond one-to-one with each DSP in the software module; Parse the target BDF in the subsequent CFG TLP. If the target bus ID is equal to Dsp_bus, extract the Device_ID field in the corresponding CFG TLP as index n, and locate the nth downlink port Dsp[n] in the Dsp software structure array. Configure the Watcher mechanism to attach callbacks before and after reading and writing to the Usp / Dsp configuration space, identify fields that need to be linked to the underlying hardware CSR and write them synchronously; Configure the response logic to return an SC status code and all F data for CFG TLP pointing to an invalid BDF or a DSP port that is not connected to an EP in order to avoid enumeration exceptions. After processing the CFG TLP, the BDF value determined by the target port and the hardware function number are concatenated into the high 4 bytes of the Data field of the returned FEP message.

2. The enumeration and routing method for PCIe Switch software emulation according to claim 1, characterized in that, In the device number Device_ID and function number Function_ID pre-configured for Usp and each DSP, the Function_ID of each port is fixedly configured to 0; If based on the Andes hardware architecture, the Device_ID of the Usp is fixed at 00, and the device numbers of the 64 DSPs are assigned from 00 to 31 according to the preset mapping. That is, each device number in the 64 DSPs corresponds to two DSPs. If based on the Crystal hardware architecture, the Device_ID of the Usp is fixed at 00, and the device numbers of the 32 DSPs are assigned sequentially from 00 to 31 according to the port index.

3. The enumeration and routing method for PCIe Switch software emulation according to claim 1, characterized in that, When locating the nth downlink port Dsp[n] in the Dsp software structure array, the formula n = Device_ID in the current CFG TLP message is used for mapping. The pre-established fixed mapping relationship between the device number and the Dsp structure index is used to directly locate the corresponding Dsp software structure.

4. The enumeration and routing method for PCIe Switch software emulation according to claim 1, characterized in that, The Watcher mechanism adopts a two-way interception structure with pre-observation points and post-observation points; In the front-end observation point, when the host initiates a write operation to the Usp or DSP configuration space, the operation is monitored and intercepted, the offset address of the configuration register to be written and the specific written value are identified. If the written value corresponds to the configuration switch that needs to be linked to the underlying hardware CSR, the written value is directly written to the hardware configuration register synchronously through the hardware interface. In the post-observation point after the write operation is completed, the software configuration space and the corresponding underlying hardware CSR are read back in reverse. If it is found that the synchronous write of the pre-observation point has not taken effect or the hardware CSR is abnormal, the underlying hardware CSR is rewritten according to the actual state read back from the post-observation point to ensure that the software and hardware configuration states are consistent.

5. The enumeration and routing method for PCIe Switch software emulation according to claim 1, characterized in that, The response message returned by the proxy logic contains the following routing backfill rules: If the CFG TLP initiated by the host accesses the port of Dsp[x] itself with index x, then the high 4 bytes of the Data field in the returned message are filled with the BDF value and hardware function number of Dsp[x] itself; x is an integer from 0 to N-1; If the accessed device is a secondary bus connected to Dsp[x] and no EP device is connected to Dsp[x], the high 4 bytes of the Data field in the returned message will still be filled with the BDF value and hardware function number of Dsp[x] itself, so that the host can recognize it as a response from Dsp[x] itself. If the accessed device is a secondary bus connected to Dsp[x], and an EP device is already connected to Dsp[x], then the CFG TLP is passed to the corresponding EP device for processing according to normal routing logic.

6. The enumeration and routing method for PCIe Switch software emulation according to claim 1, characterized in that, Also includes: When the service layer needs to connect an EP device to a DSP port, the software module modifies the slot status register in the DSP port configuration space, setting the presence status change bit, card insertion status bit, and physical link layer status change bit in the register to 1 at the same time. Modify the link status register of the DSP port, configure the current link rate and negotiated link bandwidth to preset fixed values, and set the link layer activation status to 1; After the registers are configured, an MSI-X interrupt request for the DSP port is initiated to the host through the DMA channel of the underlying hardware. This triggers the host PCIe hot-plug driver to respond to the interrupt, enabling the host to perform device enumeration and corresponding EP device driver loading for the DSP port.

7. The enumeration and routing method for PCIe Switch software emulation according to claim 1, characterized in that, Also includes: When the business layer needs to remove an EP device connected to a DSP port, the software module sets the status of the attention button in the corresponding DSP port slot status register to 1. The software module calls the underlying hardware interface to initiate an MSI-X interrupt for the DSP port to the host through the DMA channel. At the same time, the software module immediately blocks all business logic processes related to the DSP port and enters a waiting state. The host PCIe hot-plug driver responds to the interrupt and recognizes that the attention button is set. After the set timer wait period ends and it is confirmed that there is no cancellation of the unplugging action, the driver corresponding to the EP device is uninstalled, the device tree structure is removed, and the power indicator control position in the slot control register is set to off. The software module intercepts and listens for configuration space write operations when the power indicator control bit is set to off through the Watcher mechanism, triggering the release of the waiting state and resuming the blocked business logic.

8. The enumeration and routing method for PCIe Switch software emulation according to claim 7, characterized in that, The underlying hardware interface is invoked to initiate an MSI-X interrupt for the DSP port to the host via the DMA channel. The underlying hardware receives the hardware interrupt trigger request from the software module, encapsulates the current DSP port slot status register change information and attention button status into a standard PCIe TLP message format, and pushes it to the host's PCIe controller via the on-chip DMA channel, driving the host kernel to request an interrupt and execute the corresponding hot-plug processing thread.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the enumeration and routing method for PCIe Switch soft emulation as described in any one of claims 1 to 8.

10. A PCIe Switch virtualization device, comprising a lower-level hardware FEP and software modules and a processor running on the hardware, wherein the lower-level hardware FEP has a built-in hardware CSR register and a physical channel interface supporting PCIe TLP packet transmission and DMA data pass-through interaction, characterized in that, The software module is configured to perform the enumeration and routing method for PCIe Switch soft emulation as described in any one of claims 1 to 8.

Images