Bus communication method and related device

Abstract

The embodiment of the application discloses a bus communication method and related equipment, wherein the bus communication method can be applied to a bus system, the bus system comprises a plurality of devices interconnected through a bus, wherein at least the first device and the second device are included; the method can comprise: the first device sends an address translation request to the second device, the address translation request comprises a first identifier and a virtual address of a virtual address space to be translated, the virtual address space comprises one or more STUs; the second device generates one or more translation response messages in response to the address translation request; each translation response message comprises the first identifier, target location information and a target physical address; the second device feeds back one or more translation response messages to the first device; for each translation response message, the first device initiates a read-write access operation to the target physical address according to the first identifier and the target location information. The application can improve the performance of the bus system and improve the bus utilization.

Description

Technical Field

[0001] This application relates to the field of bus communication technology, and in particular to a bus communication method and related equipment. Background Technology

[0002] As computing and data-intensive applications such as Artificial Intelligence (AI), autonomous driving computing, and cloud computing become increasingly widespread, the entire computing system will become increasingly complex. Various proprietary computing devices, such as Graphics Processing Units (GPUs) and Tensor Processing Units (TPUs), will be widely integrated through interconnect technologies to form a massive computing system. This system will involve the application of numerous technologies, including virtualization (such as cloud computing) and heterogeneous computing. A common key technical challenge in implementing these technologies is how to more efficiently achieve communication between the various computing nodes within the system.

[0003] For example, regarding address access issues in bus communication of computing systems, on the one hand, as computing systems grow larger, a particular computing node will be accessed more frequently by multiple other computing nodes. This could cause the address translation of the accessed computing node to become a performance bottleneck for the entire computing system. On the other hand, in heterogeneous computing systems, each computing node has an independent physical address space, but a shared virtual address space. This inevitably leads to a large demand for address translation between computing nodes, resulting in significant bus bandwidth consumption. Currently, existing technologies have introduced an Address Translation Service (ATS) mechanism. This mechanism can obtain the address translation result of the target node before a computing node accesses data, and then use this address translation result to directly initiate the corresponding operation request to the physical address of the target node, thereby enabling access to that target node.

[0004] However, the aforementioned ATS mechanism in the prior art has many limitations, such as limitations on the number and order of translation responses during the address translation process, resulting in low translation efficiency and low bus bandwidth utilization. Therefore, it is no longer able to better match today's higher bandwidth and higher speed interconnect buses.

[0005] Application content

[0006] This application provides a bus communication method and related equipment to improve the efficiency and flexibility of bus communication.

[0007] In a first aspect, embodiments of this application provide a bus communication method applicable to a bus system, the bus system including multiple devices interconnected via a bus, the multiple devices interconnected via the bus including at least a first device and a second device; the method may include: the first device sending an address translation request to the second device, the address translation request including a first identifier identifying the address translation request and a virtual address of a virtual address space to be translated, the virtual address space to be translated including one or more Minimum Translation Units (STUs); the second device responding to the address translation request generating one or more translation response messages; wherein each of the one or more translation response messages includes the first identifier, target location information, and a target physical address, the target location information being the location information of one or more target STUs in the virtual address space to be translated, and the target physical address being the physical address after translating the virtual address of the one or more target STUs; the second device feeding back the one or more translation response messages to the first device; for each translation response message, the first device initiating a read / write access operation to the target physical address based on the first identifier and the target location information.

[0008] This application provides a bus communication design scheme, particularly relating to the design of an address translation mechanism in bus communication. This includes redefining the address translation request and response mechanism to improve address translation efficiency and bus bandwidth utilization. Specifically, during the process of requesting the translation of a virtual address into a physical address, each translation response message from the translation response side carries an identifier for its corresponding address translation request and adds target location information not present in existing translation response messages. This target location information refers to the position of the currently translated address segment within the address space to be translated. Based on this information, the translation request side can accurately identify which address segment in which address space is being translated by any given translation response message. Therefore, regardless of the order in which the translation response side sends back the translation response messages, it will not affect the translation request side's ability to reconstruct the translation result, thus enabling out-of-order feedback of translation response messages. Based on the characteristics of this out-of-order translation response message, the translation response side can send back translation response messages in batches and out of order (i.e., the first message to be translated can be sent back first) according to the actual translation progress. Each batch can contain multiple translation response messages, avoiding the problem in existing technologies where the translation response messages do not carry any position indication information and therefore can only be sent back in a predetermined order (such as the order based on the continuity of virtual addresses), resulting in untranslated messages delaying the feedback progress of translated messages. Therefore, this embodiment can effectively improve the efficiency and parallelism of translation responses, while also increasing the utilization of bus bandwidth. Furthermore, once the translation request side receives the translation response message, it can perform data read / write access operations (e.g., Direct Memory Access (DMA) operations) based on the received message, thus greatly reducing the latency of access operations by the translation request side. This further improves the overall performance of bus communication and makes fuller and more efficient use of bus bandwidth. In other words, because the embodiments of this application add the location information of the smallest translation unit (STU) of the current translation to the translation response message, there is no constraint on the feedback order between translation response messages. Therefore, the translation response messages can be fed back out of order, in parallel, or serially. Thus, the untranslated virtual addresses corresponding to the translated physical addresses in any two translation response messages can be discontinuous. This avoids the problems of inflexible design, extended translation time, low translation efficiency, and low bandwidth utilization caused by the existing technology, which can only perform order-preserving feedback in a strict order.

[0009] Based on the above, in this embodiment, from the perspective of the translation response side (such as the Translation Agent (TA)), since the ordering requirement of bus routing is removed and out-of-order feedback of translation response messages is implemented, the TA can have more flexible design space, maximize the utilization of bus bandwidth, obtain a smaller bus routing latency, and reduce the design difficulty of bus support for address translation services. From the perspective of the translation request side (such as the Address Translation Cache (ATC)), since the translation response side implements out-of-order feedback of translation response messages, the latency of ATC receiving translation feedback results will be smaller, thus the efficiency of subsequent access operations will be higher, and the utilization rate of bus bandwidth will also be higher. In summary, compared with the bus mechanism in the prior art, the embodiments of this application realize that more than two translation response messages can be fed back for one address translation request (the prior art stipulates a maximum of no more than two), and these translation response messages can be transmitted out of order in the bus routing. Different translation response messages can be transmitted in parallel or serially. That is, while ensuring the high completion rate of address translation requests (such as the total size of the translated address space / the size of the untranslated address space requested by the address translation request), the utilization rate of bus bandwidth is further improved.

[0010] In one possible implementation, the target location information includes the base address of the first target STU among the one or more target STUs, and the size of the address space of the one or more target STUs. In this embodiment, target location information added to the translation response message is defined. Specifically, it can be the base address of the first STU to be translated plus the size of the translated address space, thereby indicating to the translation request side the specific location of the STU currently being translated in the original virtual address space to be translated.

[0011] In one possible implementation, the first device initiates a read / write access operation to the target physical address based on the first identifier and the target location information, including: the first device determining the virtual address of the one or more target STUs based on the first identifier and the target location information; determining the read / write access operation corresponding to the virtual address of the one or more target STUs; and initiating the read / write access operation to the target physical address. In this embodiment, the first device first determines the virtual address of the original virtual address space to be translated corresponding to the translation response message based on the first identifier in the translation response message. Based on the virtual address and combined with the target location information, the virtual address of the one or more target STUs being translated in the current translation response message can be determined. Based on the specific virtual address of the one or more target STUs, the specific read / write access operation corresponding to the virtual address of the one or more target STUs can be further determined, thereby ultimately initiating the read / write access operation to the corresponding physical address.

[0012] In one possible implementation, the first device is one or more of a graphics processing unit (GPU), a network interface card (NIC), or an accelerator, and the second device is a processor or a host containing a processor. Further optionally, the first device is one or more of a GPU, NIC, or accelerator implementing Address Translation Cache (ATC) functionality, and the second device is a processor implementing Translation Agent (TA) functionality or a host containing a processor. This application embodiment exemplifies the specific functional modules or chips corresponding to the first and second devices included in the bus system involved in this application. It is understood that the first or second device in this application embodiment includes, but is not limited to, the specific functional modules or chips described above.

[0013] In one possible implementation, the address translation request further includes usage information of the virtual address space, which includes one or more of the following: usage frequency, access frequency, or regional expectations of the virtual address space.

[0014] In this embodiment of the application, the address translation request initiated by the translation requesting side (i.e., the first device, such as the ATC side) to the translation response side (i.e., the second device, such as the TA side) may also carry the usage information of the virtual address space to be translated by the ATC side, such as the usage frequency, access frequency, and whether the virtual address space to be accessed needs to be cached locally, so that the TA side can optimize these virtual address spaces to be translated based on the usage information. For example, the TA side may use this usage information to determine whether the page table mapping corresponding to this virtual address space needs to be cached to the CPU's MMU.

[0015] In one possible implementation, each translation response message further includes one or more of the memory attributes of the one or more target STUs, first indication information, or translation extension information; wherein, the memory attributes include whether the target STU is cacheable or the size of the access latency corresponding to the target STU, and the first indication information is used to indicate whether the current translation response message is the last response message among the one or more translation response messages.

[0016] In this embodiment of the application, the translation response message fed back by the translation response side (i.e., the second device, such as the TA side) to the translation request side (i.e., the first device, such as the ATC side) may also carry some memory attribute information of the currently translated virtual address space and translation extension information of the translation response message, so that the translation request side (such as the ATC side) can quickly learn some characteristics of these virtual address spaces to be translated, and optimize the access operation for the virtual address space based on these characteristics.

[0017] In one possible implementation, at least one of the one or more translation response messages further includes the total number of translation response messages corresponding to the address translation request; the method further includes: the second device determining whether the translation response messages corresponding to the address translation request have been received completely based on the number of received translation response messages and the total number of translation response messages; if the reception is complete, the marker resource corresponding to the address translation request is released or reused.

[0018] In this embodiment of the application, the translation response message fed back by the translation response side (i.e., the second device, such as the TA side) to the translation request side (i.e., the first device, such as the ATC side) may also carry the total number of translation response messages corresponding to the address translation request, so that the translation request side can decide whether to reuse or reclaim the marker resource corresponding to the address translation request based on this information, thereby improving resource utilization.

[0019] In one possible implementation, the method further includes: the second device sending an invalidation request to the first device, the invalidation request including a second identifier identifying the invalidation request and virtual addresses of a plurality of invalidation units to be invalidated, wherein the plurality of invalidation units correspond to multiple discrete virtual address spaces to be invalidated; and the first device, in response to the invalidation request, invalidating the virtual address and physical address mapping relationship of each of the plurality of invalidation units.

[0020] This application provides a bus communication design scheme. Besides the address translation mechanism design mentioned above, it further designs the address invalidation mechanism in bus communication, including redefining the address invalidation request mechanism to improve the performance of invalidation commands. Specifically, unlike existing technologies where invalidation requests can only carry invalidation indications for one contiguous address space segment, this application defines that a single invalidation request can carry invalidation information for multiple non-contiguous invalid address space segments (i.e., multiple invalidation units), thereby improving the transmission efficiency of invalidation commands and thus improving the overall performance of the system in executing invalidation commands. Furthermore, since an invalidation request command can carry invalidation information for multiple non-contiguous invalid address space segments, the bandwidth utilization of invalidation commands in the bus is greatly improved.

[0021] In one possible implementation, the method further includes: the first device generating one or more invalidation response messages, wherein each invalidation response message includes the second identifier and an invalidation unit number, the invalidation unit number being the number of the currently invalidated invalidation unit among the plurality of invalidation units.

[0022] This application provides a bus communication design scheme. Besides the address translation mechanism design mentioned above, it further designs the address invalidation mechanism in bus communication, including redefining the address invalidation request and response mechanism to improve the performance of invalidation commands. Specifically, by defining a mechanism where an invalidation request can carry invalidation information for multiple non-contiguous invalid address space segments, and the invalidation completion status of the corresponding invalid address space segments can be returned to the invalidation request side (such as the TA side) in batches with multiple invalidation response messages, the transmission efficiency of invalidation commands and the parallelism of invalidation execution are improved, thereby improving the overall performance of the system in executing invalidation commands. Furthermore, since an invalidation request can carry invalidation information for multiple non-contiguous invalid address space segments, the bandwidth utilization of invalidation commands in the bus is greatly improved; and since invalidation response messages can be returned to the invalidation request side (such as the TA side) in batches, the problem of increased latency in invalidation command execution caused by the need to aggregate multiple invalidation response messages is avoided.

[0023] In one possible implementation, at least one of the one or more invalidation response messages further includes the total number of invalidation response messages corresponding to the invalidation request; the method further includes: the second device determining whether the invalidation response messages corresponding to the invalidation request have been received completely based on the number of received invalidation response messages and the total number of invalidation response messages; if the reception is complete, the marker resource corresponding to the invalidation request is released or reused.

[0024] In this embodiment of the application, the invalidation response message fed back by the invalidation response side (i.e., the first device, such as the ATC side) to the invalidation request side (i.e., the second device, such as the TA side) may also carry the total number of invalidation response messages corresponding to the invalidation request, so that the invalidation request side can decide whether to reuse or reclaim the marked resources that have been invalidated based on this information, thereby improving resource utilization.

[0025] In one possible implementation, the method further includes: the first device initiating a page table request to the second device, the page table request including the page table request code in the page request group (PRG) to which the page table request belongs and the virtual addresses of a plurality of page table request units to be requested, wherein the plurality of page table request units correspond to a plurality of non-contiguous page table spaces.

[0026] This application provides a bus communication design scheme. Besides the address translation mechanism design mentioned above, it further designs the page table request mechanism in bus communication, including redefining the page table request mechanism to improve the performance of page table request commands. Specifically, unlike existing technologies where page table requests can only carry the virtual address of a single requested page table space, this application defines a page table request (such as a command / message) that can carry information about multiple page table request units, correspondingly allowing the request to establish multiple non-contiguous page table spaces. That is, because a single page table request message transmitted on the bus can carry information about multiple page table request units, the overhead of page table request commands can be reduced, bus bandwidth utilization can be improved, and the transmission efficiency of page table request commands and bus bandwidth utilization can be increased.

[0027] In one possible implementation, the page table request may also include one or more of the following: page table space size, read / write permissions, expected memory attributes, or usage prompts for each page table request unit.

[0028] In this embodiment, the page table request may also carry expected information about the page table space requested by the page table requesting side (such as the ATC side), such as the expected size of the page table space, the memory model attributes of the expected page table space, and system attributes. From the ATC side's perspective, this provides an interface for the ATC side to submit more user expected information when requesting page tables from the page table responding side (such as the TA side or the system side). In this way, the TA can create page tables for the corresponding ATC based on more accurate user information, thereby enabling the ATC to optimize its DMA behavior according to the memory model attributes of the corresponding space, thus expanding the design space of the ATC. From the perspective of the page table response side (such as the TA side), the TA has the opportunity to adjust its page table creation strategy and the attributes of the page tables based on this expectation information. This greatly expands the design space of the TA / system, making the page tables created by the TA / system for the ATC more in line with the ATC's expectations. This can improve the overall page table management efficiency and enhance the overall system performance. For example, based on the size and usage of the page table request unit that the ATC wants to request, the TA / system can determine the size (granularity) of the corresponding page table and whether the corresponding page table can be pre-loaded into the cache.

[0029] In one possible implementation, the method further includes: the second device generating one or more page table response messages in response to the page table request; wherein each page table response message includes the page table request code and a mapping relationship between the virtual address and physical address of the currently established page table request unit, or each page table response message includes the page table request code; the second device feeding back the one or more page table response messages to the first device.

[0030] This application provides a bus communication design scheme. Besides the address translation mechanism design mentioned above, it further designs the page table request and response mechanism in bus communication, including redefining the page table request and response mechanism to improve the performance of page table request and response commands. Specifically, it defines that a page table request (such as a command / message) can carry information about multiple page table request units, correspondingly requesting the establishment of multiple non-contiguous page table spaces from the system. Furthermore, it defines that multiple page table response messages can correspond to the same PRG, and the page table response side (such as the TA side) can send page table response messages back to the page table request side (such as the ATC side) in batches without order requirements. Optionally, these page table response messages can directly carry information about successfully established page tables, so that after the first address translation request by the ATC results in a page fault, a second page table request can be issued to obtain the address mapping result, reducing the need for sending and responding to a second address translation request compared to existing technologies. This application embodiment reduces the steps required by existing Address Translation Service (ATS) technology after a page fault during the first page table request, from obtaining the required address mapping result again, thereby improving the system's memory access performance. It is understood that when each page table response message only includes the page table request code and not the address mapping relationship, ATC needs to issue a corresponding address translation request after issuing the page table request to further request the untranslated virtual address. In summary, the page table response message in this application embodiment includes two implementation methods: one is a method that only requires initiating a page table request once after a page fault, and the other is a method that requires both a page table request and an address translation request after a page fault, thus simultaneously supporting both page table response methods.

[0031] In one possible implementation, each page table response message further includes one or more of the following: the base address of the page table space corresponding to the established page table request unit, the page table space size, the memory model attributes of the page table space, read / write permissions, or system attributes.

[0032] In this embodiment, the page table response message also carries one or more of the following: the base address of the page table space corresponding to the currently established page table request unit, the size of the page table space, the memory model attributes of the page table space, read / write permissions, and system attributes. This allows the page table response side (such as the TA / system side) to return the attributes of the established page table, and allows the page table request side (such as the ATC side) to obtain more page table attributes. This enables the ATC side to optimize its use of the page table space based on the memory model attributes of the corresponding page table space. For example, it can optimize the subsequent DMA behavior of the ATC side, thereby improving the overall performance of the system and expanding the design space of the ATC.

[0033] In one possible implementation, at least one of the one or more page table response messages further includes the total number of page table response messages corresponding to the page table request group (PRG); the method further includes: the second device determining, based on the total number of page table response messages and the number of received page table response messages, whether the page table response messages corresponding to the page table request group (PRG) have been completely received; if they have been completely received, the marked resource corresponding to the page table request group (PRG) is released or reused.

[0034] In this embodiment of the application, the page table response message fed back by the page table response side (i.e., the second device, such as the TA side) to the page table request side (i.e., the first device, such as the ATC side) may also carry the total number of page table response messages corresponding to the page table request group (PRG) to which it belongs. This allows the page table request side to decide whether to reuse or reclaim the marked resources that have completed page table establishment based on this information, thereby improving resource utilization.

[0035] In one possible implementation, the method further includes: the first device receiving one or more page table response messages from the second device; for each page table response message, the first device initiating an access operation on the corresponding physical address based on the page table request code and the mapping relationship between the virtual address and physical address of the currently established page table request unit; or, for each page table response message, the first device determining the virtual address corresponding to the corresponding page table request unit based on the page table request code, and initiating a translation request for the virtual address corresponding to the page table request unit to the second device.

[0036] In this embodiment, if the page table response message carries information about a successfully established page table, then after a page fault occurs in the first address translation request on the page table requesting side ATC, a second page table request can be issued, and the address mapping result can be directly obtained through the page table response message. Subsequent access operations can then be performed on the corresponding physical address based on the address mapping result. Compared to existing technologies, this reduces the need for a second address translation request, thus reducing the steps required by existing Address Translation Service (ATS) technologies after a page fault occurs during the first page table request, and improving the system's memory access performance. Alternatively, if the page table response message does not carry information about a successfully established page table, then the page table requesting side ATC needs to initiate another address translation request for the virtual address whose page table has not been successfully established.

[0037] Secondly, embodiments of this application provide a bus system, which may include multiple devices interconnected via a bus, including at least a first device and a second device. The first device can be configured to send an address translation request to the second device. The address translation request includes a first identifier identifying the address translation request and a virtual address of a virtual address space to be translated. The virtual address space to be translated includes one or more Minimum Translation Units (STUs). The second device can be configured to generate one or more translation response messages in response to the address translation request. Each of the one or more translation response messages includes the first identifier, target location information, and a target physical address. The target location information is the location information of one or more target STUs within the virtual address space to be translated, and the target physical address is the physical address after translating the virtual address of the one or more target STUs. The second device can be configured to send the one or more translation response messages back to the first device. The first device can be configured to initiate a read / write access operation to the target physical address for each translation response message, based on the first identifier and the target location information.

[0038] In one possible implementation, the target location information includes the base address of the first target STU among the one or more target STUs, and the size of the address space of the one or more target STUs.

[0039] In one possible implementation, the first device is specifically configured to: determine the virtual address of the one or more target STUs based on the first identifier and the target location information; determine a read / write access operation corresponding to the virtual address of the one or more target STUs, and initiate the read / write access operation to the target physical address.

[0040] In one possible implementation, the address translation request further includes usage information of the virtual address space, which includes one or more of the following: usage frequency, access frequency, or regional expectations of the virtual address space.

[0041] In one possible implementation, each translation response message further includes one or more of the memory attributes of the one or more target STUs, first indication information, or translation extension information; wherein, the memory attributes include whether the target STU is cacheable or the size of the access latency corresponding to the target STU, and the first indication information is used to indicate whether the current translation response message is the last response message among the one or more translation response messages.

[0042] In one possible implementation, at least one of the one or more translation response messages further includes the total number of translation response messages corresponding to the address translation request; the second device is further configured to determine whether the translation response message corresponding to the address translation request has been received completely based on the number of received translation response messages and the total number of translation response messages; if the reception is complete, the marker resource corresponding to the address translation request is released or reused.

[0043] In one possible implementation, the second device is further configured to send an invalidation request to the first device, the invalidation request including a second identifier identifying the invalidation request and virtual addresses of a plurality of invalidation units to be invalidated, wherein the plurality of invalidation units correspond to multiple discrete virtual address spaces to be invalidated; the first device is further configured to, in response to the invalidation request, invalidate the virtual address and physical address mapping relationship of each of the plurality of invalidation units.

[0044] In one possible implementation, the first device is further configured to generate one or more invalidation response messages, wherein each invalidation response message includes the second identifier and an invalidation unit number, the invalidation unit number being the number of the currently invalidated invalidation unit among the plurality of invalidation units.

[0045] In one possible implementation, at least one of the one or more invalidation response messages further includes the total number of invalidation response messages corresponding to the invalidation request; the second device is further configured to determine whether the invalidation response message corresponding to the invalidation request has been received completely based on the number of received invalidation response messages and the total number of invalidation response messages; if the reception is complete, the marker resource corresponding to the invalidation request is released or reused.

[0046] In one possible implementation, the first device is further configured to initiate a page table request to the second device. The page table request includes the page table request code of the page table request in the page table request group (PRG) to which it belongs and the virtual addresses of a plurality of page table request units to be requested, wherein the plurality of page table request units correspond to a plurality of non-contiguous page table spaces.

[0047] In one possible implementation, the page table request may also include one or more of the following: page table space size, read / write permissions, expected memory attributes, or usage prompt information for each of the plurality of page table request units.

[0048] In one possible implementation, the second device is further configured to generate one or more page table response messages in response to the page table request; wherein each page table response message includes the page table request code and a mapping relationship between the virtual address and physical address of the currently established page table request unit, or each page table response message includes the page table request code; the second device is further configured to send the one or more page table response messages back to the first device.

[0049] In one possible implementation, each page table response message further includes one or more of the following: the base address of the page table space corresponding to the established page table request unit, the page table space size, the memory model attributes of the page table space, read / write permissions, and system attributes.

[0050] In one possible implementation, at least one of the one or more page table response messages further includes the total number of page table response messages corresponding to the page table request group (PRG); the second device is further configured to determine whether the page table response messages corresponding to the page table request group (PRG) have been completely received based on the total number of page table response messages and the number of page table response messages received; if the reception has been completed, the marked resource corresponding to the page table request group (PRG) is released or reused.

[0051] In one possible implementation, the first device is further configured to: receive one or more page table response messages fed back by the second device; for each page table response message, initiate an access operation on the corresponding physical address according to the page table request code and the mapping relationship between the virtual address and physical address of the currently established page table request unit; or, for each page table response message, determine the virtual address corresponding to the corresponding page table request unit according to the page table request code, and initiate a translation request to the second device for the virtual address corresponding to the page table request unit.

[0052] Thirdly, this application provides a semiconductor chip that may include a bus system provided by any of the implementations of the second aspect above.

[0053] Fourthly, this application provides a semiconductor chip that may include: a bus system provided by any of the implementations of the second aspect above, an internal memory coupled to the bus system, and an external memory.

[0054] Fifthly, this application provides a System-on-Chip (SoC) chip, which includes a bus system provided by any of the implementations in the second aspect above, internal memory coupled to the bus system, and external memory. The SoC chip can be composed of chips or may include chips and other discrete devices.

[0055] Sixthly, this application provides a chip system including the bus system provided by any implementation of the second aspect above. In one possible design, the chip system further includes a memory for storing program instructions and data necessary or related to the operation of the data processing device. This chip system may be composed of chips or may include chips and other discrete devices.

[0056] Seventhly, this application provides a bus communication device that has the function of implementing any of the bus communication methods described in the first aspect above. This function can be implemented in hardware or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the above-described function.

[0057] Eighthly, this application provides a computer-readable storage medium storing a computer program that, when executed by a bus system, implements the bus communication method flow described in any one of the second aspects above.

[0058] In a ninth aspect, embodiments of this application provide a computer program that includes instructions that, when executed by a bus system, cause the bus system to perform the bus communication method flow described in any of the second aspects above. Attached Figure Description

[0059] To more clearly illustrate the technical solutions in the embodiments of this application or the background art, the accompanying drawings used in the embodiments of this application or the background art will be described below.

[0060] Figure 1 This is a schematic diagram of the hardware structure of a PCIe bus system provided in an embodiment of this application.

[0061] Figure 2 This is a schematic diagram of the hardware structure of a bus system provided in an embodiment of this application.

[0062] Figure 3A This is a flowchart illustrating a bus communication method provided in an embodiment of this application.

[0063] Figure 3B This is a schematic diagram illustrating the implementation structure of a translation response message provided in an embodiment of this application.

[0064] Figure 3C This is a schematic diagram illustrating another implementation structure of the translated response message provided in this application embodiment.

[0065] Figure 3D This is a schematic diagram of a physical address space translated from a virtual address space, provided as an embodiment of this application.

[0066] Figure 3E This is a schematic diagram illustrating how all untranslated address spaces of a translation request receive corresponding translation result responses, as provided in an embodiment of this application.

[0067] Figure 4A This is a schematic diagram of the data structure of an invalidation request message provided in an embodiment of this application.

[0068] Figure 4B This is a schematic diagram illustrating the spatial size of a translation result, provided as an embodiment of this application.

[0069] Figure 4C This is a schematic diagram illustrating the format of an invalidation response message provided in an embodiment of this application.

[0070] Figure 5A This is a schematic diagram of a page table response message format with page table information provided in an embodiment of this application.

[0071] Figure 5B This is a schematic diagram illustrating the size of a page table space, provided as an embodiment of this application.

[0072] Figure 5C This is a schematic diagram of another page table response message format with page table information provided in an embodiment of this application.

[0073] Figure 5D This is another schematic diagram illustrating the size of the page table space provided in an embodiment of this application.

[0074] Figure 5E This is a schematic diagram illustrating a scenario in which an ATC receives a page table response message according to an embodiment of this application.

[0075] Figure 6 This is a schematic diagram of the structure of a bus system according to an embodiment of this application. Detailed Implementation

[0076] The embodiments of this application will now be described with reference to the accompanying drawings.

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

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

[0079] As used in this specification, the terms "component," "module," "system," etc., are used to refer to computer-related entities, hardware, firmware, combinations of hardware and software, software, or software in execution. For example, a component can be, but is not limited to, a process running on a processor, a processor, an object, an executable file, an execution thread, a program, and / or a computer. As illustrated, applications running on computing devices and computing devices can both be components. One or more components may reside in a process and / or an execution thread, and components may be located on a single computer and / or distributed among two or more computers. Furthermore, these components can be executed from various computer-readable media on which various data structures are stored. Components can communicate, for example, via local and / or remote processes based on signals having one or more data packets (e.g., data from two components interacting with another component between a local system, a distributed system, and / or a network, such as the Internet interacting with other systems via signals).

[0080] First, some of the terms used in this application will be explained to facilitate understanding by those skilled in the art.

[0081] (1) A bus is a common line or path used in a computer to connect various functional components and transmit data between them. In a computer system, buses can be classified according to the objects they connect to: Chip bus, also known as a device-level bus, which is the bus inside the central processing unit chip; Internal bus, also known as a system bus or board-level bus, which is the transmission path between various functional units of the computer; the microcomputer bus is usually called the internal bus; External bus, also known as a communication bus, which is the transmission path between computer systems, or between the computer host and peripheral devices. The bus communication system in this application may include the aforementioned chip system, internal bus, or external bus.

[0082] (2) Virtual address: For each running program, the system allocates a virtual address space for it, meaning the program runs in a virtual address space. The virtual addresses in this virtual address space do not actually exist in the computer.

[0083] (3) Physical address: The address placed on the address bus. The physical address space is a real entity existing in the computer, maintaining uniqueness in each computer. For reading, the circuit uses the value of each bit of this address to place the data from the corresponding physical memory address onto the data bus for transmission. For writing, the circuit uses the value of each bit of this address to place the content from the corresponding physical memory address onto the data bus.

[0084] (4) Peripheral Component Interconnect Express (PCIe) is an end-to-end interconnection protocol that provides a solution for high-speed transmission bandwidth.

[0085] (5) Root Complex (RC): A platform system may contain one or more RCs. In a PCIe system, RC devices can be used to connect the processor and memory subsystem to a PCI Express switching fabric consisting of one or more switching devices.

[0086] (6) Root Port (RP): Each RC can support one or more RPs. Each RP represents an independent hierarchy.

[0087] (7) Address Translation and Protection Table (ATPT): In a computer operating system, address translation is the process of converting a user's logical address into a physical address in memory, thus completing address relocation. The address translation table is a table used for address translation, where logical addresses and physical addresses are in a one-to-one correspondence. It is mainly used to accelerate the address translation process and improve the speed and efficiency of data reading in the computer system.

[0088] (8) Direct Memory Access (DMA): When a device interface attempts to send data (usually large amounts of data) directly to another device via the bus, it first sends a DMA request signal to the CPU. The peripheral device, through a dedicated DMA interface circuit—the DMA controller (DMAC)—submits a bus request to the CPU to take over bus control. Upon receiving this signal, the CPU, after the current bus cycle ends, responds to the DMA signals according to their priority and the order in which the DMA requests were submitted. When the CPU responds to a DMA request from a device interface, it relinquishes bus control. Thus, under the management of the DMA controller, the peripheral device and memory directly exchange data without CPU intervention. After the data transfer is complete, the device interface sends a DMA end signal to the CPU, returning bus control.

[0089] First, to facilitate understanding of the embodiments of this application, the specific technical problem to be solved by this application is further analyzed and proposed. In the prior art, Address Translation Service (ATS) technology includes various technical solutions. The following are exemplary examples of commonly used PCIe ATS solutions. Specifically:

[0090] Assume the CPU in the host machine has functional modules such as RC / RP, TA, and ATPT, and the PCIe device connected to the host implements ATC. Then, the ATC initiates an address translation request to the TA. After translating, the TA returns the corresponding address mapping to the ATC. The ATC locally caches these address mappings, so when the PCIe device accesses the CPU's memory space (e.g., DMA), it can directly obtain the corresponding physical address from the local ATC, thus directly accessing the CPU's memory space via the physical address. When some address mappings cached locally by the ATC in the TA need to be invalidated, the TA will initiate an invalidation request to the ATC. The ATC invalidates the corresponding locally cached mapping and returns an invalidation response to the TA. It is understood that, including the following related descriptions, the device initiating the address translation request (ATC) is called the ATS requester, and the TA or RC is uniformly called the ATS completer, or simply referred to as TA.

[0091] Analysis reveals the following drawbacks of the aforementioned PCIe ATS solution:

[0092] (1) The address space that a translation request can represent is even more limited under today's high-bandwidth, high-speed buses, with a maximum of 16*2. (STU+12) bytes, while in existing systems, STU is often set to 0. With today's buses having higher bandwidth and speed (for example, the speed of each link in the future officially released PCIe 6.0 will reach 64GT / s), the address space size of the above single application translation will obviously require more translation request commands, thus occupying more bus bandwidth.

[0093] (2) A translation request can correspond to a maximum of two translation response messages, and the translation size in the same response message must be the same. This limits the design space of the translation tool and may increase the probability that a translation request for a single address cannot obtain the translation results for the entire requested address space, thereby reducing the overall translation efficiency.

[0094] (3) The data (translation result) carried in the response to a translation request must logically be contiguous with the address space of the corresponding translation request, and must be from the beginning to the end of that translation space. Furthermore, if there are multiple completion messages, they must be returned in strict order. This also limits the design space of the TA and imposes requirements on the routing and scheduling design of the entire bus. Therefore, the address translation response messages of the ATS will have a greater impact on the bus (obviously, if there were no strict order requirement, the impact on the bus would be smaller).

[0095] (4) An invalidation request message can only carry an invalidation indication for one contiguous address space segment, which increases the overhead of the invalidation request message header.

[0096] (5) A page table request cannot carry more information, such as the size of the page table space to be created, and a page table request can only carry the virtual address of the page table space to be created, which increases the overhead of the page table request header.

[0097] (6) Multiple page table requests under the same PRG can only receive one page table response message, and it cannot carry any established page table information. The corresponding established page table information can only be obtained through an address translation request. This mechanism wastes the opportunity for ATC to issue a page table request, making the process required for ATC to obtain the translation result more cumbersome, which invisibly increases the latency of device data access.

[0098] In summary, the aforementioned PCIe ATS solutions suffer from low communication efficiency, prolonged communication time, excessive bus bandwidth consumption, high bus overhead, and limited design space. Therefore, the technical problems this application aims to solve can include the following aspects: improving the shortcomings of existing ATS technology in terms of insufficient performance under high bandwidth and high speed bus conditions, high bus overhead, and inability to match high bandwidth and high speed bus requirements; extending the ATS mechanism to achieve higher performance and provide a highly scalable interface for the system; and addressing the inefficient mechanism of existing ATS technology requiring an additional page table request interface to request page table creation from the TA (Task Manager) and then obtaining the translation result through an ATS translation request when a page fault occurs, proposing a new page table request and response mechanism to reduce the need for a secondary translation request to obtain the translation result.

[0099] The bus communication method in this application is applicable to various bus system architectures, such as PCIe bus systems and AMBA bus systems. To facilitate understanding of the bus communication method provided in this application, this embodiment will use a PCI Express (PCIe) system as an example to describe the bus communication method in this application. The basic structure of a PCIe system will be described below.

[0100] The PCIe bus is a high-speed serial computer expansion bus standard, employing a point-to-point transmission architecture and a serial connection method. In a PCIe link within a PCIe bus system, the connected ports are completely equal, connecting to the transmitting and receiving devices respectively, and only one transmitting or receiving device can be connected to one end of a PCIe link. However, when a PCIe link is extended using a switch, multiple devices can be connected. A typical structure consists of a root port and an endpoint forming a point-to-point connection pair, while a switch can connect several endpoints simultaneously, thus enabling link expansion. Devices conforming to the PCIe bus standard are generally referred to as PCIe devices, and a PCIe bus system can include multiple PCIe devices interconnected via the PCIe bus.

[0101] Please see Figure 1 , Figure 1 This is a schematic diagram of the hardware structure of a PCIe bus system provided in an embodiment of this application. The PCIe bus system 10 can be located in any electronic device, such as a computer, mobile phone, tablet, or other similar devices. Specifically, the hardware structure of the PCIe bus system 10 can be a chip, a chipset, or a circuit board carrying a chip or chipset. The chip, chipset, or circuit board carrying the chip or chipset can operate under necessary software drivers. Figure 1 The PCIe bus system 10 shown may include multiple PCIe devices interconnected via the PCIe bus. Specifically, for example, the interconnected PCIe devices may include a host 100 and multiple node devices interconnected via the PCIe bus. The host 100 may be a computing system including one or more CPUs 101, main memory 102, a TA 103 including I / O address management functions (e.g., Input / Output Address Management Unit (IOMMU), System Address Management Unit (SMMU) under ARM architecture or VT-d under x86 architecture), and cache memory (e.g., cache), internal interconnect bus, etc., not shown in the figure. Node devices may specifically be a graphics processing unit (GPU1) 105, a smart network card 106, a solid-state drive (SSD) 107, and a graphics processing unit (GPU2) 108, etc.; while the switch 109 is a switching device that can realize functions such as bus interconnection, routing, and congestion control. The host 100 may be interconnected with multiple node devices or the switch 109 through the switching device RC 104.

[0102] Please see Figure 2 , Figure 2This is a schematic diagram of the hardware structure of a bus system provided in an embodiment of this application. This bus system 20 can also be located in any electronic device, such as a computer, mobile phone, tablet, or other similar devices. Specifically, the hardware structure of the bus system 20 can be a chip, a chipset, or a circuit board carrying a chip or chipset. The chip, chipset, or circuit board carrying the chip or chipset can operate under necessary software drivers. Figure 2 In the bus system 20 shown, host 200 is interconnected with various node devices (such as SSD 205, network card 206, accelerator 207, network card 2 208, GPU1 209, GPU2 210) through switching device RC 104. Each node device is also interconnected via a path reachable from each other through switch 211. Each node device may be multipath reachable. Figure 2 The entire interconnect topology of the bus system in the diagram is a flattened graph, no longer... Figure 1 The PCIe bus system in China has a top-down tree structure. Figure 2 The bus system in this application supports multipathing. ATS-related data streams communicate freely on the bus, and each node may be reachable via multiple paths. The bus communication method in this embodiment supports out-of-order response message feedback, thus enabling multipathing (since multipathing inevitably involves out-of-order delivery); while existing ATS technologies, due to routing ordering requirements, cannot support this. Figure 2 The multi-path architecture in [the context].

[0103] Understandable Figure 1 and Figure 2 The bus system architecture described above is just one of several exemplary implementations in this application. The bus system architecture in this application includes, but is not limited to, the application scenarios described above. The bus communication method in this application can also be applied to various parallel buses such as AMBA bus, serial buses, chip buses, internal buses, external buses, and other bus communication system architectures. Other scenarios and examples will not be listed or described in detail.

[0104] The following is in conjunction with the above. Figure 1 or Figure 2 The bus system architecture shown provides an exemplary description of the various interconnected devices involved in the bus system:

[0105] The host computer can contain any CPU, which can be a general-purpose processor (CPU), an embedded processor, a dedicated processor, etc. The host computer may also contain functional modules such as RC / RP, TA, and ATPT.

[0106] A Translation Agent (TA), implemented in hardware or a combination of hardware and software, is responsible for translating virtual addresses in PCIe transactions into actual physical addresses. The TA may support Address Translation Services (ATS), which allows PCIe functions to pre-obtain the address translation relationships of the target memory before initiating data access operations (such as DMA). Optionally, the TA may include a Table Lookup Buffer (TLB) to accelerate access to the address translation table.

[0107] The Address Translation and Protection Table (ATPT) is a table that stores address translation relationships and can be accessed by the Address Translation Table (TA).

[0108] Root Complex (RC): A platform system can contain one or more RCs. In a PCIe system, RC devices can be used to connect the processor and memory subsystem to a PCI Express switching fabric consisting of one or more switching devices.

[0109] Root Port (RP): Each RC can support one or more RPs. Each RP represents an independent hierarchy.

[0110] Switch: Used to expand bus systems, for example, to allow more PCIe devices to be connected, or a PCIe switch.

[0111] Bus devices: such as PCIe devices, which can be network cards, GPUs, SSDs, accelerators, storage, etc. Specifically, for... Figure 1 In the context of the bus system, the network card is mainly used to connect the entire PCIe system to the network, that is, to connect the device to the external network; the accelerator is usually used to assist the CPU in accelerating a specific function, such as the matrix accelerator; the GPU is usually used as a microprocessor to perform image and graphics-related computing tasks; SSD, also known as solid-state drive, is a hard drive made of solid-state electronic storage chip array.

[0112] Address Translation Cache (ATC) is essentially a cache used to store page tables translated by the Address Translation Cache (TA), that is, to cache virtual addresses and their mapped physical addresses. If a PCIe device has its own ATC, then there is no need to query the IOTLB, thus alleviating the pressure on the IOTLB and improving memory access performance. Optionally, the above... Figure 1or Figure 2 The system architecture can include devices that implement ATC or devices that do not. For example, in the above... Figure 1 In the system architecture, ATC functionality is implemented in GPU1, GPU2, and the network card, but not in the SSD; for example, in the above... Figure 2 In the system architecture, ATC functionality can be implemented in GPU1, GPU2, NIC1, NIC2, and the accelerator, but not in the SSD.

[0113] The interaction between the Translation Agent (TA) and the Address Translation Cache (ATC) ultimately forms the Address Translation Service (ATS). For example, when the ATC of a PCIe device cannot complete address mapping, the PCIe device containing the ATC needs to send an ATS Request to the TA. After completing the address mapping, the TA returns the result to the PCIe device, thus the ATC in the PCIe device caches the address mapping entry. In this embodiment, the TA and ATC can not only perform complete address translation interaction, but also further perform functions such as address invalidation and page table creation. For example, when a memory address is changed in the TA, an ATS InvalidateRequest is sent to the PCIe device, which cancels the mapping entry and returns the result to the TA.

[0114] It's important to note that in an ATS (Address Translate System), PCIe devices are typically categorized into devices implementing ATC (Address Translate) functionality and devices implementing TA (Text Translate) functionality, based on their ability to initiate requests or complete responses. Devices implementing ATC are usually the initiators of translation or page table requests, while devices implementing TA, or the device containing the RC (Responding Device), are usually the responders. Alternatively, devices implementing TA are typically the initiators of invalidation requests, while devices implementing ATC are the responders of invalidation requests. For example, the ATC initiates an address translation request to the TA. After translation, the TA returns the corresponding address mapping to the ATC. The ATC locally caches these address mappings, so when accessing the memory space of the device containing the TA, such as the CPU (e.g., DMA), can directly obtain the corresponding physical address from the local ATC, thus directly accessing the CPU's memory space via the physical address. When some address mappings cached locally by the ATC in the TA need to be invalidated, the TA will initiate an invalidation request to the ATC. The ATC invalidates the corresponding locally cached mappings and returns an invalidation response to the TA.

[0115] For ease of description, in the following embodiments, the term "ATC side" or "ATC" will be used to refer to devices that implement the ATC function; similarly, the term "TA side" or "TA" will be used to refer to devices that implement the TA function, and this will not be elaborated further. It is understood that some devices in a bus system can also have both TA and ATC capabilities, that is, in different ATSs, they can use their TA capability or ATC capability as different roles in the ATS. This application does not specifically limit this aspect.

[0116] It should also be noted that the first device in this application can be considered as a device that implements ATC function or has ATC capability, and the second device can be considered as a device that implements TA function or has TA capability. That is, the first device in this application can be any of the aforementioned... Figure 1 or Figure 2 The GPU, network card, accelerator, etc. that implement ATC functionality are mentioned above. The second device in this application can be one of the aforementioned... Figure 1 or Figure 2 The host that implements the TA function.

[0117] The bus communication method in this application embodiment can be applied to, but is not limited to, the methods described above. Figure 1 or Figure 2 The bus system architecture in the example. For instance, the bus communication method provided in this application, when applied to the above... Figure 1 In a PCIe bus system, the PCIe bus system may include multiple PCIe devices, among which one or more first devices implementing ATC functionality and one or more second devices implementing TA functionality may be included. It is understood that when the bus communication method provided in this application is applied to other types of bus systems, the first or second device in this application may be a device with ATC capability or a device with TA capability in the corresponding system; that is, the first and second devices in this application include, but are not limited to, the aforementioned... Figure 1 or Figure 2 The equipment involved.

[0118] Based on the above Figure 1 or Figure 2 The provided bus system architecture and the functions of each device in the system architecture, combined with the bus communication method provided in this application, provide a specific analysis and solution to the technical problems raised in this application.

[0119] See Figure 3A , Figure 3A This is a flowchart illustrating a bus communication method provided in an embodiment of this application. This method can be applied to the above-mentioned... Figure 1 or Figure 2In the PCIe bus system described herein, bus system 10 can be used to support and execute... Figure 3A The method flow shown consists of steps S301-S304. The following will refer to the appendix... Figure 3A The method is described from the interaction side of the first and second devices in the bus system 10. It may include steps S301-S304, and optionally, steps S305-S306.

[0120] Step S301: The first device sends an address translation request to the second device.

[0121] Specifically, the bus communication method in this embodiment is applied to a bus system, which includes multiple devices interconnected via a bus. These interconnected devices include at least a first device and a second device. The first device can be understood as a node device that implements or has ATC functionality during bus communication (hereinafter referred to as ATC for ease of description), and the second device can be understood as a node device that implements or has TA functionality during bus communication (hereinafter referred to as TA for ease of description). When the ATC informs itself via software that it needs to access the TA's address space, since this address space is a virtual address space, it needs to be translated into one or more corresponding physical address spaces during the access process to enable the ATC to truly access the TA's memory space. Specifically, when the ATC needs to access a segment of virtual address space in the TA, the ATC initiates an address translation request to the TA. After translating, the TA returns the corresponding address mapping to the ATC. The ATC caches these address mappings locally, allowing it to directly obtain the corresponding physical address from its local cache when accessing the TA's virtual address space (such as the CPU's memory space DMA), thus directly accessing the CPU's memory space through the physical address. The address translation request includes a first identifier identifying the request and the virtual address of the virtual address space to be translated. The virtual address space to be translated includes one or more Minimum Translation Units (STUs). The first identifier is carried by the TA in the feedback translation response message, allowing the ATC to identify which address translation request the translation response message corresponds to by recognizing the identifier in the message. The Minimum Translation Unit (STU) refers to a contiguous segment of virtual address space, where the translation response side uses this STU as the smallest translation unit.

[0122] Optionally, in this embodiment, the message length of the address translation request is not limited, and its message length field value can reach the length of a general data read request, that is, it can be longer than the prior art. Therefore, the size of the virtual address space to be translated carried by a translation request in this embodiment can be expanded, thereby greatly reducing the message overhead of the address translation request.

[0123] In one possible implementation, the address translation request further includes usage information of the virtual address space, which includes one or more of the following: usage frequency, access frequency, or regional expectation. Regional expectation can be considered as the strength of the first device's desire to cache the data corresponding to the virtual address space locally. That is, based on whether the data corresponding to the virtual address space needs to be used frequently, the device decides whether to cache the data locally, rather than retrieving it from other memory such as Double Data Rate (DDR) each time. In this embodiment of the application, the address translation request initiated by the translation requesting side (i.e., the first device, such as the ATC side) to the translation response side (i.e., the second device, such as the TA side) may also carry the usage information of the virtual address space to be translated by the ATC side, such as the usage frequency, access frequency, and whether the virtual address space to be accessed needs to be cached locally, so that the TA side can optimize these virtual address spaces to be translated based on the usage information. For example, the TA side may use this usage information to determine whether the page table mapping corresponding to this virtual address space needs to be cached to the CPU's MMU.

[0124] Step S302: In response to the address translation request, the second device generates one or more translation response messages.

[0125] Specifically, each translation response message also needs to carry a first identifier that uniquely identifies the address translation request, the target location information of one or more target STUs in the virtual address space, and the target physical address after translating the virtual address of the one or more target STUs. Optionally, the target location information includes the base address of the first target STU among the one or more target STUs, and the size of the address space of the one or more target STUs. That is, the target location information added to the translation response message can specifically be the base address of the first STU to be translated plus the size of the address space to be translated, thereby indicating to the translation request side the specific location of the STU currently being translated in the original virtual address space to be translated in the translation response message. In this embodiment, during the process of requesting the translation of a virtual address into a physical address, by carrying the identifier of the corresponding address translation request and adding the location information of the currently translated address space within the original requested address space in each translation response message, the requesting translation side can accurately identify which original requested address space and which segment within that address space is being translated by any given translation response message. Therefore, regardless of the order in which the translation response messages are fed back or received, it will not affect the requesting translation side's reconstruction of the translation result. That is, this embodiment is not affected or constrained by the order of translation response message feedback; the translation response messages can be fed back out of order, sequentially, or in parallel, thereby avoiding the problems of inflexibility, time delay, and low efficiency caused by the prior art's requirement to strictly follow a predetermined sequential feedback order.

[0126] In one possible implementation, each translation response message further includes one or more of the following: memory attributes of the one or more target STUs, first indication information, or translation extension information; wherein, the memory attributes include whether the target STU is cacheable or the size of the access latency corresponding to the target STU, and the first indication information is used to indicate whether the current translation response message is the last response message among the one or more translation response messages. In this embodiment, the translation response message fed back from the translation response side (i.e., the second device, such as the TA side) to the translation request side (i.e., the first device, such as the ATC side) may also carry some memory attribute information of the currently translated virtual address space and translation extension information of the translation response message, so that the translation request side (such as the ATC side) can quickly learn some characteristics of these virtual address spaces to be translated and optimize the access operation for the virtual address space based on these characteristics.

[0127] Optionally, the address space translated by the one or more translation response messages generated by the second device in response to the address translation request may be all or part of the address space to be translated as stated in the address translation request. This is because, during the translation process, the second device may not find the virtual address and physical address mapping relationship for the address space segment to be translated, or the translation may fail for other reasons. Therefore, the address translation response message received by the first device may only correspond to a portion of the virtual address space to be translated. In this case, for the virtual address space portion for which the response failed in the address translation request, the first device can resend a page table request carrying virtual address information to the second device. The second device returns one or more page table response messages to the first device, allowing the first device to directly obtain the translation result or re-initiate the address translation request to obtain the translation result. For specific embodiments of this part of the page table request and response, please refer to the descriptions of subsequent steps S308-S311, which will not be described in detail here.

[0128] In step S302 above, after the second device has processed all or part of the address space requested for translation by the address translation request, it can return the corresponding translation result. The following example, using the interaction between the TA in the second device and the ATC in the first device, illustrates how the second device in this embodiment specifically responds to the address translation request.

[0129] 1) TA generates translation results and returns them to ATC via translation response messages. Each translation request can correspond to multiple translation response messages.

[0130] 2) For a translation response message to the same address translation request, the information it needs to carry includes: information that can uniquely identify which address translation request this translation response message corresponds to, the number of translation results carried in this response message, the STU space from which the untranslated address space corresponding to the first translation result carried in this response message starts from the address space requested for translation in the translation request, the size of the translation address space corresponding to each translation result, the attributes of the corresponding translation address space, whether this translation response message is the last translation response message for the corresponding translation request, whether there is an indication of carrying translation extension information, and if there is extended translation information, the corresponding translation extension information should be included.

[0131] 3) The untranslated address spaces corresponding to the translation results carried in a translation response message should be contiguous; a translation response message should also contain an indication of which STU space the untranslated address space corresponding to its first translation result starts from in the translation request; a translation response message should have a bit field indicating whether the current message is the last translation response message for the corresponding translation request, and if it is the last, it should also indicate the number of all translation response messages corresponding to this translation request.

[0132] like Figure 3B As shown, Figure 3B This is a schematic diagram illustrating the implementation structure of a translation response message provided in an embodiment of this application. The Start STU field indicates which STU segment of the untranslated address space of the corresponding TransReq is being translated into the first 64 bits of data carried in this TransCpl message (corresponding to the first translation result). Its encoding starts from 0: Start STU = 0 indicates that the first 64 bits of data carried in this TransCpl message is being translated into the first STU segment of the untranslated address space of the corresponding TransReq; Start STU = 1 indicates that the first 64 bits of data carried in this TransCpl message is being translated into the second STU segment of the untranslated address space of the corresponding TransReq, and so on. When TransCpl is a completion message without data, this field is reserved, and TA should be filled with 0. In this case, ATC does not care about the specific value of this field. The L field indicates whether the current TransCpl is the last translation response message corresponding to the translation request. The Cpl_Num field indicates the total number of translation response messages for the address translation request to which the current TransCpl belongs. Its value is equal to the actual number of messages minus 1. When its value is 0, it represents the maximum number of messages. Only the Cpl_Num value corresponding to the response message with L field set to 1 is (required) accurate.

[0133] 4) Each translation result also includes the memory attributes of the corresponding translation's address space, such as whether this space is cacheable, and whether the corresponding access latency is particularly large / small, etc. Figure 3C As shown, Figure 3C This is a schematic diagram illustrating another implementation structure of the translated response message provided in this application embodiment.

[0134] The memory attribute (MemAttr) is used to indicate the memory attribute of the corresponding translation address space. Its specific encoding meaning is related to the TA system, or it can be encoded to indicate a more abstract meaning (e.g., establishing a common memory space model). Table 1 below shows one possible encoding meaning:

[0135] Table 1

[0136]

[0137]

[0138] In Table 1 above, the meanings of other fields can remain consistent with existing ATS technology, and the way the size is indicated can also remain the same.

[0139] Step S303: The second device sends one or more translation response messages back to the first device.

[0140] Specifically, the second device can provide feedback by immediately sending a translation response message upon generating one. That is, the second device can send translation response messages to the first device in batches according to the actual translation progress, and each batch can include one or more translation response messages. Furthermore, in the design of the information carried in the translation response messages in this embodiment, the original untranslated virtual addresses corresponding to the translated physical addresses in any two different translation response messages can be non-contiguous. The requesting translation side can also receive translation response messages in batches, and each batch can contain one or more, unlike the prior art where a maximum of two separate responses can be sent, and only one response message can be sent at a time. This achieves the effect of reducing the latency of translation response message feedback and improving bandwidth utilization. In other words, the TA in the second device can expand its design space according to the translation completion response mechanism, and reduce the translation request completion latency of the ATC in the first device, thereby improving the bus's transmission utilization rate for translation requests (the size of the obtained translation space / the number of translation requests).

[0141] Step S304: For each of the translation response messages, the first device initiates a read / write access operation to the target physical address based on the first identifier and the target location information.

[0142] Specifically, after receiving a translation response message, the first device can reconstruct the specific virtual address of the address space segment translated in the current translation response message within the original address space to be translated, based on the first identifier and target location information carried in each translation response message. Then, based on this determined virtual address, it can determine the specific read / write access operation for the translated address space segment and ultimately initiate the specific read / write access operation to the corresponding physical address. Further, the first device can first determine the virtual address of the original virtual address space to be translated corresponding to the translation response message based on the first identifier in the translation response message. Based on this virtual address and the target location information, it can determine the virtual address of the address space segment (i.e., one or more target STUs) translated in the current translation response message. Based on the specific virtual address of the one or more target STUs, it can further determine the specific read / write access operation corresponding to the virtual address of the one or more target STUs, and ultimately initiate the read / write access operation to the corresponding physical address. Furthermore, once the requesting translation side receives the translation response message, it can perform data read and write access operations (such as DMA operations) based on the physical address in the received translation response message. This further shortens the delay for the requesting translation side to wait for the translation result and allows for more efficient and full utilization of bus bandwidth.

[0143] This application embodiment defines a new address translation request and translation completion response, which enables an address translation request to request a larger address space, and the translation completion response can be returned to the requester in batches and out of order. Furthermore, it defines the translation extension information carried in the translation response message, which can carry more system information of the system where the TA is located to the requester, thus solving the above-mentioned shortcomings of the prior art in (1), (2) and (3).

[0144] In one possible implementation, at least one of the one or more translation response messages further includes the total number of translation response messages corresponding to the address translation request; the method further includes: the second device determining, based on the number of received translation response messages and the total number of translation response messages, whether the translation response message corresponding to the address translation request has been completely received; if the reception is complete, the marker resource corresponding to the address translation request is released or reused. Optionally, the TA side may also carry an indication of whether the current translation response message is the last message among the one or more translation response messages in the last translation response message sent. In this embodiment of the application, the translation response message fed back by the translation response side (i.e., the second device, such as the TA side) to the translation request side (i.e., the first device, such as the ATC side) may also carry the total number of translation response messages corresponding to the address translation request, or an indication of whether the last response message carried in the last sent response message is the last response message, so that the translation request side can decide whether to reuse or reclaim the marker resource corresponding to the address translation request based on the information, so as to improve resource utilization.

[0145] In step S304 above, after the ATC in the second device receives all the translation response messages for the address translation request, it can determine which address spaces requested for translation have received translation results based on the information carried in the messages, and perform access operations on the corresponding addresses based on the translation results. The following will, in conjunction with specific virtual address spaces and translated physical address spaces, exemplarily illustrate how the TA in the first device in this application performs operations to access the physical address space of the virtual address space to be accessed based on the translation response messages.

[0146] 1) such as Figure 3D As shown, Figure 3D This is a schematic diagram of a physical address space after virtual address space translation provided in an embodiment of this application. TA receives an address translation request from ATC, and the virtual address space to be translated is 32 STUs in size.

[0147] 2) The TA begins processing this address translation request. Within a certain timeframe, it can return a translation response message to the ATC. Based on its own microarchitecture and design, the TA decides to return the first translation response message to the ATC. The target location information carried in this first translation response message corresponds to an untranslated address space starting from the second STU segment, with a size of 1 STU. Therefore, the Start STU value of the translation response message it sends is 0, the L field value is 0, the length field value is 2 (DWs), and the 64 bits of data carried in the message correspond to the translation result and the corresponding translation size.

[0148] 3) Once ATC receives the first translation response message returned by TA, it can begin to use the information in this translation response message to directly access the physical address space of the response.

[0149] 4) At a certain point in time, the TA, based on its own microarchitecture and design, decides that it can return a second translation response message to the ATC. The untranslated address space corresponding to this translation response message is a continuous space of 8 STU size starting from the 5th STU. Therefore, the Start STU value of the translation response message sent by the TA is 4, the L field value is 0, the length field value is 4 (DWs), and the message carries two 64-bit data groups representing two translation results. The untranslated address space corresponding to the first translation result is from STU4 to STU7; the untranslated address space corresponding to the second is from STU8 to STU11.

[0150] 5) At a certain point in time, the TA, based on its own microarchitecture and design, decides that it can return a third translation response message to the ATC. The untranslated address space corresponding to this translation response message is a continuous space of 1 STU size starting from the 3rd STU. Therefore, the Start STU value of the translation response message sent by the TA is 2, the value of the L field is 0, the value of the length field is 2 (DWs), and the 64-bit data group carried in the message represents one translation result.

[0151] 6) At a certain point in time, the Translator (TA), based on its own microarchitecture and design, decides to terminate the request. The untranslated address space corresponding to the translation response message that the TA can still return is the address space of the last STU. The remaining untranslated space will not be processed and no results will be returned. Therefore, the Start STU value of the translation response message sent by the TA is 31, the L field value is 1, the length field value is 2 (DWs), the 64-bit data group carried in the message represents one translation result, and the Cpl_Num value is 3 (indicating that this translation request has a total of 4 translation response messages).

[0152] 7) All translation response messages can be out of order, so ATC may receive the last translation response message first. At this time, ATC receives a translation response message with the L field value of 1, finds that its Cpl_Num is 3, and since it has only received two translation response messages so far, it knows that there are still two translation response messages on the way that need to be received.

[0153] 8) The ATC receives the remaining two translation response messages for the translation request, and finally knows that the corresponding translation request has ended and all translation response messages have been received. It then releases / reuses the tags and other resources used in the corresponding request.

[0154] In the example above, TA can also translate all untranslated address spaces and return these translation results in batches and out of order using multiple translation response messages. For example... Figure 3E As shown, Figure 3E This is a schematic diagram illustrating how a translation request, as provided in an embodiment of this application, receives corresponding translation result responses for all untranslated address spaces. Figure 3E In the example, ATC will eventually collect all translation response messages before considering the corresponding translation request complete, and its corresponding tags and other resources can be released / reused.

[0155] This application provides a bus communication design scheme, particularly relating to the design of an address translation mechanism in bus communication. This includes redefining the address translation request and response mechanism to improve address translation efficiency and bus bandwidth utilization. Specifically, during the process of requesting the translation of a virtual address into a physical address, each translation response message from the translation response side carries an identifier for its corresponding address translation request and adds target location information not present in existing translation response messages. This target location information refers to the position of the currently translated address segment within the address space to be translated. Based on this information, the translation request side can accurately identify which address segment in which address space is being translated by any given translation response message. Therefore, regardless of the order in which the translation response side sends back the translation response messages, it will not affect the translation request side's ability to reconstruct the translation result, thus enabling out-of-order feedback of translation response messages. Based on the characteristics of this out-of-order translation response message, the translation response side can send back translation response messages in batches and out of order (i.e., the first message to be translated can be sent back first) according to the actual translation progress. Each batch can contain multiple translation response messages, avoiding the problem in existing technologies where the translation response messages do not carry any position indication information and therefore can only be sent back in a predetermined order (such as the order based on the continuity of virtual addresses), resulting in untranslated messages delaying the feedback progress of translated messages. Therefore, this embodiment can effectively improve the efficiency and parallelism of translation responses, while also increasing the utilization of bus bandwidth. Furthermore, once the translation request side receives the translation response message, it can perform data read / write access operations (e.g., Direct Memory Access (DMA) operations) based on the received message, thus greatly reducing the latency of access operations by the translation request side. This further improves the overall performance of bus communication and makes fuller and more efficient use of bus bandwidth. In other words, because the embodiments of this application add the location information of the smallest translation unit (STU) of the current translation to the translation response message, there is no constraint on the feedback order between translation response messages. Therefore, the translation response messages can be fed back out of order, in parallel, or serially. Thus, the untranslated virtual addresses corresponding to the translated physical addresses in any two translation response messages can be discontinuous. This avoids the problems of inflexible design, extended translation time, low translation efficiency, and low bandwidth utilization caused by the existing technology, which can only perform order-preserving feedback in a strict order.

[0156] Based on the above, in this embodiment, from the perspective of the translation response side (such as the Translation Agent (TA)), since the ordering requirement of bus routing is removed and out-of-order feedback of translation response messages is implemented, the TA can have more flexible design space, maximize the utilization of bus bandwidth, obtain a smaller bus routing latency, and reduce the design difficulty of bus support for address translation services. From the perspective of the translation request side (such as the Address Translation Cache (ATC)), since the translation response side implements out-of-order feedback of translation response messages, the latency of ATC receiving translation feedback results will be smaller, thus the efficiency of subsequent access operations will be higher, and the utilization rate of bus bandwidth will also be higher. In summary, compared with the bus mechanism in the prior art, the embodiments of this application realize that more than two translation response messages can be fed back for one address translation request (the prior art stipulates a maximum of no more than two), and these translation response messages can be transmitted out of order in the bus routing. Different translation response messages can be transmitted in parallel or serially. That is, while ensuring the high completion rate of address translation requests (such as the total size of the translated address space / the size of the untranslated address space requested by the address translation request), the utilization rate of bus bandwidth is further improved.

[0157] Based on the above design of the address translation mechanism in bus communication, this application further designs an address invalidation mechanism in bus communication, specifically including invalidation requests and invalidation responses in the invalidation mechanism. The bus communication method provided in this application will be specifically explained below by how the second device 10 requests invalidation of the invalidation unit to be invalidated; and how the first device 103 invalidates the corresponding unit according to the invalidation request and sends an invalidation response message back to the second device. Therefore, after step S304 is executed, the following steps S305-S307 may also be included:

[0158] Step S305: The second device sends an invalidation request to the first device.

[0159] Specifically, the invalidation request includes a second identifier identifying the invalidation request and virtual addresses of multiple invalidation units to be invalidated, wherein the multiple invalidation units correspond to multiple discrete virtual address spaces to be invalidated. This application provides a bus communication design scheme, which, in addition to the design of the address translation mechanism in the aforementioned bus communication, further designs the address invalidation mechanism in bus communication, including redefining the address invalidation request mechanism to improve the performance of invalidation commands. Specifically, by defining an invalidation request that can carry invalidation information for multiple non-contiguous invalid address space segments, the transmission efficiency of invalidation commands is improved, thereby improving the overall performance of the system in executing invalidation commands. Furthermore, since an invalidation request command can carry invalidation information for multiple non-contiguous invalid address space segments, the bandwidth utilization of invalidation commands in the bus is greatly improved.

[0160] Step S306: In response to the invalidation request, the first device invalidates the virtual address and physical address mapping relationship of the plurality of invalidation units.

[0161] Specifically, in response to the invalidation request, the invalidation request response side invalidates the virtual address and physical address mapping relationship that may carry multiple non-contiguous invalid address space segments in the invalidation request command, for example, by deleting the mapping relationship locally. In one possible implementation, invalidation refers to the first device side deleting the virtual address and physical address mapping relationship already stored locally. It is understood that other specific methods can also be used to invalidate the mapping relationship, and this application embodiment does not specifically limit this approach.

[0162] Step S307: The first device generates one or more invalidation response messages.

[0163] Specifically, each invalidation response message includes the second identifier and an invalidation unit number, where the invalidation unit number is the number of the currently invalidated invalidation unit among the plurality of invalidation units. In this way, the second device can determine the specific virtual address of the invalidation unit invalidated by the current invalidation response message based on the second identifier and the corresponding invalidation unit code. More specifically, the second device determines the invalidation request corresponding to the second identifier, further determines the virtual addresses of the plurality of invalidation units to be invalidated corresponding to the invalidation request, and further determines the specific virtual address corresponding to the currently invalidated invalidation unit based on the invalidation unit code of the currently invalidated invalidation unit among the plurality of invalidation units to be invalidated in the invalidation response message. This allows the second device to ultimately know which virtual addresses have been successfully invalidated based on the above information. This application provides a bus communication design scheme, which, in addition to involving the design of the address translation mechanism in the above-mentioned bus communication, further designs the address invalidation mechanism in bus communication, including redefining the address invalidation request and response mechanism to improve the performance of invalidation commands. Specifically, by defining a mechanism where an invalidation request can carry invalidation information for multiple non-contiguous invalid address space segments, and the invalidation completion status of the corresponding invalid address space segments can be returned to the invalidation request side (such as the TA side) in batches with multiple invalidation response messages, the transmission efficiency of invalidation commands and the parallelism of invalidation execution are improved, thereby improving the overall performance of the system in executing invalidation commands. Furthermore, since an invalidation request can carry invalidation information for multiple non-contiguous invalid address space segments, the bandwidth utilization of invalidation commands on the bus is greatly improved; and since invalidation response messages can be returned to the invalidation request side (such as the TA side) in batches with invalidation completion status, the problem of increased latency in invalidation command execution caused by the need to aggregate multiple invalidation response messages is avoided.

[0164] In one possible implementation, at least one of the one or more invalidation response messages further includes the total number of invalidation response messages corresponding to the invalidation request; the method further includes: the second device determining whether the invalidation response messages corresponding to the invalidation request have been received completely based on the number of received invalidation response messages and the total number of invalidation response messages; if the reception is complete, the marked resource corresponding to the invalidation request is released or reused. In this embodiment, the invalidation response message fed back from the invalidation response side (i.e., the first device, such as the ATC side) to the invalidation request side (i.e., the second device, such as the TA side) may also carry the total number of invalidation response messages corresponding to the invalidation request, so that the invalidation request side can decide whether to reuse or reclaim the marked resource that has been invalidated based on this information, thereby improving resource utilization.

[0165] This application embodiment solves the above-mentioned shortcomings of the prior art by defining a new invalidation request, which allows a single invalidation request message to carry a command to invalidate the translation of multiple non-contiguous address space segments. (4)

[0166] In step S305 above, when the TA in the second device needs to invalidate a portion of the mapping relationship between virtual addresses and physical addresses, it can send a request to the ATC in the first device to invalidate the relevant mapping relationship stored in the first device. The following will exemplarily illustrate how the ATC in the first device in this application specifically invalidates invalidation units based on the invalidation request sent by the TA in the second device.

[0167] 1) The information in a voiding request message sent by a TA includes: the number of voiding commands (voiding units) used to void the address space, the untranslated base address of the voided address space corresponding to each voiding command, and the size of the address space to be voided. For example... Figure 4A As shown, Figure 4A This is a schematic diagram of the data structure of an invalidation request message provided in an embodiment of this application. For example... Figure 4AAs shown in the figure, the field marked XX is the same as the prior art. The value of the message length field indicates how many invalidation units there are, and its value must be an even number. Each invalidation unit represents the invalidation of a small segment of address space. Among them, the indication of the size of the invalidation space corresponding to the invalidation unit can be multiple. Here is an example of one indication method: each invalidation unit has an S field. When the S field is set to 1, it means that the size of the invalidation space of the current invalidation unit is greater than 4096 bytes, otherwise it is equal to 4096 bytes; if S = 1, then the Untranslated Address

[12] indicates whether the size of the current invalidated untranslated address space is greater than 8192 bytes. If

[12] is set to 1, it means that the size of the current invalidation space of the current invalidation unit is greater than 8192 bytes, otherwise it is equal to 8192 bytes. And so on, such as Figure 4B As shown, Figure 4B This is a schematic diagram illustrating the spatial size of a translation result, provided as an embodiment of this application.

[0168] 2) Upon receiving an invalidation request message, the ATC begins invalidating the corresponding address space segments based on the invalidation unit carried in the message. The device can flexibly return different invalidation response messages to the TA in batches, targeting different invalidation units, according to the actual business scenario and its own design. The invalidation response message returned by the ATC must include: a unique identifier of which invalidation request and invalidation unit this response message corresponds to, and the total number of invalidation response messages for that invalidation request and invalidation unit. Alternatively, the ATC can return the same invalidation completion message for all invalidation units; in this case, this must be indicated in the message header.

[0169] like Figure 4C As shown, Figure 4C This is a schematic diagram of the format of an invalidation response message provided in an embodiment of this application. The fields marked XX are represented in the same way as in the prior art. The CC field indicates how many invalidation response messages there are in total for all invalidation units / a single invalidation unit corresponding to the current invalidation response. When its value is 0, it means that the number of corresponding response messages should be a maximum of 256. When the All field is 1, it means that all invalidation units of the invalidation request corresponding to the current invalidation response message share the same invalidation response message. In this case, the CC field indicates how many invalidation response messages there are in total for all invalidation units of the corresponding invalidation request. InvUnit indicates which invalidation unit of the invalidation request the current invalidation response message corresponds to. This field is only valid when the All field is 0.

[0170] 3) After receiving the corresponding invalidation completion response message, the TA can accurately determine which invalidation request and which invalidation unit the current invalidation response message corresponds to. In this way, the TA can accurately determine which address range has been invalidated.

[0171] Based on the above design of the address translation mechanism in bus communication, this application further designs the page table establishment mechanism in bus communication, specifically including page table request and page table response in the page table establishment mechanism. The bus communication method provided in this application will be specifically explained below by how the first device 10 requests a page table for a currently unreachable missing page; and how the first device 103 establishes the corresponding page table based on the page table request and feeds back the page table establishment result to the second device. Therefore, before or after the execution of step S304, the following steps S308-S311 may also be included:

[0172] Step S308: The first device sends a page table request to the second device.

[0173] Specifically, the page table request includes the page table request code in its respective page table request group (PRG) and the virtual addresses of multiple page table request units to be requested, wherein the multiple page table request units correspond to multiple non-contiguous page table spaces. This application provides a bus communication design scheme. Besides involving the design of the address translation mechanism in the aforementioned bus communication, it further designs the page table request mechanism in bus communication, including redefining the page table request mechanism to improve the performance of page table request commands. Specifically, it defines that a page table request (such as a command / message) can carry information of multiple page table request units, correspondingly requesting the establishment of multiple non-contiguous page table spaces from the system. That is, since a page table request message transmitted on the bus can carry information of multiple page table request units, the overhead of page table request commands can be reduced, the bandwidth utilization of the bus can be improved, and the transmission efficiency of page table request commands and the bandwidth utilization of the bus can be increased.

[0174] Optionally, in the embodiments described in steps S301-S305 above, if the second device fails to find the virtual address and physical address mapping relationship of the address space segment to be translated during the translation process, or if the translation fails for other reasons, the address translation response message received by the first device may only correspond to a portion of the virtual address space to be translated. In this case, for the virtual address space portion that failed to respond in the address translation request, the first device can issue the page table request described in step S308 above, that is, re-issue a page table request carrying virtual address and other information to the second device, so that the second device can subsequently return one or more page table response messages to the first device, thereby allowing the first device to directly obtain the translation result or re-initiate the address translation request to obtain the translation result.

[0175] In one possible implementation, the page table request further includes one or more of the following: page table space size, read / write permissions, expected memory attributes, or usage prompts for each page table request unit. Expected memory attributes refer to the memory attributes that the page table requesting side expects the page table space corresponding to the requested page table request unit to possess. Specific details regarding memory attributes can be found in Table 1, which describes the memory attributes of the address space to be translated; these will not be repeated here. In this embodiment, the page table request may also carry expected information about the page table space requested by the page table requesting side (e.g., the ATC side), such as the expected page table space size, the expected memory model attributes, and system attributes. From the ATC side's perspective, this provides an interface for the ATC side to submit more user expectation information when requesting page tables from the page table response side (e.g., the TA side or the system side). This allows the TA to create page tables for the corresponding ATC based on more precise user information, enabling the ATC to optimize its DMA behavior based on the memory model attributes of the corresponding space, thus expanding the ATC's design space. From the perspective of the page table response side (such as the TA side), the TA has the opportunity to adjust its page table creation strategy and the attributes of the page tables based on this expectation information. This greatly expands the design space of the TA / system, making the page tables created by the TA / system for the ATC more in line with the ATC's expectations. This can improve the overall page table management efficiency and enhance the overall system performance. For example, based on the size and usage of the page table request unit that the ATC wants to request, the TA / system can determine the size (granularity) of the corresponding page table and whether the corresponding page table can be pre-loaded into the cache.

[0176] In step S308 above, after requesting address translation, the TA in the first device finds that some virtual address requests have failed, and therefore needs to re-establish the page table for these virtual address information. The following will exemplarily illustrate how the TA in the first device initiates a page table request in this application.

[0177] 1) When an ATC initiates a page table request, the message / transaction it sends should include the requested page table address, the corresponding page table space size, the read / write permissions for the corresponding page table space, the memory attributes the ATC expects for this page table space, and usage prompts from the ATC regarding this space. A page table request message / transaction can contain multiple page tables to be requested (page table request units), and the encoding of the current page table request message / transaction among all page table requests under the current PRG. This allows the TA to accurately determine how many page table requests will occur under the current PRG in the event of out-of-order transmission (this number is equal to the Page Num field value of the page table request with an L field of 1 plus 1). Each page table to be requested contains the above information.

[0178] 2) such as Figure 5A As shown, Figure 5A This is a schematic diagram of a page table response message format with page table information provided in an embodiment of this application. The XXXX fields have the same meaning as in the prior art. The length field of the message indicates how many sets of page tables to be requested are carried in the current page table request message, called page table request units, with each set consisting of 2 DWs (64 bits). The SSV field indicates whether the current page table request message carries a PASID.

[0179] 3) The Page Num field in the Page Table Request header is 9 bits wide, representing the encoding of the current page table request among all page table requests under the same PRG. When the TA determines that multiple page table response messages need to be returned in batches for the page table requests under the current PRG, the corresponding page table response message needs to carry this field value to indicate which page table request the current response corresponds to.

[0180] 4) In each page table request unit, Exe and Pri are the same as Exe and Priv in the prior art, respectively indicating whether the requested page table is an executable space and whether it requires special privileges. The Hint field indicates how ATC is most likely to use the page table space shown in the current page table request unit. Table 2 shows one of the possible encoding methods.

[0181] Table 2

[0182]

[0183]

[0184] In Table 2 above, the Memory Attribute (MemAttr) field indicates what memory attributes the ATC expects from the page table space represented by the current page table requesting unit, with the specific encoding being the same as shown in Table 1. The S field indicates whether the size of the page table space the current page table requesting unit wants to request is greater than 4096 bytes. It, along with the page table address field, indicates the size of the page table space the current page table requesting unit wants to request. For example... Figure 5B As shown, Figure 5B The following is a schematic diagram of the page table space size provided in the embodiments of this application. The specific method is as follows: When the S field is set to 1, it indicates that the size of the invalid space of the current invalidation unit is greater than 4096 bytes, otherwise it is equal to 4096 bytes; if S = 1, then UntranslatedAddress

[12] indicates whether the size of the current invalidated untranslated address space is greater than 8192 bytes. If

[12] is set to 1, it indicates that the size of the current invalidation unit is greater than 8192 bytes, otherwise it is equal to 8192 bytes, and so on.

[0185] Step S309: In response to the page table request, the second device generates one or more page table response messages.

[0186] Specifically, each page table response message includes the page table request code and the mapping relationship between the virtual address and physical address of the currently established page table request unit, or each page table response message includes the page table request code; the second device sends one or more page table response messages back to the first device. That is, in some possible embodiments, the page table response message contains both the page table request code and the established address mapping relationship; in other possible embodiments, the page table response message only includes the page table request code and does not include the address mapping relationship. When the page table response message carries the address mapping relationship, the first device can directly obtain the address mapping relationship and directly initiate an access operation to the corresponding physical address. When the page table response message does not carry the address mapping relationship, the first device may not be able to obtain the corresponding address mapping relationship this time and needs to initiate an address translation request to the second device again to request the translation result of the corresponding virtual address. This application provides a bus communication design scheme. Besides the address translation mechanism design mentioned above, it further designs the page table request and response mechanism in bus communication, including redefining the page table request and response mechanism to improve the performance of page table request and response commands. Specifically, it defines that a page table request (such as a command / message) can carry information about multiple page table request units, correspondingly requesting the establishment of multiple non-contiguous page table spaces from the system. Furthermore, it defines that multiple page table response messages can correspond to the same PRG, and the page table response side (such as the TA side) can send page table response messages back to the page table request side (such as the ATC side) in batches without order requirements. Optionally, these page table response messages can directly carry information about successfully established page tables, so that after the first address translation request by the ATC results in a page fault, a second page table request can be issued to obtain the address mapping result, reducing the need for sending and responding to a second address translation request compared to existing technologies. This application embodiment reduces the steps required by existing Address Translation Service (ATS) technology after a page fault during the first page table request, from obtaining the required address mapping result again, thereby improving the system's memory access performance. It is understood that when each page table response message only includes the page table request code and not the address mapping relationship, ATC needs to issue a corresponding address translation request after issuing the page table request to further request the untranslated virtual address. In summary, the page table response message in this application embodiment includes two implementation methods: one is a method that only requires initiating a page table request once after a page fault, and the other is a method that requires both a page table request and an address translation request after a page fault, thus simultaneously supporting both page table response methods.

[0187] In one possible implementation, each page table response message further includes one or more of the following: the base address of the page table space corresponding to the established page table request unit, the page table space size, the memory model attributes of the page table space, read / write permissions, and system attributes. It is understood that the above-mentioned one or more pieces of information carried in the page table response messages in this embodiment are based on the mapping relationship between the virtual address and physical address of the established page table request unit carried in the page table response message returned by the second device in step S309. In this embodiment, the page table response message also carries one or more of the following: the base address of the page table space corresponding to the currently established page table request unit, the size of the page table space, the memory model attributes of the page table space, read / write permissions, and system attributes. This allows the page table response side (such as the TA / system side) to return the attributes of the established page table, and allows the page table request side (such as the ATC side) to obtain more page table attributes. This enables the ATC side to optimize its use of the page table space based on the memory model attributes of the corresponding page table space. For example, it can optimize the subsequent DMA behavior of the ATC side, thereby improving the overall performance of the system and expanding the design space of the ATC.

[0188] In one possible implementation, at least one of the one or more page table response messages further includes the total number of page table response messages corresponding to the page table request group (PRG); the method further includes: the second device determining whether the page table response messages corresponding to the page table request group (PRG) have been received completely based on the total number of page table response messages and the number of page table response messages received; if the reception is complete, the marked resource corresponding to the page table request group (PRG) is released or reused. In this embodiment, the page table response message fed back from the page table response side (i.e., the second device, such as the TA side) to the page table request side (i.e., the first device, such as the ATC side) may also carry the total number of page table response messages corresponding to the page table request group (PRG) so that the page table request side can decide whether to reuse or reclaim the marked resource for which page table establishment has been completed based on this information, thereby improving resource utilization.

[0189] In step S309 above, after requesting address translation, the ATC in the first device finds that some virtual address requests have failed, and therefore needs to re-establish the virtual address information. The following will exemplarily illustrate how the TA in the second device establishes the relevant page tables based on the page table requests initiated by the ATC in the first device.

[0190] 1) Upon receiving a page table request, the TA (System Controller) begins building the page table based on the information shown in the page table request message. The TA may not fully satisfy all the page table spaces and corresponding memory attributes requested by the ATC (Application Processor). These are merely informational messages for the TA, and the TA (system software) can decide whether to satisfy all of the ATC's expectations based on its own design and strategies. For page table requests under the same PRG (Period Relationship Group), the TA can return multiple page table response messages with page table information to the ATC in batches, depending on its specific design and microarchitecture. Alternatively, like existing PCIe ATS technology, it can return only one page table response message without data (page table information) to the ATC. This application's embodiments, compared to existing technologies, define a mechanism that allows page table response messages to carry page table information (with data), and allows multiple page table response messages to correspond to multiple page table requests for the same PRG number. First, among the multiple page table response messages returned by the TA for the same PRG number, a format for the last page table response message needs to be defined. This format needs to correctly indicate the total number of page table response messages for the current PRG, and correctly indicate which page table request under this PRG the successfully created page table information carried in each page table response message corresponds to. The page table information carried in the page table response message can include the base address and size of the corresponding page table, the memory attributes of the physical address space of the corresponding page table, the read / write permissions of the physical address space of the corresponding page table, whether the physical address space of the corresponding page table is privileged, and whether the physical address space of the corresponding page table is executable, etc. The number of sets of page table information carried in a page table response message with page table information can be less than the number of page table allocation units requested in the corresponding page table request. The ATC should not assume that if the number of sets of page table information carried in the received page table response message is less than the number of page table allocation units in the corresponding page table request, the corresponding page table allocation unit that did not return page table information was not successfully created.

[0191] 2) such as Figure 5C As shown, Figure 5CThis is a schematic diagram of another page table response message format with page table information provided in this application embodiment. The page table response message with page table information is a data-carrying page table response message; successfully established page table information is carried as data in the message. Only successfully established page tables are returned to the ATC via a data-carrying page table response message. The L field of the page table response message indicates whether the current page table response message is the last page table response message under the corresponding PRG; Page Num should accurately indicate the Page Num value of the corresponding page table request under this PRG; the length field indicates how many groups of page table information are carried in the current page table response message, with each 2 DWs of data forming one group of page table information; for the page table response message with an L field of 1, the RC field value must accurately indicate the total number of page table response messages under this PRG. Each page table information group (2 DWs in total) carries the following information: the physical base address corresponding to the currently created page table, the memory attributes (MemAttr) of the physical address space corresponding to the currently created page table, read and write permissions (R and W domains), whether it is privileged (Pri), etc. The specific meanings are shown in Table 3. The encoded meaning of MemAttr is one of the possibilities, which can be understood and defined according to the specific TA system.

[0192] Table 3

[0193]

[0194]

[0195] like Figure 5D As shown, Figure 5D This is another schematic diagram of the page table space size provided in the embodiments of this application. Each page table information group also carries the size of the physical address space corresponding to the currently established page table. This size indication is similar to the translation result size indication: whether the S field is 1 or not indicates whether the size of the physical address space of the currently established page table is greater than 4096 bytes. If the S field is 1, then whether the bit

[12] of the page table address is 1 indicates whether the size of the physical address space of the currently established page table is greater than 8192 bytes, and so on.

[0196] Step S310: The second device sends one or more page table response messages back to the first device.

[0197] Specifically, once the second device has established a page table response message corresponding to a page table request unit, it can send feedback to the first device, either in multiple steps or in parallel or serially.

[0198] Step S311: The first device receives one or more page table response messages from the second device; for each page table response message, the first device initiates an access operation on the corresponding physical address according to the page table request code and the mapping relationship between the virtual address and physical address of the currently established page table request unit; or, for each page table response message, the first device determines the virtual address corresponding to the corresponding page table request unit according to the page table request code, and initiates a translation request for the virtual address corresponding to the page table request unit to the second device.

[0199] Specifically, if the page table response message carries information about a successfully established page table, then after a page fault occurs in the first address translation request on the page table requesting side's ATC, a second page table request can be issued, and the address mapping result can be directly obtained through the page table response message. Subsequent access operations can then be performed on the corresponding physical address based on the address mapping result. Compared to existing technologies, this reduces the need for a second address translation request and its feedback, thus reducing the steps required by existing Address Translation Service (ATS) technologies after a page fault occurs during the first page table request and the necessary address mapping result is obtained again, thereby improving the system's memory access performance. Alternatively, if the page table response message does not carry information about a successfully established page table, then the page table requesting side's ATC needs to initiate another address translation request for the virtual address whose page table has not been successfully established.

[0200] In step S311 above, the ATC in the first device can receive one or more page table response messages from the TA in the second device. The following will exemplarily illustrate how the ATC in the first device specifically receives the page table response messages from the TA in the second device.

[0201] 1) The ATC may receive multiple page table response messages belonging to the same PRG in batches. If the corresponding page table response message carries page table information, the ATC is allowed to directly use the page table physical address and attributes carried in these page table response messages to directly issue physical address access to the corresponding physical address space. The ATC cannot assume that all page table requests under its PRG will receive page table response messages with data, nor can the ATC assume that page table requests that did not receive page table response messages with data were not successfully established. The ATC considers all leaf requests under the corresponding PRG to have been processed and responded to when the following condition is met: the number of all page table response messages received by the ATC is equal to the number of page table response messages with the L field set to 1 under the current PRG, as indicated by the RC value. Therefore, page table response messages can also be transmitted out of order on the bus. Figure 5E As shown, Figure 5E This is a schematic diagram illustrating a scenario in which an ATC receives a page table response message according to an embodiment of this application.

[0202] This application embodiment redefines the page table request. By defining the page table request, it can carry the untranslated address and size of the page table to be created, as well as some expectations for certain attributes of the requested page table space or the possible use of these page tables by the requester, so that TA can optimize its own design space and also solve the above-mentioned shortcomings of the prior art (5).

[0203] This application also redefines the page table response message mechanism. By modifying the existing mechanism's limitation that only one page table response message can be sent for a page table request under the same PRG, it extends this mechanism to allow multiple page table response messages for a page table request under the same PRG. Furthermore, it defines a mechanism that allows the requester (ATC) to accurately identify whether all page table requests under the corresponding PRG have been completed (receiving all corresponding page table response messages). Simultaneously, this application also defines a page table response message mechanism that allows the page table response message to directly return the page table mapping result of the page table space established in the corresponding request. This solves the aforementioned (6) shortcomings of the prior art.

[0204] Please see Figure 6 , Figure 6 This is a schematic diagram of a bus system provided in an embodiment of this application. The bus system 60 may include multiple devices interconnected by a bus, and the multiple devices interconnected by the bus include at least a first device 601 and a second device 602; wherein, the detailed functional descriptions of the first device 601 and the second device 602 are as follows.

[0205] First device 601 is used to send an address translation request to second device 602. The address translation request includes a first identifier that identifies the address translation request and a virtual address of the virtual address space to be translated. The virtual address space to be translated includes one or more minimum translation units (STUs).

[0206] The second device 602 is configured to generate one or more translation response messages in response to the address translation request; wherein each of the one or more translation response messages includes the first identifier, target location information and target physical address, the target location information being the location information of one or more target STUs in the virtual address space to be translated, and the target physical address being the physical address after translating the virtual address of the one or more target STUs;

[0207] The second device 602 is used to send back one or more translation response messages to the first device 601;

[0208] The first device 601 is configured to initiate a read / write access operation to the target physical address based on the first identifier and the target location information for each of the translation response messages.

[0209] In one possible implementation, the target location information includes the base address of the first target STU among the one or more target STUs, and the size of the address space of the one or more target STUs.

[0210] In one possible implementation, the first device 601 is specifically configured to: determine the virtual address of the one or more target STUs based on the first identifier and the target location information; determine the read / write access operation corresponding to the virtual address of the one or more target STUs, and initiate the read / write access operation to the target physical address.

[0211] In one possible implementation, the address translation request further includes usage information of the virtual address space, which includes one or more of the following: usage frequency, access frequency, or regional expectations of the virtual address space.

[0212] In one possible implementation, each translation response message further includes one or more of the memory attributes of the one or more target STUs, first indication information, or translation extension information; wherein, the memory attributes include whether the target STU is cacheable or the size of the access latency corresponding to the target STU, and the first indication information is used to indicate whether the current translation response message is the last response message among the one or more translation response messages.

[0213] In one possible implementation, at least one of the one or more translation response messages further includes the total number of translation response messages corresponding to the address translation request; the second device 602 is further configured to determine whether the translation response message corresponding to the address translation request has been received completely based on the number of received translation response messages and the total number of translation response messages; if the reception is complete, the marker resource corresponding to the address translation request is released or reused.

[0214] In one possible implementation, the second device 602 is further configured to send an invalidation request to the first device 601. The invalidation request includes a second identifier identifying the invalidation request and virtual addresses of a plurality of invalidation units to be invalidated, wherein the plurality of invalidation units correspond to multiple discrete virtual address spaces to be invalidated. The first device 601 is further configured to, in response to the invalidation request, invalidate the virtual address and physical address mapping relationship of each of the plurality of invalidation units.

[0215] In one possible implementation, the first device 601 is further configured to generate one or more invalidation response messages, wherein each of the invalidation response messages includes the second identifier and an invalidation unit number, the invalidation unit number being the number of the currently invalidated invalidation unit among the plurality of invalidation units.

[0216] In one possible implementation, at least one of the one or more invalidation response messages further includes the total number of invalidation response messages corresponding to the invalidation request; the second device 602 is further configured to determine whether the invalidation response message corresponding to the invalidation request has been received completely based on the number of received invalidation response messages and the total number of invalidation response messages; if the reception is complete, the marker resource corresponding to the invalidation request is released or reused.

[0217] In one possible implementation, the first device 601 is further configured to initiate a page table request to the second device 602. The page table request includes the page table request code of the page table request in the page table request group (PRG) to which it belongs and the virtual addresses of a plurality of page table request units to be requested, wherein the plurality of page table request units correspond to a plurality of non-contiguous page table spaces.

[0218] In one possible implementation, the page table request may also include one or more of the following: page table space size, read / write permissions, expected memory attributes, or usage prompt information for each of the plurality of page table request units.

[0219] In one possible implementation, the second device 602 is further configured to generate one or more page table response messages in response to the page table request; wherein each page table response message includes the page table request code and a mapping relationship between the virtual address and physical address of the currently established page table request unit, or each page table response message includes the page table request code; the second device 602 is further configured to send the one or more page table response messages back to the first device.

[0220] In one possible implementation, each page table response message further includes one or more of the following: the base address of the page table space corresponding to the established page table request unit, the page table space size, the memory model attributes of the page table space, read / write permissions, and system attributes.

[0221] In one possible implementation, at least one of the one or more page table response messages further includes the total number of page table response messages corresponding to the page table request group (PRG); the second device 602 is further configured to determine whether the page table response messages corresponding to the page table request group (PRG) have been received completely based on the total number of page table response messages and the number of page table response messages received; if the reception has been completed, the marked resource corresponding to the page table request group (PRG) is released or reused.

[0222] In one possible implementation, the first device 601 is further configured to receive one or more page table response messages fed back by the second device 602; for each page table response message, based on the page table request code and the mapping relationship between the virtual address and physical address of the currently established page table request unit, initiate an access operation on the corresponding physical address; or, for each page table response message, based on the page table request code, determine the virtual address corresponding to the corresponding page table request unit, and initiate a translation request for the virtual address corresponding to the page table request unit to the second device.

[0223] It should be noted that the functions of each device in the bus system 60 described in this application embodiment are as described above. Figures 1-5E The relevant descriptions in the method embodiments are not repeated here.

[0224] This application also provides a computer storage medium, wherein the computer storage medium may store a program, which, when executed, includes some or all of the steps described in any of the above method embodiments.

[0225] This application also provides a computer program that includes instructions that, when executed by a computer, enable the computer to perform some or all of the steps described in the above method embodiments.

[0226] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0227] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0228] In the several embodiments provided in this application, it should be understood that the disclosed apparatus can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of the units described above is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical or other forms.

[0229] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0230] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0231] If the integrated units described above are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which can be a personal computer, server, or network device, specifically a processor in the computer device) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium may include various media capable of storing program code, such as a USB flash drive, portable hard drive, magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM).

[0232] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A bus communication method, characterized in that, Applied to a bus system, the bus system including multiple devices interconnected via a bus, the multiple devices interconnected via the bus including at least a first device and a second device; the method includes: The first device sends an address translation request to the second device. The address translation request includes a first identifier that identifies the address translation request and a virtual address of the virtual address space to be translated. The virtual address space to be translated includes one or more minimum translation units (STUs). In response to the address translation request, the second device generates one or more translation response messages; wherein each of the one or more translation response messages includes the first identifier, target location information and target physical address, the target location information being the location information of one or more target STUs in the virtual address space to be translated, and the target physical address being the physical address after translating the virtual address of the one or more target STUs; The second device sends one or more translation response messages back to the first device; wherein the one or more translation response messages are sent back to the first device in the order in which they are translated. For each of the translation response messages, the first device initiates a read / write access operation to the target physical address based on the first identifier and the target location information.

2. The method according to claim 1, characterized in that, The target location information includes the base address of the first target STU among the one or more target STUs, and the size of the address space of the one or more target STUs.

3. The method according to claim 1, characterized in that, The first device initiates a read / write access operation to the target physical address based on the first identifier and the target location information, including: The first device determines the virtual address of the one or more target STUs based on the first identifier and the target location information; Determine the read / write access operation corresponding to the virtual address of the one or more target STUs, and initiate the read / write access operation to the target physical address.

4. The method according to any one of claims 1-3, characterized in that, The address translation request also includes usage information of the virtual address space, which includes one or more of the following: usage frequency, access frequency, or regional expectations of the virtual address space.

5. The method according to any one of claims 1-3, characterized in that, Each of the translation response messages also includes one or more of the memory attributes of the one or more target STUs, first indication information, or translation extension information; wherein, the memory attributes include whether the target STU is cacheable or the size of the access latency corresponding to the target STU, and the first indication information is used to indicate whether the current translation response message is the last response message among the one or more translation response messages.

6. The method according to any one of claims 1-3, characterized in that, At least one of the one or more translation response messages also includes the total number of translation response messages corresponding to the address translation request; The method further includes: The second device determines whether the translation response message corresponding to the address translation request has been received completely based on the number of received translation response messages and the total number of translation response messages. If the reception is complete, the marker resource corresponding to the address translation request is released or reused.

7. The method according to any one of claims 1-3, characterized in that, The method further includes: The second device sends an invalidation request to the first device. The invalidation request includes a second identifier that identifies the invalidation request and the virtual addresses of a plurality of invalidation units to be invalidated, wherein the plurality of invalidation units correspond to a plurality of discrete virtual address spaces to be invalidated. In response to the invalidation request, the first device invalidates the virtual address and physical address mapping relationship of each of the plurality of invalidation units.

8. The method according to claim 7, characterized in that, The method further includes: The first device generates one or more invalidation response messages, wherein each invalidation response message includes the second identifier and an invalidation unit number, the invalidation unit number being the number of the currently invalidated invalidation unit among the plurality of invalidation units.

9. The method according to claim 8, characterized in that, At least one invalidation response message in the one or more invalidation response messages further includes the total number of invalidation response messages corresponding to the invalidation request; the method further includes: The second device determines whether the invalidation response message corresponding to the invalidation request has been received completely based on the number of invalidation response messages received and the total number of invalidation response messages. If the reception is complete, the marked resource corresponding to the invalidation request is released or reused.

10. The method according to claim 1, characterized in that, The method further includes: The first device initiates a page table request to the second device. The page table request includes the page table request code in the page table request group (PRG) to which the page table request belongs and the virtual addresses of multiple page table request units to be requested, wherein the multiple page table request units correspond to multiple non-contiguous page table spaces.

11. The method according to claim 10, characterized in that, The page table request also includes one or more of the following: the page table space size, read / write permissions, expected memory attributes, or usage prompt information corresponding to each of the plurality of page table request units.

12. The method according to claim 10 or 11, characterized in that, The method further includes: In response to the page table request, the second device generates one or more page table response messages; wherein each page table response message includes the page table request code and the mapping relationship between the virtual address and physical address of the currently established page table request unit, or each page table response message includes the page table request code; The second device sends one or more page table response messages back to the first device.

13. The method according to claim 12, characterized in that, Each page table response message also includes one or more of the following: the base address of the page table space corresponding to the established page table request unit, the page table space size, the memory model attributes of the page table space, read / write permissions, or system attributes.

14. The method according to claim 12, characterized in that, At least one of the one or more page table response messages further includes the total number of page table response messages corresponding to the page table request group (PRG); the method further includes: The second device determines whether the page table response message corresponding to the page table request group (PRG) has been completely received based on the total number of page table response messages and the number of page table response messages received. If the reception is complete, the marked resource corresponding to the page table request group (PRG) is released or reused.

15. The method according to claim 12, characterized in that, The method further includes: The first device receives one or more page table response messages from the second device; For each page table response message, the first device initiates an access operation on the corresponding physical address based on the page table request code and the mapping relationship between the virtual address and physical address of the currently established page table request unit; or, For each page table response message, the first device determines the virtual address corresponding to the page table request unit based on the page table request code, and initiates a translation request for the virtual address corresponding to the page table request unit to the second device.

16. A bus system, characterized in that, The bus system includes multiple devices interconnected via a bus, and the multiple devices interconnected via the bus include at least a first device and a second device; The first device is configured to send an address translation request to the second device. The address translation request includes a first identifier that identifies the address translation request and a virtual address of the virtual address space to be translated. The virtual address space to be translated includes one or more minimum translation units (STUs). The second device is configured to generate one or more translation response messages in response to the address translation request; wherein each of the one or more translation response messages includes the first identifier, target location information and target physical address, the target location information being the location information of one or more target STUs in the virtual address space to be translated, and the target physical address being the physical address after translating the virtual address of the one or more target STUs; The second device is configured to send one or more translation response messages back to the first device; wherein the one or more translation response messages are sent back to the first device in the order in which they are translated. The first device is configured to initiate a read / write access operation to the target physical address for each of the translated response messages, based on the first identifier and the target location information.

17. The system according to claim 16, characterized in that, The target location information includes the base address of the first target STU among the one or more target STUs, and the size of the address space of the one or more target STUs.

18. The system according to claim 16, characterized in that, The first device is specifically used for: Based on the first identifier and the target location information, determine the virtual address of the one or more target STUs; Determine the read / write access operation corresponding to the virtual address of the one or more target STUs, and initiate the read / write access operation to the target physical address.

19. The system according to any one of claims 16-18, characterized in that, The address translation request also includes usage information of the virtual address space, which includes one or more of the following: usage frequency, access frequency, or regional expectations of the virtual address space.

20. The system according to any one of claims 16-18, characterized in that, Each of the translation response messages also includes one or more of the memory attributes of the one or more target STUs, first indication information, or translation extension information; wherein, the memory attributes include whether the target STU is cacheable or the size of the access latency corresponding to the target STU, and the first indication information is used to indicate whether the current translation response message is the last response message among the one or more translation response messages.

21. The system according to any one of claims 16-18, characterized in that, At least one of the one or more translation response messages also includes the total number of translation response messages corresponding to the address translation request; The second device is further configured to determine whether the translation response message corresponding to the address translation request has been received completely based on the number of received translation response messages and the total number of translation response messages; If the reception is complete, the marker resource corresponding to the address translation request is released or reused.

22. The system according to any one of claims 16-18, characterized in that, The second device is further configured to send an invalidation request to the first device, the invalidation request including a second identifier identifying the invalidation request and virtual addresses of a plurality of invalidation units to be invalidated, wherein the plurality of invalidation units correspond to a plurality of discrete virtual address spaces to be invalidated; The first device is further configured to, in response to the invalidation request, invalidate the virtual address and physical address mapping relationship of each of the plurality of invalidation units.

23. The system according to claim 22, characterized in that, The first device is further configured to generate one or more invalidation response messages, wherein each invalidation response message includes the second identifier and an invalidation unit number, the invalidation unit number being the number of the currently invalidated invalidation unit among the plurality of invalidation units.

24. The system according to claim 23, characterized in that, At least one invalidation response message in the one or more invalidation response messages also includes the total number of invalidation response messages corresponding to the invalidation request; The second device is further configured to determine whether the invalidation response message corresponding to the invalidation request has been received completely based on the number of invalidation response messages received and the total number of invalidation response messages; If the reception is complete, the marked resource corresponding to the invalidation request is released or reused.

25. The system according to claim 16, characterized in that, The first device is further configured to initiate a page table request to the second device. The page table request includes the page table request code in the page table request group (PRG) to which the page table request belongs and the virtual addresses of a plurality of page table request units to be requested, wherein the plurality of page table request units correspond to a plurality of non-contiguous page table spaces.

26. The system according to claim 25, characterized in that, The page table request also includes one or more of the following: the page table space size, read / write permissions, expected memory attributes, or usage prompt information corresponding to each of the plurality of page table request units.

27. The system according to claim 25 or 26, characterized in that, The second device is further configured to generate one or more page table response messages in response to the page table request; wherein each page table response message includes the page table request code and the mapping relationship between the virtual address and physical address of the currently established page table request unit, or each page table response message includes the page table request code; The second device is also configured to send one or more page table response messages back to the first device.

28. The system according to claim 27, characterized in that, Each page table response message also includes one or more of the following: the base address of the page table space corresponding to the established page table request unit, the page table space size, the memory model attributes of the page table space, read / write permissions, and system attributes.

29. The system according to claim 27, characterized in that, At least one of the page table response messages includes the total number of page table response messages corresponding to the page table request group (PRG). The second device is further configured to determine whether the page table response message corresponding to the page table request group (PRG) has been received completely, based on the total number of page table response messages and the number of page table response messages received. If the reception is complete, the marked resource corresponding to the page table request group (PRG) is released or reused.

30. The system according to claim 27, characterized in that, The first device is further used for: Receive one or more page table response messages from the second device; For each page table response message, based on the page table request code and the mapping relationship between the virtual address and physical address of the currently established page table request unit, an access operation is initiated on the corresponding physical address; or, for each page table response message, based on the page table request code, the virtual address corresponding to the corresponding page table request unit is determined, and a translation request for the virtual address corresponding to the page table request unit is initiated to the second device.

31. A computer-readable storage medium, characterized in that, The computer-readable medium is used to store program code that, when executed by the bus system, implements the method described in any one of claims 1-15.

32. A computer program, characterized in that, The computer program includes instructions that, when executed by the bus system, cause the bus system to perform the method as described in any one of claims 1-15.

Images