A method and system for bdf-to-uuid mapping for firmware emulation

Abstract

The present application relates to the technical field of firmware simulation, and in particular to a BDF-to-UUID mapping method and system for firmware simulation. The method comprises: assigning a unique UUID to each virtual device and associating it to a corresponding port of a PCIe tree structure; receiving a config-type TLP request carrying a BDF, querying the BDF's corresponding UUID through a hardware mapping table, establishing a mapping according to a PCIe topology search algorithm and writing it into the hardware table when a first miss occurs, and directly outputting the UUID when a subsequent hit occurs. The hardware O(1) table lookup replaces the firmware tree search, eliminates the firmware's environmental dependence on the host's dynamic allocation of BDFs, significantly reduces the TLP processing delay, and supports the simulation of thousands of virtual devices.

Description

Technical Field

[0001] This invention relates to the field of firmware emulation technology, and in particular to a BDF-to-UUID mapping method and system for firmware emulation. Background Technology

[0002] In the PCIe (Peripheral Component Interconnect Express) architecture, the host discovers and manages all its subordinate PCIe devices through an enumeration process. Each PCIe device is assigned a triplet number consisting of a bus number, a device number, and a function number, known as the BDF (Bus / Device / Function). When the host initiates configuration or memory access to a PCIe device, the TLP (Transaction Layer Packet) carries the target device's BDF for addressing.

[0003] In existing physical PCIe device scenarios, the BDF is statically assigned by the host BIOS (Basic Input Output System) or the operating system during enumeration, and the device itself passively accepts the number.

[0004] With the development of cloud computing technology, large cloud service providers need to create a large number of virtual machines on a single physical server. Each virtual machine needs its own virtual network interface card (NIC) and virtual block storage (PCIe) devices. To strike a balance between cost and flexibility, the industry adopts a method of embedding an ARM (Advanced RISC Machine) core within the NIC or DPU (Data Processing Unit) chip to run firmware. This firmware, in conjunction with hardware acceleration units, simulates a large number of PCIe devices. In this firmware-simulated device scenario, the firmware needs to simulate a large number of virtual PCIe devices within the chip. These virtual devices also need to respond to the host's BDF enumeration and addressing.

[0005] However, in firmware emulation device scenarios, the use of BDF has the following problems: First, BDFs are dynamically assigned by the host. The BDF of the same device may change on different servers, under different kernel versions, or even after each server reboot. If the firmware directly uses BDFs to identify and manage devices, the mapping relationship needs to be re-established every time the environment changes.

[0006] Second, the firmware requires a unified identification system independent of the host for device management. BDF, as an external identifier on the host side, is not suitable for data structure indexing and function addressing within the firmware.

[0007] Third, when the number of simulated devices reaches the K level (e.g., 1000 to 16000), each TLP access requires a complex tree topology search within the firmware using BDF to locate the target device, resulting in huge computational overhead and easily triggering PCIe transaction timeouts.

[0008] Therefore, in the scenario of firmware emulation devices, how to establish a unified device identifier that is independent of the host dynamically allocated BDF, and how to achieve efficient and low-latency conversion from BDF to this identifier, is a technical problem that urgently needs 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 method for mapping BDF to UUID for firmware emulation is provided, comprising the following steps: Step S1: In response to the user's operation of creating a virtual device, assign a unique UUID to each virtual device and logically associate the UUID with the corresponding DSP port identifier in the pre-built PCIe tree structure; Step S2: When the host initiates enumeration, it sends a TLP request of type config carrying BDF; Step S3: Use the hardware mapping table to check if the BDF in the TLP request already has a corresponding UUID; If the hardware mapping table has been matched, the corresponding UUID will be output directly, and the process will jump to step S5. If the request is not hit, the original information of the TLP request is forwarded to the firmware; Step S4: The firmware receives the TLP request, parses the corresponding device identifier from the BDF according to the topology search algorithm specified by the PCIe protocol, determines the corresponding UUID, and writes the mapping relationship between the BDF and the UUID into the hardware mapping table. Step S5: When a subsequent TLP request pointing to the same BDF arrives, the corresponding UUID is obtained directly by querying the hardware mapping table, and the firmware processes the target device based on the UUID.

[0010] According to a second aspect of the present invention, a BDF-to-UUID mapping system for firmware emulation is provided, comprising: The identification association module is used to respond to the user's operation of creating virtual devices, assign a unique UUID to each virtual device, and logically associate the UUID with the corresponding DSP port identifier in the pre-built PCIe tree structure; The request receiving module is used to receive TLP requests of type config carrying BDF sent by the host when it initiates enumeration; The hardware query module is used to query whether the BDF in the TLP request already has a corresponding UUID using the hardware mapping table; If the hardware mapping table has been matched, the corresponding UUID will be output directly, and the process will jump to the subsequent processing module. If the request is not hit, the original information of the TLP request is forwarded to the firmware; The mapping establishment module is used by the firmware to receive TLP requests, parse the corresponding device identifier from BDF according to the topology search algorithm specified by the PCIe protocol, determine the corresponding UUID, and write the mapping relationship between BDF and UUID into the hardware mapping table. The subsequent processing module is used to directly query the corresponding UUID through the hardware mapping table when a subsequent TLP request pointing to the same BDF arrives, and the firmware processes the target device based on the UUID.

[0011] This invention has at least one of the following beneficial effects: This invention assigns a unique UUID to each virtual device in step S1 and logically associates the UUID with the DSP port identifier in the PCIe tree structure. Steps S2 to S4 parse the BDF (Browser Definition Table) and establish a mapping relationship between the BDF and UUID when the first config-type TLP (Transaction Pointer) arrives, writing this mapping relationship into the hardware mapping table. Step S5 utilizes the hardware mapping table to directly query and convert the BDF to UUID for subsequent TLPs. This constitutes a complete technical solution from device identifier allocation to identifier conversion, resulting in the following beneficial effects: First, it eliminates the firmware's environmental dependency on the host BDF. Since a unique UUID is assigned to each virtual device in step S1, and this UUID is specified by the user when creating the device on the cloud management platform, it is a fixed number within the firmware and is independent of the host-assigned BDF. Therefore, when the same device runs on different servers, the kernel version of the same server changes, or the same server restarts, although the host-assigned BDF may change, the UUID used internally by the firmware remains constant. The firmware does not need to rebuild the device identifier mapping relationship after each environmental change, the UUID remains unchanged when the device migrates between different servers, and the management plane does not need to update the device identifier.

[0012] Second, it significantly reduces TLP processing latency. Since step S3 queries the UUID corresponding to the BDF through the hardware mapping table, and the firmware completes the tree search to establish the mapping and writes it into the hardware table during the first TLP access in step S4, all subsequent TLP requests pointing to the same BDF in step S5 are directly converted from BDF to UUID by the hardware mapping table. The hardware mapping table supports single-cycle table lookup output with a time complexity of O(1), while the firmware needs to perform a PCIe tree search to locate the device for each TLP access under the pure software solution, with a time complexity of O(logN) or O(N). When the device scale reaches K levels, the hardware O(1) table lookup reduces the processing latency by more than tens of times compared to the firmware tree search.

[0013] Third, it supports large-scale device simulation scenarios. Since the O(1) time complexity of hardware mapping table lookup is not affected by the increase in the number of devices, the conversion time from BDF to UUID for each TLP remains constant when the number of devices expands from hundreds to thousands or even tens of thousands. This makes it possible for a single chip to support the simulation of K to tens of K virtual devices, breaking through the limitation of firmware computing power bottleneck on device scale in pure software solutions. 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 A flowchart illustrating a BDF-to-UUID mapping method for firmware emulation provided in an embodiment of the present invention.

[0016] Figure 2 A flowchart of a BDF-to-UUID mapping system for firmware emulation provided in an embodiment of the present invention.

[0017] Figure 3 This is a schematic diagram of the PCIe tree topology 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] As a first possible embodiment of the present invention, such as Figure 1 As shown, a BDF to UUID mapping method for firmware emulation is provided.

[0020] In this embodiment, the method is applied to a firmware-simulated PCIe device system in a cloud computing scenario.

[0021] In cloud computing scenarios, cloud service providers need to create a large number of virtual machines on a single physical server. Each virtual machine requires an independent virtual network interface card (NIC) and virtual block storage (PCIe) devices. To meet this requirement, the physical server deploys NICs or DPU chips with ARM cores. The firmware in the chip is responsible for emulating these virtual PCIe devices. Users issue operation commands to create virtual devices through the cloud management platform, and these commands are transmitted over the network to the firmware system on the physical server. The user here can be either the administrator of the cloud management platform or an automated scheduling system.

[0022] In this embodiment, the method includes the following steps: Step S1: In response to the user's operation of creating a virtual device, assign a unique UUID to each virtual device and logically associate the UUID with the corresponding DSP port (Downstream Port) identifier in the pre-built PCIe tree structure.

[0023] When the firmware system receives a user's instruction to create a virtual device from the cloud management platform, it first determines the DSP port that the virtual device is connected to in the PCIe tree topology. For example... Figure 3 As shown, the PCIe tree topology is pre-built during system initialization, with each DSP port being a known fixed node. The USP (Upstream Port) is the root node of the PCIe topology, the "root" of the entire device tree. The EP (Endpoint) is the lowest-level virtual device; each EP is assigned a unique UUID, corresponding to a DSP, providing the basic association for subsequent BDF-to-UUID mapping.

[0024] UUID generation can employ a general UUID generation algorithm, such as UUID version 4 based on timestamps and random numbers. Alternatively, it can determine unique values ​​based on the number of Power Factors (PFs) / V Factors (VFs) on the chip, for example, incrementing VFs from 0 and PFs from 1024, thus generating a UUID. UUIDs generated in this way are unique globally within the system. Internally, the UUID is mapped to a fixed number, such as 0, 1, 2, etc., based on the creation order. This number is completely independent of the BDFs dynamically allocated during subsequent host enumeration.

[0025] The firmware uses UUIDs for unified management of virtual devices. This unified management encompasses the organization of device objects, allocation of memory space, and maintenance of device status. This UUID-based unified management ensures that regardless of the BDF value assigned to the virtual device by the host in subsequent enumerations, the firmware internally uses the initially assigned UUID for indexing and management. When a virtual device is migrated from one physical server to another, the UUID remains unchanged before and after the migration. The upper-level management data structures of the firmware can continue to function normally without any modifications, avoiding the overhead of rebuilding mappings caused by BDF changes.

[0026] Step S2: When the host initiates enumeration, it sends a TLP request of type BDF carrying a config file.

[0027] When the host boots up or rescans the PCIe bus, it initiates an enumeration process. The host BIOS or operating system enumerates each PCIe device level by level, starting from the root complex, using the PCIe protocol's depth-first search algorithm. During the enumeration process, the host assigns a unique BDF to each discovered device and reads its configuration space information via a config-type TLP request.

[0028] Step S3: Use the hardware mapping table to check whether the BDF in the TLP request already has a corresponding UUID.

[0029] The hardware mapping table is a BDF-to-UUID mapping table. This table is maintained by the hardware unit and resides in the hardware acceleration unit between the PCIe interface and the ARM core. The mapping table uses BDF as the input key and UUID as the output value. The hardware mapping table supports single-cycle lookup to output the corresponding UUID.

[0030] The single-cycle lookup capability stems from the implementation of the hardware-mapped table. This table is implemented using CAM (Content Addressable Memory) or a directly mapped register array. When the BDF (Browser Array Definition) is used as the lookup input, the hardware simultaneously matches it against the BDF fields of all valid entries in the table using a parallel comparator. The matching logic is performed in combinational circuitry, and the entire lookup process is completed within one clock cycle. This design results in lookup latency on the order of nanoseconds.

[0031] Table 1 shows an example structure of the BDF-to-UUID mapping table: Table 1

[0032] If the hardware mapping table has been matched, it means that the BDF has been identified and mapped in the previous enumeration. The hardware directly outputs the corresponding UUID and jumps to step S5.

[0033] If a match is missed, it indicates that this is the first time the BDF has been accessed. For example, when the host first enumerates the device, the mapping relationship has not yet been established. The hardware forwards the raw information of the TLP request to the firmware for further processing. When the system first boots or a new device is created, the BDF-to-UUID mapping table is empty. If this miss handling path is missing, the entire device identification process will fail to start. Therefore, the branch logic of forwarding the miss to the firmware in step S3 is the initial channel through which the entire mapping system can establish mapping relationships from scratch.

[0034] Step S4: The firmware receives the TLP request, parses the corresponding device identifier from the BDF according to the topology search algorithm specified by the PCIe protocol, determines the corresponding UUID, and writes the mapping relationship between the BDF and the UUID into the hardware mapping table.

[0035] Step S4 specifically includes: Step S4.1: Based on the tree search algorithm of the PCIe protocol, parse the corresponding DSP port identifier from the BDF, and then determine the corresponding endpoint device and its pre-assigned UUID.

[0036] The target device is the virtual device that the host is addressing in this TLP request.

[0037] The specific execution process of the PCIe topology search algorithm is as follows: The firmware parses the data hierarchically based on the physical path traversed when the TLP request arrives. First, it determines how many PCIe bridge levels the data has passed through using the Bus number in the BDF. Then, it determines which slot on the corresponding Bus the target device is connected to using the Device number. Finally, it locates the specific functional unit within the multifunction device using the Function number.

[0038] Since the firmware has logically associated the UUID with the DSP port identifier in the PCIe tree structure in step S1, once the firmware determines the DSP port connected to the target device through the above tree search process, it can directly find the UUID associated with that DSP port. The firmware writes the mapping relationship between the BDF and UUID of the target device into the BDF-to-UUID mapping table, and the hardware then activates the mapping entry.

[0039] Step S5: When subsequent TLP requests pointing to the same BDF arrive, the corresponding UUID is obtained directly by querying the hardware mapping table. The firmware processes the target device based on the UUID.

[0040] After the mapping relationship is established in step S4, all subsequent TLP requests carrying the same BDF will hit the BDF-to-UUID mapping table in step S3 when they arrive at the hardware acceleration unit. The hardware directly returns the corresponding UUID. The firmware's processing of the target device based on the UUID here means that after receiving the request information with the UUID, the firmware uses the UUID as the key to look up the internal data structure of the target device, locates the corresponding processing function and context information of the target device, and then executes the specific operation indicated by the TLP request (such as configuration space read / write, BAR space read / write, device status query, etc.).

[0041] This two-stage processing mode, where the initial mapping is established by firmware and subsequent table lookups are performed directly by hardware, reduces the device location overhead for each subsequent TLP request to a constant level. In a pure software solution, for each TLP request issued by a BDF, the firmware needs to re-perform a PCIe tree search to determine the target device. Its time complexity is O(logN) or O(N). However, with the hardware mapping table in this embodiment, all subsequent accesses are converted from BDF to UUID by hardware, with a time complexity of O(1). Taking a single chip supporting 1000 virtual devices as an example, the tree search for each TLP in the pure software solution takes an average of about 1 microsecond, while the hardware table lookup only takes 5 nanoseconds, a difference of about 200 times. In large-scale, high-frequency access scenarios, this difference, after being accumulated and amplified, determines whether the system can meet the timing requirements of PCIe response.

[0042] In the hardware acceleration unit, TLP requests processed by the BDF-to-UUID mapping table are sent to different TLP queues according to their type and target. The TLP queue is a message buffer between the hardware and firmware, used to temporarily store requests awaiting firmware processing. Each TLP queue can be bound to a specific ARM core, and the ARM core retrieves requests from its bound TLP queue and processes them one by one. This queuing mechanism is the basis of request scheduling in the firmware emulation device system; its details can be adjusted according to the actual implementation and are not further limited in this invention.

[0043] As a second possible embodiment of the present invention, based on the UUID of the target device obtained in step S5 of the first embodiment, a specific scheme for address acceleration of PCIe Memory type access using the UUID is further provided.

[0044] The first embodiment solves the device identification problem of "which device is the host looking for" by using a BDF-to-UUID mapping table. UUID serves as the device identifier, enabling the firmware to locate the target device in O(1) time.

[0045] However, after resolving the device identification issue, a new performance bottleneck emerged. This bottleneck lies in the fact that when the host initiates a memory access to a specific device register, the access address carried in the TLP is a 64-bit address. This address is determined by the host's BAR allocation mechanism and changes across different servers, different kernel versions, and even after each reboot of the same server. In cloud computing scenarios, virtual machines may dynamically migrate between different physical servers, making the uncertainty of the BAR address even more pronounced.

[0046] In the current approach, after receiving the Memory TLP, the firmware needs to extract the 64-bit access address and compare it item by item in its internally registered address range table. This comparison process requires determining whether the access address falls within a specific address range, involving addition, subtraction, and comparison operations on the 64-bit value. When the device scale reaches the K level, the number of entries in the address range table is enormous, and the cumulative time spent on item-by-item comparison can easily exceed the TLP response timeout threshold of the PCIe specification. Once a timeout occurs, the host side will trigger a PCIe transaction timeout error, which can lead to system crashes in severe cases.

[0047] This embodiment addresses the aforementioned bottleneck by providing a solution that utilizes a hardware address mapping table to eliminate the address calculation overhead on the firmware side.

[0048] In this embodiment, after step S5, the method further includes the following steps: Step S6: During the initialization phase, the firmware registers mapping entries in the hardware's address mapping table for the address range corresponding to the function of each virtual device.

[0049] Each mapping entry contains at least the following fields: starting address, address range length, UUID, function number, and enable flag (EN, Enable). The address mapping table is implemented using a key-value pair structure and is maintained by the hardware unit. The key is a combination of the UUID and the address range, and the value contains the function number, enable flag, and offset calculation parameters.

[0050] During system initialization, the firmware pre-plans the address space layout corresponding to each function based on the PCIe configuration space information of each virtual device. The configuration space information includes the number and size of BARs (Base Address Registers). For example, for a virtual network interface card device, its BAR0 space can be mapped to the control register area, and the BAR1 space can be mapped to the doorbell register area. Each area is assigned a unique function number.

[0051] Table 2 shows an example of a typical entry in the address mapping table: Table 2

[0052] Enable flags are designed for specific purposes. During device operation, access to certain address ranges is only permitted under specific conditions. For example, the address space corresponding to the Option ROM should not be accessed before it has finished loading. Similarly, when a device function is dynamically disabled during operation, its corresponding address space should also be masked. Using enable flags, firmware can dynamically control access permissions for that address range simply by toggling a single bit without deleting or modifying the entry content.

[0053] Step S7: Receive a Memory type TLP request sent by the host. The TLP request contains the target request address.

[0054] Step S8: Query the address mapping table using the UUID and the target request address to determine if a matching entry exists.

[0055] A match must meet two conditions simultaneously: first, the UUID must be the same as the UUID field of the entry; second, the target request address (denoted as Target_Addr) must fall within the range defined by the entry. This range consists of a first address and a second address, where the first address is the starting address and the second address is the sum of the starting address and the address range length. In other words, ADDR ≤ Target_Addr must be satisfied. <ADDR + LEN。

[0056] The hardware employs a parallel comparison architecture for address range matching. Upon receiving the UUID and address, the hardware simultaneously compares the target requested address with the range of all entries in the table. Because the comparison logic is executed in parallel within combinational circuitry, the entire matching process can be completed within one clock cycle.

[0057] If a matching entry exists and the enable flag is off, the hardware directly returns a preset response to the host without forwarding the request to the firmware. The intention behind this design is that, in cloud computing scenarios, the host often traverses the entire configuration space of the device using standard commands. Within the 4KB configuration space, only a small portion of the registers are actually implemented. The remaining addresses correspond to unimplemented space. Without an interception mechanism using the enable flag, these accesses to the unimplemented space would be sent to the firmware for processing. By setting the enable flag of the entry corresponding to the unimplemented address space to off, the hardware completes the interception and response at the entry point, preventing these invalid requests from consuming firmware computing power.

[0058] If a matching entry exists and the enable flag is set to "on," the hardware encapsulates the following four pieces of information into a simplified request message: function number, offset, read / write flag, and data. The offset is obtained by subtracting the starting address from the target request address. After encapsulation, the hardware sends the simplified request message to the firmware via the TLP queue.

[0059] A key design feature of this embodiment is that the offset calculation is performed by the hardware. The hardware calculates the offset in parallel within the same clock cycle when it determines that the target requested address falls within the range. The message received by the firmware no longer contains the original 64-bit address, but rather a pre-parsed function number and offset tuple. This design eliminates the need for the firmware to perform any address calculations.

[0060] Step S9: The firmware receives the simplification request message, locates the corresponding processing function in the function pointer table using the function number as an index, passes the offset as a parameter to the processing function, and the processing function performs the corresponding register or memory access operation.

[0061] The firmware pre-constructs an array of function pointers during initialization. The array index is the function number. For example, FuncTable[0] points to the processing function in the device configuration space, and FuncTable[1] points to the processing function in the BAR0 space. After receiving the simplified request message, the firmware extracts the function number from the message and directly uses the number as the array index to obtain the corresponding function pointer to complete the function call. The entire process does not require any conditional judgment or loop traversal.

[0062] The following comparison of processing flows illustrates the performance improvement brought by this embodiment. In a pure software implementation, firmware processing a single Memory TLP requires: extracting a 64-bit address from the TLP, traversing the address range table for item-by-item comparison, performing 64-bit numerical operations for each comparison, determining the function index through conditional branching after finding a matching range, and finally calling the function. In this process, the cumulative time for extraction, traversal, and numerical operations is in the microsecond range. However, with the solution in this embodiment, all the above steps are completed by hardware in the nanosecond range. The firmware receives a parsed binary tuple and only needs to perform one array indexing operation to locate the processing function. In high-frequency access scenarios with K-level devices, the accumulated microsecond-level processing time saved for each TLP ensures that the system can meet the timing requirements of PCIe response.

[0063] In step S8, after querying the address mapping table using the UUID and the target request address, step S8 further includes: Step S8b-1: When there are two mapping entries in the address mapping table with the same starting address but different address range lengths, the enable status of the Option ROM is detected according to the enable flag of the Option ROM (Option Read-Only Memory) of the virtual device corresponding to the UUID.

[0064] If the Option ROM is enabled, the corresponding mapping entry of the Option ROM is retained and another mapping entry is cleared.

[0065] If the Option ROM is disabled, the corresponding mapping entry for the Option ROM is cleared and another mapping entry is restored.

[0066] In addition, address conflicts not related to Option ROM are not allowed, and the firmware guarantees the uniqueness of addresses from a design perspective.

[0067] This sub-step addresses the address range overlap issue in Option ROM scenarios within the PCIe specification. In the PCIe specification, Option ROM and the device's normal configuration space may overlap in address mapping. The specification allows two entries of different lengths to have the same starting address. The firmware retrieves the Option ROM's enable flag by reading relevant registers in the device's PCIe configuration space to determine if the Option ROM is currently enabled. Based on the determination, the firmware dynamically switches the enabled mapping entries, ensuring that at any given time, an address range matches only one function number. This design avoids processing function call errors caused by fuzzy address range matching.

[0068] As a third possible embodiment of the present invention, based on the UUID assigned to each virtual device in step S1 of the first embodiment, a virtual device status monitoring scheme using the UUID as an index is further provided.

[0069] In the first embodiment, a unique UUID is assigned to each virtual device. After the device is correctly identified and put into operation, the upper-layer management software needs to continuously monitor the status changes of each virtual device. These status changes include driver loading completion, driver unloading, device errors, link status changes, etc. Only by obtaining this status change information in a timely manner can the management software make correct scheduling decisions.

[0070] In cloud computing scenarios, the number of virtual devices simulated on a single physical server can reach the K-level. If a separate interrupt notification channel were established for each device, 1000 devices would require 1000 interrupt lines. This approach is too costly and lacks scalability. Therefore, existing technologies use a polling Bitmap approach: the firmware summarizes the device status into a Bitmap, and the management software reads it periodically.

[0071] In the single-bit Bitmap scheme, each device uses only one bit to represent "whether a change has occurred." When the device state oscillates rapidly between two polling intervals, the final state of this bit value may be exactly 0. The management software, upon reading 0, mistakenly interprets it as the device remaining unchanged. In cloud computing environments, dynamic migration, elastic scaling, and fault recovery of virtual machines all cause frequent state jumps. The probability and frequency of state oscillations increase significantly, making the missed detection problem of the single-bit scheme even more prominent.

[0072] This embodiment addresses the aforementioned problem of missed detection of state oscillations by providing a reliable state monitoring scheme based on double-bit tags.

[0073] In this embodiment, the method further includes: The firmware allocates two adjacent bits to each virtual device. The lower-order bit is designated as the Change Bit (CB), and its value is toggled each time the virtual device's state changes. The higher-order bit is designated as the Update Bit (UB), and it is set to 1 by the firmware and held in place when the virtual device's state changes.

[0074] The physical storage location of these two bits is a set of consecutive bits in the Bitmap. Bits 0 and 1 of the Bitmap correspond to the virtual device with UUID=0, bits 2 and 3 correspond to the virtual device with UUID=1, and so on.

[0075] The following uses a specific state change sequence to illustrate the operating principle of the two-bit mechanism. Assume that the initial state of a virtual device is normal operation (state = 0), and both CB and UB have initial values ​​of 0. During the first polling cycle, the device undergoes continuous state changes. The specific change process is shown in Table 3: Table 3

[0076] As shown in Table 3, the device state flipped twice (0→1→0) during the polling interval. At time t2, the final state returned to 0, the same as the initial state. However, since UB was set to 1 and maintained at time t1 (the first change), the management software can still accurately determine that the device has undergone a state change at time t3 by using UB=1. The management software's judgment will not be misled by the current value of CB being 0.

[0077] In contrast, in the single-bit scheme, the single bit is set to 1 at time t1. If the firmware actively clears this bit at time t2 (when the state returns to 0), the management software reads 0 at time t3. At this point, the device state has indeed returned to 0. From the management software's perspective, the read value is 0, the current state is 0, and everything seems normal—but the two intermediate state changes "state 0→1→0" have been completely missed.

[0078] This characteristic of the update bit—once set, it remains until actively cleared by the management software—is the core mechanism for resolving the oscillation omission problem. The firmware sets the update bit to 1 when the virtual device state first changes. The update bit remains 1 until the management software reads and clears it, unaffected by any subsequent state flips.

[0079] Step S10: The management software periodically reads the bitmap of all virtual devices to obtain the combination information of the changed bits and updated bits of each virtual device.

[0080] The bitmap storage structure is as follows: the Nth status flag unit corresponds to the virtual device with UUID N. Each status flag unit occupies 2 bits, and the bitmaps of all devices are stored in a contiguous address space. The value of N is an integer greater than or equal to 0 and less than the total number of virtual devices.

[0081] Table 4 shows the storage overhead of bitmaps on different device sizes: Table 4

[0082] As can be seen, even in a massive scenario supporting 16,000 virtual devices, the total size of the bitmap is only 4KB. This extremely compact storage solution allows management software to read all device status change information into memory at once, which can be completed with a single DMA operation or MMIO read, resulting in extremely low I / O overhead.

[0083] Step S11: The management software determines whether the virtual device's state has changed based on the value of the update bit. If the update bit is 1, it is determined that the virtual device has undergone at least one state change between the two reads. The management software further obtains the specific state information of the device after the change through a separate information reading interface. If the update bit is 0, the device is skipped directly without further processing.

[0084] The management software processes the data as follows: After reading the Bitmap, it iterates through each status marker unit, checking only the value of the UB bit. If UB=1, it indicates that the device has undergone at least one status change within the time window from the previous read to the current read. The management software then obtains the detailed status through a separate information reading interface. If UB=0, the device's status has not changed, and the management software performs no additional operations.

[0085] This logic of checking only UB (Uniform Binary Data) results in extremely low polling overhead. In a normally operating system, most devices do not undergo state changes during most polling cycles. For these devices with UB=0, the management software consumes almost no CPU processing time. For devices with UB=1, the management software performs targeted queries. Compared to the single-bit scheme that requires comparing the differences between bitmaps in consecutive rounds, this logic is simpler and more efficient.

[0086] Step S12: After the management software completes the reading, the firmware will simultaneously clear the changed bits and the updated bits to zero.

[0087] The zeroing operation is performed by the firmware after confirming that the management software has completed the current round of reading. After zeroing, both CB and UB return to 0, awaiting the triggering of the next round of state change events. The zeroing operation essentially marks the end of the previous monitoring cycle and the beginning of the next monitoring cycle.

[0088] As a fourth possible embodiment of the present invention, such as Figure 2 As shown, based on the method described in steps S1 to S5 of the first embodiment, a BDF to UUID mapping system for firmware simulation is also provided.

[0089] In this embodiment, the system includes: The identification association module is used to respond to the user's operation of creating virtual devices, assign a unique UUID to each virtual device, and logically associate the UUID with the corresponding DSP port identifier in the pre-built PCIe tree structure.

[0090] The request receiving module is used to receive TLP requests of type config carrying BDF sent by the host when it initiates enumeration.

[0091] The hardware query module uses the hardware mapping table to check if the BDF in the TLP request already has a corresponding UUID. If a match is found in the hardware mapping table, the corresponding UUID is directly output, and the process jumps to the subsequent processing module. If no match is found, the original information of the TLP request is forwarded to the firmware.

[0092] The mapping establishment module is used by the firmware to receive TLP requests, parse the corresponding device identifier from the BDF according to the topology search algorithm specified by the PCIe protocol, determine the corresponding UUID, and write the mapping relationship between the BDF and the UUID into the hardware mapping table.

[0093] The subsequent processing module is used to directly retrieve the corresponding UUID from the hardware mapping table when a subsequent TLP request pointing to the same BDF arrives. The firmware then processes the target device based on the UUID.

[0094] The functions of each module described above correspond completely to the methods described in steps S1 to S5 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.

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

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

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

[0098] 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 method for mapping BDF to UUID for firmware emulation, characterized in that, Includes the following steps: Step S1: In response to the user's operation of creating a virtual device, assign a unique UUID to each virtual device and logically associate the UUID with the corresponding DSP port identifier in the pre-built PCIe tree structure; Step S2: When the receiving host initiates enumeration, the host sends a TLP request of type config carrying BDF; Step S3: Use the hardware mapping table to check if the BDF in the TLP request already has a corresponding UUID; If the hardware mapping table has been matched, the corresponding UUID will be output directly, and the process will jump to step S5. If the request is not hit, the original information of the TLP request is forwarded to the firmware; Step S4: The firmware receives the TLP request, parses the corresponding device identifier from the BDF according to the topology search algorithm specified by the PCIe protocol, determines the corresponding UUID, and writes the mapping relationship between the BDF and the UUID into the hardware mapping table. Step S5: When a subsequent TLP request pointing to the same BDF arrives, the corresponding UUID is obtained directly by querying the hardware mapping table, and the firmware processes the target device based on the UUID.

2. The method according to claim 1, characterized in that, The hardware mapping table mentioned in step S3 is a BDF-to-UUID mapping table, which is maintained by the hardware unit and supports single-cycle table lookup to output the corresponding UUID.

3. The method according to claim 1, characterized in that, In step S4, the firmware receives the TLP request, parses the corresponding device identifier from the BDF according to the topology search algorithm specified in the PCIe protocol, and then determines the corresponding UUID, including: Based on the tree search algorithm of the PCIe protocol, the corresponding DSP port identifier is parsed from the BDF, and then the corresponding endpoint device and its pre-assigned UUID are determined.

4. The method according to claim 1, characterized in that, The UUID is specified by the user when creating the device on the cloud management platform. The UUID is a fixed number inside the firmware and is unrelated to the BDF dynamically assigned by the host. The firmware uses UUIDs to manage virtual devices in a unified manner, which includes device object organization, memory space allocation, and status maintenance.

5. The method according to claim 1, characterized in that, Also includes: Step S6: During the initialization phase, the firmware registers mapping entries for the address range corresponding to the function of each virtual device in the hardware's address mapping table; each mapping entry includes at least the starting address, address range length, UUID, function number, and enable flag; Step S7: Receive a Memory type TLP request sent by the host. The TLP request contains the target request address. Step S8: Query the address mapping table using the UUID and the target request address to determine if there is a matching entry; the matching entry is an entry with the same UUID and the target request address is located within the interval formed by the first address and the second address, where the first address is the starting address and the second address is the sum of the starting address and the address range length; If a match entry exists and the enable flag is off, the hardware directly returns a default response to the host without forwarding the request to the firmware. If a match entry exists and the enable flag is on, the hardware will encapsulate the function number, offset, read / write flag, and data into a simplified request message and send it to the firmware via the TLP queue. The offset is obtained by subtracting the starting address from the target request address; Step S9: The firmware receives the simplified request message, locates the corresponding processing function in the function pointer table using the function number as an index, passes the offset as a parameter to the processing function, and the processing function performs the corresponding register or memory access operation.

6. The method according to claim 5, characterized in that, After querying the address mapping table using the UUID and the target request address, the method further includes: Step S8.1: When there are two mapping entries in the address mapping table with the same starting address but different address range lengths, the enable status of the Option ROM is detected according to the enable flag of the Option ROM of the virtual device corresponding to the UUID; If the Option ROM is enabled, the corresponding mapping entry of the Option ROM is retained and another mapping entry is cleared; If the Option ROM is disabled, the corresponding mapping entry for the Option ROM is cleared and another mapping entry is restored.

7. The method according to claim 1, characterized in that, The firmware allocates two adjacent bits to each virtual device, with the lower bit being designated as the change bit, and its value is flipped each time the virtual device state changes. The high-order bit is recorded as the update bit, which is set to 1 by the firmware and retained when the virtual device state changes; The method further includes: Step S10: The management software periodically reads the bitmap of all virtual devices to obtain the combination information of the changed bits and updated bits of each virtual device; Step S11: The management software determines whether the state of the virtual device has changed based on the value of the update bit. If the update bit is 1, it is determined that the virtual device has undergone at least one state change between the two reads. Step S12: After the management software completes the reading, the firmware will simultaneously clear the changed bits and the updated bits to zero.

8. The method according to claim 7, characterized in that, The firmware sets the update bit to 1 when the virtual device state first changes. The update bit remains at 1 until the management software reads and clears it, and is not affected by the virtual device state flipping multiple times during the read interval.

9. The method according to claim 7, characterized in that, The storage structure of the bitmap is as follows: the Nth status flag unit corresponds to the virtual device with UUID N, each status flag unit occupies 2 bits, and the bitmap of the entire device is stored in a continuous address space; where N is an integer greater than or equal to 0 and less than the total number of virtual devices.

10. A BDF-to-UUID mapping system for firmware emulation, characterized in that, include: The identification association module is used to respond to the user's operation of creating virtual devices, assign a unique UUID to each virtual device, and logically associate the UUID with the corresponding DSP port identifier in the pre-built PCIe tree structure; The request receiving module is used to receive TLP requests of type config, which carry BDF, sent by the host when the host initiates enumeration. The hardware query module is used to query whether the BDF in the TLP request already has a corresponding UUID using the hardware mapping table; If the hardware mapping table has been matched, the corresponding UUID will be output directly, and the process will jump to the subsequent processing module. If the request is not hit, the original information of the TLP request is forwarded to the firmware; The mapping establishment module is used by the firmware to receive TLP requests, parse the corresponding device identifier from BDF according to the topology search algorithm specified by the PCIe protocol, determine the corresponding UUID, and write the mapping relationship between BDF and UUID into the hardware mapping table. The subsequent processing module is used to directly query the corresponding UUID through the hardware mapping table when a subsequent TLP request pointing to the same BDF arrives, and the firmware processes the target device based on the UUID.

Images