TW202319902A - Software indirection level for address translation sharing - Google Patents

Abstract

Systems and methods are disclosed for debug event tracing. For example, an integrated circuit (e.g., a processor) for executing instructions includes an address translation buffer, wherein an entry of the address translation buffer includes a tag including a field storing a context identifier; and a context identifier look-up circuitry that stores context identifiers in an array that is indexed by a hardware identifier, wherein the context identifier look-up circuitry is configured to: receive an input address translation request including a first hardware identifier value; generate an output address translation request, including a first context identifier value that is stored in an entry of the array indexed by the first hardware identifier value; and apply the output address translation request to the address translation buffer.

Description

address translation shareware indirection level

Cross-references to related applications

This application claims priority and benefit to U.S. Provisional Patent Application No. 63/256,628, filed October 17, 2021, which is hereby incorporated by reference in its entirety. This application claims priority and benefit to US Provisional Patent Application No. 63/256,630, filed October 17, 2021, which is hereby incorporated by reference in its entirety. This application claims priority and benefit to US Provisional Patent Application No. 63/291,314, filed December 17, 2021, which is hereby incorporated by reference in its entirety.

This disclosure is about the level of software indirection used for address translation sharing.

An input/output memory management unit (IOMMU) is a memory management unit (MMU) that connects a DMA-capable I/O bus to main memory. Like traditional MMUs that translate CPU-visible virtual addresses to physical addresses, the IOMMU maps device-visible virtual addresses (also known as device addresses or I/O addresses) to physical addresses. Some units also provide memory protection to prevent malfunction or malicious installation.

overview

Systems and methods are described herein that may be used to implement a level of software indirection for address translation sharing. Address translation engines may be integrated between input/output (I/O) devices and system interconnects. For example, an IO device may include a graphics processing unit (GPU) for graphics, a storage controller, a network interface controller (NIC), or an IO accelerator (such as a cryptographic accelerator or a digital signal processor (DSP)), which may have Direct memory access (DMA) interface to the system. The role of the address translation engine may include translating device virtual addresses to physical addresses for device DMA requests, and performing memory protection for such requests.

In order to perform address translation, the address translation engine can distinguish various IO devices to select an appropriate translation rule. To facilitate this, an inbound request may include a hardware identifier (eg, a hardware context identifier) and a request (eg, a request that also includes address, read/write, attributes) to identify the conversion item. A hardware identifier should be unique to a device or a program within a device. Each device can provide several HIDs to the address translation engine on a transaction basis, but a HID should only be associated with one device.

The address translation engine includes a mechanism for associating software programs with hardware identifiers. This is accomplished by linking context identifiers (eg, SoftContextID) to hardware identifiers using an array indexed by hardware identifiers. A context identifier may be a representation of a software program. In some implementations, the array is stored as a single-level table in data storage (eg, a register file or static random access memory (SRAM)) included in the address translation engine. In some implementations, the array is stored in system memory as a multilevel table with entries. Write access to the array mapping hardware identifiers to context identifiers may be restricted to hosts with a particular privilege level (eg, machine privilege level or administrator privilege level) and/or hosts acting as hypervisors. By sharing a context identifier, multiple devices can share an address translation context.

Some implementations may provide advantages over conventional systems for address translation, such as reducing the size of an address translation buffer (such as an address translation cache or translation lookaside buffer) needed to efficiently support collection of IO devices, Support for a large number of IO devices for shared memory systems, and/or increase the speed/performance of the address translation engine in some cases.

As used herein, the term "circuit" refers to an arrangement of electronic components (eg, transistors, resistors, capacitors, and/or inductors) structured to perform one or more functions. For example, a circuit may comprise one or more transistors interconnected to form logic gates that collectively perform a logic function. detail

1 is a block diagram of an example of a system 100 for sharing memory with an I/O device 140, including an address translation engine 150 for translating virtual addresses from various devices to physical addresses. System 100 includes processor core complex 110 , memory interconnect 120 and memory subsystem 130 . System 100 also includes one or more I/O devices 140 that access memory subsystem 130 using address translation engine 150 , which is part of I/O bridge 152 .

The address translation engine 150 is integrated between the IO device 140 and the system interconnection 120 . For example, input/output devices 140 may include an IO accelerator (eg, a cryptographic accelerator or DSP), possibly with a DMA interface to system 100's memory, a GPU for graphics, a storage controller, and/or a NIC. The purpose of the address translation engine 150 is to both translate device virtual addresses to physical addresses for device DMA requests, and to perform memory protection for such requests.

For example, address translation engine 150 may be used to facilitate DMA traffic from I/O device 140 . The address translation engine 150 can be integrated in the IO bridge 152 or the housing to meet the requirements of a system on chip (SOC). The role of this IO bridge 152 may vary from SOC to SOC, but it may have to handle request reordering, error handling, and/or specific attribute management.

In an example, device DMA requests (which may be referred to as inbound transactions) to memory subsystem 130 may be handled by address translation engine 150 . In some implementations, outbound transactions from the processor core complex 110 to the input/output devices 140 are not managed by the address translation engine 150 because the address of the transaction is already physical (e.g., by the core's memory management unit (MMU) ) to convert). In order for the address translation engine 150 to perform address translation, it can differentiate various IO devices 140 to select an appropriate translation rule. Incoming requests must then have a hardware identifier (eg hardware context identifier) along with the request (address, read/write, attributes) to identify the translation item. A hardware identifier may be unique to a device (or a program in a device). In some implementations, each IO device may provide several HIDs to the address translation engine 150 on a transaction basis, but one HID should only be associated with one device.

Address translation engine 150 may include a mechanism for associating software programs with hardware identifiers. This can be achieved by linking software context identifiers to hardware identifiers using a context identifier table. A software context identifier may be a representation of a software program (eg, using an address space identifier (ASID)). A single address translation engine can be used to perform address translation from one device or several devices. There may also be several address conversion engine instances in the SOC, and each instance converts addresses for a set of IO devices. For example, the address translation engine 150 may be the address translation engine 300 of FIG. 3 .

FIG. 2 is a block diagram of an example of a system 200 for sharing memory with a device connected by a bus to an integrated circuit 210 including an address translation engine 230 including an inter-device A context identifier lookup circuit 240 capable of sharing an address translation context. In this example, system 200 is a Peripheral Component Interconnect Express (PCIe) system that connects components via a PCIe bus. System 200 includes an integrated circuit 210 for executing instructions, a system memory 218 , and end devices ( 222 , 224 , and 226 ), some of which are connected to integrated circuit 210 via switches 228 . Integrated circuit 210 includes one or more processor cores 212, system architecture 214, memory controller 216 for interfacing with system memory 218, PCIe controller 220 for interfacing with devices via a PCIe bus, and an address translation engine 230 (such as the address translation engine 300 of FIG. 3 ) for translating virtual addresses used by the terminal devices ( 222 , 224 , and 226 ) into physical addresses of the system memory 218 . The address translation engine 230 includes an address translation buffer 232 (such as a translation lookaside buffer (TLB)) and a context identifier lookup circuit 240 for mapping Linked hardware identifiers to context identifiers that can be used to facilitate sharing of address translation contexts between devices. For example, address translation buffer 232 may be address translation buffer 300 of FIG. 3 . For example, system 200 may be used to implement procedure 600 of FIG. 6 and/or procedure 700 of FIG. 7 .

The integrated circuit 210 includes an address translation buffer 232 . The entries of the address translation buffer 232 include tags including fields for storing context identifiers. For example, address translation buffer 232 may be a translation lookaside buffer. In some implementations, the address translation buffer 232 is part of a second-level address translation cache. Entries in address translation buffer 232 may be tagged with a context identifier (eg, a software context identifier) and a virtual address. The full context identifier can be used to mark VS-phase or nest transitions, and the upper part of the context identifier can be used to mark G-phase transitions. There may be several entries in address translation buffer 232 with the same virtual address but different context identifiers, or even the same virtual address and context identifier but different privilege levels. In some implementations, the address translation buffer 232 is not tagged with a hardware identifier because multiple IO devices can use the same translation rules and be assigned to the same software context. However, a software context can be uniquely identified by a privilege level and a context identifier.

Integrated circuit 210 includes context identifier lookup circuitry 240 that stores context identifiers in an array, such as context identifier entry array 410 , indexed by the hardware identifier. The context identifier lookup circuit 240 may be configured to receive an input address translation request comprising a first hardware identifier value; generate an output address translation request comprising an item stored in an array indexed by the first hardware identifier value and applying the output address translation request to the address translation buffer 232 . The address translation buffer 232 can return the physical address in response to the outgoing address translation request, and can transmit the outgoing address translation request in response to the incoming address translation request. In some implementations, the incoming address translation request is part of a DMA request. In some implementations, an incoming address translation request is received from an external device via a PCIe bus. For example, an incoming address translation request may be received from an end device ( 222 , 224 or 226 ) via PCIe controller 220 . For example, an incoming address translation request may be received from a processor core via the bus by context identifier lookup circuit 240, and a first hardware identifier value may be associated with the processor core.

In some implementations, the array is implemented as a single-level table, and all entries of the array are stored in the data storage of the context identifier lookup circuit 240 . For example, the context identifier lookup circuit 240 may have 2^n entries, where n is the width of the hardware identifier in bits. In an example, the array of context identifier lookup circuits 240 may have 256 locally stored entries. In some implementations, the array is implemented as a multi-level table, and at least some entries of the array are stored in memory accessed by the context identifier lookup circuit 240 via the bus. For example, the context identifier lookup circuit 240 may include data storage storing a first level of a multi-level table with entries including pointers to the next level of the multi-level table. For example, the context identifier lookup circuit 240 may store some levels of the multi-level table in the system memory 218 . For example, the array of context identifier lookup circuits 240 may be implemented as multi-level table 500 of FIG. 5 .

The entries of the array of context identifier lookup circuits 240 may include various information specifying how address translation engine 230 is to perform address translation. For example, an item of the array may include a context identifier (e.g., a software context identifier; a valid flag; and/or a physical page number (PPN) (e.g., a 4KiB PPN for single-phase or G-phase-only transitions). In some implementations, The entries of the array indexed by the first hardware identifier value include a translation tag indicating the privilege level, virtualization mode, and translation mode, and the translation tag is included in the output address translation request. For example, the privilege level may be derived from including the machine privilege A set of privilege levels for grades and administrator privilege levels. For example, a translation pattern can be from a set of translation patterns including single-phase translation patterns, G-phase-only patterns, VS-phase-only, and nested translation patterns. A translation label can be for an address A portion of the tag of an entry in translation buffer 232 and may be used by address translation buffer 232 and/or other components of address translation engine 230 to perform the requested address translation.

The context identifier lookup circuit 240 may be configured and maintained by executing commands received at a host interface (eg, via a machine command queue or an administrator command queue). The context ID lookup circuit 240 can also detect some errors and send some error records to the host accordingly (eg, via the machine error log queue or the administrator error log queue). In some implementations, the context identifier lookup circuit 240 is configured to only allow programs with a machine privilege level to write to the entries of the array. In some implementations, the context identifier lookup circuit 240 is configured to only allow programs with an administrator privilege level to write to the items of the array. In some implementations, the context identifier lookup circuit 240 is configured to only allow the hypervisor to write to the entries of the array. For example, address translation engine 230 may implement procedure 700 of FIG. 7 to configure and maintain an array of context identifier lookup circuits 240 . In some implementations, the context identifier lookup circuit 240 can be read indirectly by software via the host interface for debugging purposes.

Note that although not shown in FIG. 2 , integrated circuit 210 may have several PCIe controllers handled by a single address translation engine 230 . The hardware identifier provided to the address translation engine 230 may be structured such that each end device has a unique identifier (eg, the most significant bit of the hardware identifier may be the root segment ID).

3 is a block diagram of an example of an address translation engine 300 for mapping virtual addresses from various devices to physical addresses in a memory system. Address translation engine 300 may be located in an integrated circuit (eg, an SOC) close to the device for which it provides address translation. The address translation engine 300 functions to intercept device address transactions to system memory and perform the requested address translation using its address translation buffer 310 (eg, comprising one or more TLBs). If the translation buffer does not have the requested information, the address translation engine 300 performs a page table walk through the bus (eg system interconnect) to system memory interface. The address translation engine 300 can manage command queues and error log queues to interface with software. Address translation engine 300 may also implement a hardware performance monitor. The address translation engine 300 includes an address translation buffer 310 , a page table walker 320 , a permission checking circuit 330 , a context identifier lookup circuit 340 and a host interface circuit 350 . For example, the address translation engine 300 may be used to implement the procedure 600 of FIG. 6 and/or the procedure 700 of FIG. 7 .

The address translation engine 300 includes an address translation buffer 310 . For example, address translation buffer 310 may be a translation lookaside buffer. In some implementations, the address translation buffer 310 is part of a second-level address translation cache. For example, address translation buffer 310 may include a small and fast L1 TLB and a larger L2 TLB. On a TLB hit, the translated address and permission can be sent to the permission checking circuit 330 via the hit queue, while an L2TLB miss is sent to the page table walker 320 . The address translation buffer 310 may be associated with a configurable number of entries entirely or in sets. For example, the replacement policy of the address translation buffer 310 may be pseudo-LRU (pseudo-least recently used). In some implementations, the address translation buffer 310 stores page translations in scratchpads using a vector of reg elements that create arrays of scratchpads whose output is delayed by one clock cycle (depending on its enable signal) A copy of the input signal. The address translation buffer 310 can respond with a hit/miss indication on the next clock cycle and store the virtual-to-physical page translation (eg, for 4KB pages or 2MB/1GB/512GB superpages). For example, address translation buffer 310 may be implemented using content addressable memory (CAM) or static random access memory (SRAM). The entries of the address translation buffer 310 include tags, which include fields for storing context identifiers (eg, software context identifiers), which may be shared by multiple hardware devices. Item tags may also include virtual addresses and/or translation tags indicating privilege levels, virtualization modes, and translation modes. For example, the privilege level may be from a set of privilege levels including a machine privilege level and an administrator privilege level. For example, the transition patterns may be from a set of transition patterns including single-phase transition patterns, G-phase-only patterns, VS-phase-only patterns, and nested transition patterns. The items of the address conversion buffer 310 include data, and the data includes physical addresses and permission data (for example, including read permission flags, write permission flags, and execute permission flags).

The address translation engine 300 includes a page table walker 320 configured to perform a page table walk to determine address translations in response to cache misses in the address translation buffer 310 . For example, page table walker 320 may include parallel page table walker instances that share caches for non-leaf page tables. Page table walker 320 may be configured to access page tables stored in system memory (eg, system memory 218 ) using a memory interface to the system interconnect.

Address translation engine 300 includes permission check circuitry 330 that receives translated physical addresses from address translation buffer 310 . The license check circuit 330 may include an arbiter to obtain translated requests from the page table walker response queue. It performs a permission check and sends a response to the requesting hardware device via a device conversion completion interface (eg, via a PCIe bus host interface). In the case of a violation, the permission checking circuit 330 may also write the error record to the appropriate error record queue.

Address translation engine 300 includes context identifier lookup circuitry 340 . The context identifier lookup circuit 340 maps hardware identifiers to context identifiers (eg, software context identifiers) that may be associated with multiple hardware devices to facilitate sharing of address translation contexts among devices. The context identifier lookup circuit 340 stores the context identifier in an array indexed by the hardware identifier, such as the context identifier entry array 410 . The context identifier lookup circuit 340 may be configured to receive an input address translation request comprising a first hardware identifier value; generate an output address translation request, the output address translation request comprising a first context identifier value, the first context storing the identifier value in an entry of the array indexed by the first hardware identifier value; and applying the output address translation request to the address translation buffer 310 . Address translation buffer 310 may return physical addresses in response to outgoing address translation requests, which may be transmitted (by permission check circuit 330 ) in response to incoming address translation requests. In some implementations, the incoming address translation request is part of a DMA request. For example, an incoming address translation request may be received through a device translation request interface, which may be a slave interface and an active/ready type interface. For example, the context identifier lookup circuit 340 may be the context identifier lookup circuit 400 of FIG. 4 .

In some implementations, the array is implemented as a single-level table and all entries of the array are stored in the data storage of the context identifier lookup circuit 340 . For example, the context identifier lookup circuit 340 may have 2^n entries, where n is the bit width of the hardware identifier. In one example, the array of context identifier lookup circuits 340 may have 256 locally stored entries. In some implementations, the array is implemented as a multi-level table, and at least some entries of the array are stored in memory accessed by the context identifier lookup circuit 340 via the bus. For example, the context identifier lookup circuit 340 may include data storage storing a first level of a multi-level table with entries including pointers to the next level of the multi-level table. For example, the context ID lookup circuit 340 stores some levels of the multi-level table in system memory. For example, the array of context identifier lookup circuits 340 may be implemented as multi-level table 500 of FIG. 5 .

The entries of the array of context identifier lookup circuits 340 may include various information specifying how the address translation engine 230 is to perform address translation. For example, items of the array may include context identifiers (eg, software context identifiers; valid flags; and/or PPNs (eg, 4KiB PPNs for single-phase or G-phase-only transitions)). In some implementations, the entry of the array indexed by the first hardware identifier value includes a translation tag indicating the privilege level, virtualization mode, and translation mode, and the translation tag is included in the outgoing address translation request. For example, the privilege level may be from a set of privilege levels including a machine privilege level and an administrator privilege level. For example, the transition patterns may be from a set of transition patterns including single-phase transition patterns, G-phase-only patterns, VS-phase-only, and nested transition patterns. A translation tag may be part of the tags for an entry in address translation buffer 310 and may be used by address translation buffer 310 and/or page table walker 320 to perform the requested address translation. The context identifier lookup circuit 340 may be configured to provide the address translation buffer 310 with the entries of the array indexed by the first hardware identifier value and the translation request.

The address translation engine 300 includes a host interface circuit 350 . Host interface circuitry 350 enables the host to configure and maintain address translation engine 310 , which includes an array of write context identifier lookup circuitry 340 . The host interface circuit 350 can output error logs, system performance data and/or debug data. For example, the host interface circuit 350 can implement a command queue and an error log queue. Host interface circuitry 350 may include a slave interface to the system interconnect.

4 is a block diagram of an example of a context identifier lookup circuit 400 for sharing an address translation context between devices. The context identifier lookup circuit 400 includes a context identifier entry array 410 (eg, a table), a valid vector 420 storing valid flags for individual entries of the context identifier entry array 410 , and an arbiter 430 . For example, context identifier entry array 410 may be used to implement procedure 600 of FIG. 6 .

Items of context identifier item array 410 may describe each phase transition rule for a particular IO device. The hardware identifier of the incoming transaction is used as an index into the context identifier entry array 410 to find the associated underlying entity page number (PPN) of the page table. For example, on a small non-virtualized system, the number of devices connected to an address translation engine (eg, address translation engine 300 ) is limited, while on a large virtualized system, the number of devices and virtual functions can be large. To support these two types of systems, the context identifier lookup circuit 400 may have two interfaces to the context identifier entry array 410 . When the hardware identifier is small (eg, 8 bits or less), the context identifier entry array 410 may be a single-level table stored in the context identifier lookup circuit 400 . The software can use commands to populate the form through the host interface. When the hardware identifier is large (eg, greater than 8 bits), the context identifier entry array 410 may be a multi-level table stored in system memory.

The purpose of the context identifier entry array 410 is to provide information similar to the satp register in the memory management unit (MMU) of the kernel (hart) for single-phase transitions, and to link IO devices to context identifiers (e.g. software context identifier). In the same way that hardware identifiers link hardware device functions to unique identifiers, software can use context identifiers stored by context identifier entry array 410 to link programs (eg, a combination of VMID and ASID) to unique software identifiers. This context identifier is used to mark the base PPN of the page table for address translation. The software will keep track of the mapping of hardware identifiers to context identifiers. In some implementations, the context identifier entry array 410 provides a maximum of 30 bits, since it likely maps well to a 14-bit VMID and a 16-bit ASID, but it is a software implementation choice on how to handle context identifiers. However, software is not required to map {VMID, ASID} tuples one-to-one to context identifiers. For example, a context identifier may have a parameterized size between 16 and 30 bits (parameter: SCIDWidth). In the case of a virtualization system requesting a two-stage transition, the entire context identifier (SCID) can be used to identify the first-stage or VS-stage transition, while a part of the context identifier called the GSCID is adapted to identify the second-stage or G-phase transition. The GSCIDWidth upper bit of the context identifier may be used as the GSCID. GSCIDWidth is a parameter that must be equal to or less than SCIDWidth and GSCID = SCID [ SCIDWidth -1: SCIDWidth - GSCIDWidth ]. For example, if we assume that SCID is a 30-bit context identifier representing the tuple {VMID, ASID}, then GSCID can be a 14-bit identifier that can represent VMID. Context identifiers can be used to mark single-phase transitions as well as VS-phase or nested transitions. GSCID can be used to mark G-phase transitions.

The context identifier entry array 410 can be written locally into the context identifier lookup circuit 400 through commands sent by software. Regardless of whether the M-mode software or the S-mode software sends the command to configure the context identifier entry array 410, the hardware of the context identifier lookup circuit 400 reads the command from the queue and fills in the context appropriately after checking the validity of the command Identifier item array 410 . For debugging purposes, the host may be provided with read-only access to an array 410 of context identifier entries, where this array (eg, table) is constructed by software. Read access can be restricted to M-mode software only. In some implementations, hardware may prevent direct writes to context identifier entry array 410 from the host.

When the hardware identifier is large (eg larger than 8 bits), a multilevel table can be defined and stored in system memory. For example, the multi-stage table 500 of FIG. 5 may be used.

The context identifier lookup circuit 400 interfaces with several modules. The context identifier lookup circuit 400 interfaces with external devices via an IO device interface, which may be a device slave interface to a bus (eg, PCIe bus). Upon receipt of a translation request, when the translation is enabled, the context for the translation must be extracted from the context identifier entry array 410 using the requested hardware identifier. The context identifier lookup circuit 400 interfaces with an address translation buffer (eg, TLB) via a TLB interface. Once an entry of context identifier entry array 410 is read for a requested hardware identifier, the result may be forwarded with the request to an address translation buffer (eg, address translation buffer 310 ). The context identifier lookup circuit 400 interfaces with the host via a host interface. For example, the context identifier entry array 410 may be configured and maintained by executing commands received on the M command queue or the S command queue. The context identifier lookup circuit 400 can also detect some errors and thus send some error records to the M error record queue or the S error record queue. For debugging purposes, the context identifier lookup circuit 400 can be read indirectly by software through the host interface. To simplify invalidation procedures, a valid flag or bit associated with each entry of context identifier item array 410 may be maintained in valid vector 420 . For example, context identifier entry array 410 access may include: According to the device conversion request indicated by the request valid input signal, the reading of the hardware identifier value of the input address conversion request is performed. The entries of the context identifier entry array 410 indexed by the hardware identifier value are available on the next clock cycle and on the entry valid signal. Request attributes can be pinned and provided to address translation buffers via TLB interfaces (eg, ReqHCID_Out, ReqVA_Out, ReqID_out, Req_RWN_out).

Writes at WrHCID to build entries (WrCTE, WrPrivL) requested by WrCTEVal. The appropriate PrivL fields for the items of the context identifier item array 410 can be established based on the command source queue. When the CMD_SET_ONE_CTE command is executed from the M command queue, the M mode privilege level is established, and when the CMD_SET_ONE_CTE command is executed from the S command queue, the S mode privilege level is established. The Valid[WrHCID] bit is set up to indicate that the corresponding entry in the context identifier entry array 410 is valid.

Read in DbgHCID when requested by debug read signal. Software from the host interface has indirect read access to the context identifier entry array 410 for debugging purposes.

According to the invalid command, the valid vector 420 needs to be updated. When the InvalidateAll signal is asserted (CMD_INV_ALL_CTE), the entire valid vector 420 is reset. A valid flag (or valid flags) associated with a hardware identifier (or set of hardware identifiers) extracted from the InvHCIDBlock and InvVector inputs is cleared when the invalid signal is asserted. (Commands: CMD_INV_ONE_CTE, CMD_INV_MANY_CTE).

Arbiter 430 includes circuitry that controls access to array 410 of context identifier entries. For example, the arbiter 430 can implement a simple round robin between the IO device interface and the host interface, and the host interface can be divided into a debugging interface and a queue management interface.

5 is a block diagram of an example of a multilevel table 500 implementing an array for mapping hardware identifiers to software context identifiers in address translation requests. When the HID width is large (eg, greater than 8 bits), it is advantageous to define the array stored in system memory as a multi-level table. In FIG. 5, the array is implemented as a multilevel table 500, and at least some entries of the array are stored in memory via a bus (eg, system architecture 214) by the context identifier lookup circuitry.

Each level of the multi-level table 500 may have a size (PLATE_CIDT_L_WIDTH) defined in the configuration register of the address translation engine and a base address of the first level (PLATE_CIDT_BASE). In the multilevel table 500 , the upper 8 bits of the hardware identifier (defined by CID_L1_width ) are used to address the CID_L1 table 510 . For example, the upper 8 bits of the hardware identifier may correspond to a bus. Descriptor 512 indicates the remaining level and a pointer to the next CID table level 520 . The next 8 bits of the hardware identifier (defined by CID_L2_width) are used to index the CID_L2 table 520 . The next 8 bits of the hardware identifier may correspond to the device and function. For example, a descriptor for a multi-level table 500 may include a valid bit indicating whether the descriptor is valid, a remaining level field indicating the number of levels to read to reach an entry in the array (e.g., 2 bits for a 4-level table), and is the next-level index of the next-level physical address of the multi-level table 500 . Descriptor 522 indicates the remaining levels and a pointer to the next CID table level 530 . The next 10 bits of the hardware identifier (defined by CID_L3_width) are used to index the CID_L3 table 530 . For example, the next 10 bits of the hardware identifier may correspond to the most significant bits of the PSAID. Descriptor 532 indicates the remaining level and a pointer to the next CID table level 540 . The last 10 bits of the hardware identifier (defined by CID_L4_width) are used to index the CID_L4 table 540 . For example, the last 10 bits of the hardware identifier may correspond to the least significant bits of the PSAID. The requested entry of array 542 is indexed by the last 10 bits of the hardware identifier in CID_L4 table 540 .

The multilevel table 500 can be configured to use 2, 3 or 4 levels. For example, some terminals may support PASID and some may not. The remaining level information in the descriptor helps to optimize the number of tables and the size of the multilevel table 500 for the context identifier lookup circuit to read to reach the associated item of its array. For example, descriptor 514 indicates a remaining level and a pointer to the next CID table level 550 . The next 8 bits of the hardware identifier (defined by CID_L2_width) are used to index the CID_L2 table 520 to retrieve the requested entry of the array 552 . For example, the next 8 bits of the hardware identifier may correspond to device and function. In some implementations, the multi-level table 500 table must be configured by the most privileged software (Mmode) because it requires the establishment of the PrivL field in the array's entries.

In some implementations, the context identifier lookup circuitry includes a data store storing the first level 510 of the multilevel table 500 with entries including pointers to the next level of the multilevel table 500 .

6 is a flowchart of an example of a process 600 for mapping a hardware identifier to a software context identifier in an address translation request, the process 600 enabling sharing of an address translation context between devices. Process 600 includes receiving 610 an input address translation request comprising a first hardware identifier value; generating 620 an output address translation request comprising an item stored in an array indexed by the first hardware identifier value and applying 630 the output address translation request to the address translation buffer. For example, procedure 600 may be implemented using system 100 of FIG. 1 . For example, procedure 600 may be implemented using integrated circuit 210 of FIG. 2 . For example, program 600 may be implemented using address translation engine 300 of FIG. 3 . For example, procedure 600 may be implemented using context identifier lookup circuit 400 of FIG. 4 .

Process 600 includes receiving 610 an incoming address translation request including a first hardware identifier value. For example, an incoming address translation request can be received 610 from a processor core via a bus, and a first hardware identifier value can be associated with the processor core. For example, an incoming address translation request may be part of a DMA request. In some implementations, an incoming address translation request is received from an external device (eg, end device 222 ) via the PCIe bus.

Process 600 includes generating 620 an output address translation request including a first context identifier value stored in an item of an array indexed by the first hardware identifier value (eg, context identifier entry array 410 ). In some implementations, the array is implemented as a single-level table. In some implementations, the array is implemented as a multi-level table (eg, multi-level table 500 ), and at least some entries of the array are stored in memory accessed via the bus. For example, the first level of a multi-level table may have entries that include pointers to the next level of the multi-level table. Arrays can be configured and maintained by host software, such as a hypervisor. For example, process 700 of FIG. 7 may be implemented via a host interface to update an array. In some implementations, the entry of the array indexed by the first hardware identifier value includes a translation tag indicating the privilege level, virtualization mode, and translation mode, and the translation tag is included in the outgoing address translation request. For example, the privilege level may be from a set of privilege levels including a machine privilege level and an administrator privilege level. For example, the transition pattern may be from a set of transition patterns including a single-phase transition pattern, G-phase-only pattern, VS-phase-only, and nested transition patterns.

Process 600 includes applying 630 an output address translation request to an address translation buffer (eg, an address translation cache). Items in the address translation buffer include tags including fields for storing context identifiers. For example, the address translation buffer may be a translation lookaside buffer. In some implementations, the address translation buffer is part of a second-level address translation cache.

7 is a flowchart of an example of a process 700 for updating an array of context identifier lookup circuits based on a write request from a host. Process 700 includes receiving 710 a write request from a host. For example, a host may be a program running on a processor core of an integrated circuit including a context identifier lookup circuit. Process 700 includes checking 720 the privilege level of the host. If (at 725) the privilege level requirements are met, the procedure 700 includes updating 730 the entries of the array based on the write request. If (at 725 ) the privilege level requirements are not met, procedure 700 includes denying 740 the write request. In some implementations, checking 720 the privilege level of the host includes checking 720 that the host writing to the array has a machine privilege level prior to updating 730 an item of the array. In some implementations, checking 720 the privilege level of the host includes checking 720 that the host writing to the array has an administrator privilege level prior to updating 730 an item of the array. In some implementations, checking 720 the privilege level of the host includes checking 720 that the host writing to the array has a hypervisor prior to updating 730 an entry in the array. For example, procedure 700 may be implemented using system 100 of FIG. 1 . For example, routine 700 may be implemented using integrated circuit 210 of FIG. 2 . For example, program 700 may be implemented using address translation engine 300 of FIG. 3 . For example, procedure 700 may be implemented using context identifier lookup circuit 400 of FIG. 4 .

In a first aspect, the subject matter described in this specification can be embodied in an integrated circuit for executing instructions, the integrated circuit including an address translation buffer, wherein the entries of the address translation buffer include tags, the tags include storage context identification and a context identifier lookup circuit storing the context identifier in an array indexed by the hardware identifier, wherein the context identifier lookup circuit is configured to: receive an input bit comprising a first hardware identifier value an address translation request; generate an output address translation request, the output address translation request including a first context identifier value stored in an entry of an array indexed by a first hardware identifier value; and applying the output address translation request to address translation buffer.

In a second aspect, the subject matter described in this specification can be embodied in a method comprising receiving an input address translation request comprising a first hardware identifier value; generating an output address translation request comprising storing in a the first context identifier value in an entry of the array indexed by the symbol value; and applying the output address translation request to an address translation buffer, wherein the address translation buffer entry includes a tag for a field storing the context identifier.

Although the present disclosure has been described in connection with certain embodiments, it should be understood that the present disclosure is not limited to the disclosed embodiments, but instead, is intended to cover various modifications and equivalent arrangements included in the patent scope of the appended application, The scope should be given the broadest interpretation to cover all such modifications and equivalent constructions.

100, 200: system 110: Processor core complex 120:Memory Interconnect 130:Memory Subsystem 140:IO device 150:Address translation engine 152: IO bridge 210: Integrated circuit 212: processor core 214: System Architecture 216: Memory controller 218: System memory 220: PCIe controller 222, 224, 226: terminal device 228: switch 230:Address conversion engine 232: Address conversion buffer 240: Context identifier (CID) lookup circuit 300: address translation engine 310: address conversion buffer 320:Page table walkthrough 330: license check circuit 340, 400: CID search circuit 350: host interface circuit 410: Context ID item array 420: valid vector 430: Arbiter 500: multi-stage table 510: Address CID_L1 form 512, 514, 522, 532: Descriptors 520: Index CID_L2 table 530: Index CID_L3 table 540: Index CID_L4 542, 552: array 550: CID table order 600, 700: program TLB: translation lookaside buffer

The present disclosure is best understood from the following Detailed Description when read with the accompanying Drawings. It is emphasized that, according to common practice, the various features of the drawings are not to scale. On the contrary, the dimensions of the various features may be arbitrarily expanded or reduced for clarity. 1 is a block diagram of an example of a system for sharing memory with I/O devices, the system including an address translation engine for translating virtual addresses from various devices into physical addresses. 2 is a block diagram of an example of a system for sharing memory with devices connected to an integrated circuit by a bus, the system including an address translation engine including an address translation engine that enables sharing of address translation between devices. The context identifier for the context lookup circuit. 3 is a block diagram of an example of an address translation engine for mapping virtual addresses from various devices to physical addresses in a memory system. 4 is a block diagram of an example of a context identifier lookup circuit for sharing an address translation context between devices. 5 is a block diagram of an example of a multilevel table implementing an array for mapping hardware identifiers to software context identifiers in address translation requests. 6 is a flowchart of an example of a procedure for mapping a hardware identifier to a software context identifier in an address translation request, so that the address translation context can be shared among devices. 7 is a flowchart of an example of a procedure for updating an array of context identifier lookup circuits based on a write request from a host.

200: system

210: Integrated circuit

212: processor core

214: System Architecture

216: Memory controller

218: System memory

220: PCIe controller

222, 224, 226: terminal device

228: switch

230:Address translation engine

232: Address conversion buffer

240: Context identifier (CID) lookup circuit

Claims (20)

An integrated circuit comprising: an address translation buffer, wherein an entry of the address translation buffer includes a tag including a field storing a context identifier; and a context identifier lookup circuit storing the context identifiers in an array indexed by a hardware identifier, wherein the context identifier lookup circuit is configured to: receiving an incoming address translation request including a first hardware identifier value; generating an output address translation request including a first context identifier value stored in an entry of the array indexed by the first hardware identifier value; and The output translating request is applied to the translating buffer. The integrated circuit of claim 1, wherein the array is implemented as a single-level table and all entries of the array are stored in a data store of the context identifier lookup circuit. The integrated circuit of claim 1, wherein the array is implemented as a multi-level table, and at least some entries of the array are stored in a memory accessed by the context identifier lookup circuit via a bus. The integrated circuit of claim 3, wherein the context identifier lookup circuit includes a data store storing a first level of the multilevel table having entries including pointers to the next next level of the multilevel table an indicator. The integrated circuit of claim 1, wherein the context identifier lookup circuit receives the input address translation request from a processor core via a bus, and the first hardware identifier value is associated with the processor core couplet. The integrated circuit of claim 1, wherein the context identifier lookup circuit is configured to only allow programs with a machine privilege level to write to the items of the array. The integrated circuit of claim 1, wherein the context identifier lookup circuit is configured to only allow programs with an administrator privilege level to write to the items of the array. The integrated circuit of claim 1, wherein the context identifier lookup circuit is configured to only allow a hypervisor to write to the entries of the array. The integrated circuit of claim 1, wherein the address translation buffer is part of a second-level address translation cache. The integrated circuit as claimed in claim 1, wherein the address translation buffer is a translation lookaside buffer. The integrated circuit of claim 1, wherein the input address translation request is part of a direct memory access request. The integrated circuit of claim 1, wherein the input address translation request is received from an external device via a PCIe bus. The integrated circuit of claim 1, wherein the entry of the array indexed by the first hardware identifier value includes a translation tag indicating a privilege level, a virtualization mode, and a translation mode, and the translation Tags are included in the outgoing address translation request. The integrated circuit of claim 13, wherein the privilege level is from a set of privilege levels including a machine privilege level and an administrator privilege level. The integrated circuit of claim 13, wherein the switching pattern is from a set of switching patterns including a single-stage switching pattern, a G-stage-only pattern, a VS-stage-only, and a nested switching pattern. A method comprising: receiving an incoming address translation request including a first hardware identifier value; generating an outgoing address translation request including a first context identifier value stored in an entry of an array indexed by the first hardware identifier value; and The output address translation request is applied to an address translation buffer, wherein an entry of the address translation buffer includes a tag including a field storing a context identifier. The method of claim 16, wherein the array is implemented as a single-level table. The method of claim 16, wherein the array is implemented as a multi-level table and at least some entries of the array are stored in a memory accessed via a bus. The method of claim 18, wherein a first level of the multi-level table has entries including a pointer to a next next level of the multi-level table. The method of claim 16, wherein the incoming address translation request is received from a processor core via a bus, and the first hardware identifier value is associated with the processor core.

Images