Preventing unauthorized memory access using physical address access permission tables

CN116628772BActive Publication Date: 2026-10-27NVIDIA CORP
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
CN202211184308.7
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Priority Date
2022-02-14
Filing Date
2022-09-27
Publication Date
2026-10-27
Estimated Expiration
2042-09-27

AI Technical Summary

Technical Problem

[0002]然而,当请求DMA传输时,存在这样的情况,即请求中包括的物理地址不是端点(endpoint)被授权访问的物理地址

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN116628772B_ABST
    Figure CN116628772B_ABST
Patent Text Reader

Abstract

Using physical address access permission tables to prevent unauthorized memory access is disclosed. A host can translate a virtual address to a physical address of an endpoint using an address translation, and the endpoint can then submit a memory access request for the physical address. The host can grant access to the physical address in a physical address access permission table (PAAPT) of an entity in response to the address translation. Security of the address translation service can be improved based at least on verifying that a memory access request is authorized using the PAAPT. For example, an entity identifier included in the request can be used to locate a corresponding PAAPT, and the physical address can be extracted from the request and used to locate an entry indicating whether the entity corresponding to the entity identifier has permission to access the physical address. In the case that the entity has permission, the system can perform a memory access using the physical address. Otherwise, an error or fault code can be provided in response to the request.
Need to check novelty before this filing date? Find Prior Art

Description

Background Technology

[0001] PCI Express (PCIe) provides Address Translation Service (ATS), where a host can use a translation agent to translate a virtual address provided by an endpoint (e.g., a device interfaced with the root port) into a physical address in memory. The endpoint can cache the translations from the translation agent and subsequently use the physical address obtained from the cached translation to request a Direct Memory Access (DMA) transfer. Therefore, the translation agent may not need to perform translations for DMA transfers, thus reducing memory access latency and the burden on the translation agent performing the address translation.

[0002] However, when requesting a DMA transfer, there exists a situation where the physical address included in the request is not the physical address that the endpoint is authorized to access. In various cases, such as when the endpoint corresponds to an external device, it may be unreliable to trust that the endpoint will not attempt unauthorized access, and therefore ATS is often disabled. Further complicating matters, a host may include multiple virtual machines (VMs), where the endpoint is part of a trusted execution environment (TEE) of one VM, but not another VM's TEE. In this case, the host should be able to guarantee that the endpoint cannot access the memory of a VM whose TEE does not include the endpoint, but this is not always possible. Summary of the Invention

[0003] Embodiments of this disclosure relate to using physical address access permission tables to prevent unauthorized memory access. Systems and methods are disclosed that can use permission tables to verify whether an entity associated with a request for memory access to a physical address is authorized to access that physical address. The disclosed methods can be used to enhance the security of memory access, for example, in address translation services.

[0004] Unlike conventional systems (such as those described above), the disclosed method can record permissions corresponding to one or more entities and one or more physical addresses (PAs). Requests from entities for memory access using physical addresses can be authorized by determining one or more permissions granted to the entity to access the physical address.

[0005] In at least one embodiment, granting an entity permission to access a physical address may be done in response to a translation request being recorded in a physical address access permission table. For example, permission may be granted to an entity in response to a translation request, at least based on the entity being authorized to receive (translated from a logical address) a physical address. In response to receiving a memory access request associated with a physical address, the system may search for permissions granted to the entity and / or endpoint associated with the request to access that physical address. For example, an entity identifier included in the request may be used to locate the corresponding physical address access permission table, and the physical address may be extracted from the request and used to locate an entry indicating whether the entity has permission. If the entity has permission, the system may perform memory access using the physical address. Otherwise, an error or fault code may be provided in response to the request. Attached Figure Description

[0006] The system and method for preventing unauthorized memory access using a physical address access permission table are described in detail below with reference to the accompanying drawings, wherein:

[0007] Figure 1A This is an example schematic diagram of a memory access system including a physical address access permission table according to some embodiments of the present disclosure;

[0008] Figure 1B This is an example schematic diagram of a transaction mapping table according to some embodiments of the present disclosure, which may include a physical address access permission table;

[0009] Figure 2 The use of some embodiments according to this disclosure is illustrated. Figure 1A An example process for using a physical address access permission table in a memory access system to prevent unauthorized translation access;

[0010] Figure 3 This is a flowchart illustrating a method that a host can employ to prevent unauthorized access to a physical address based on a search for permissions corresponding to that physical address, according to some embodiments of the present disclosure.

[0011] Figure 4 This is a flowchart illustrating a method that a host can employ to prevent unauthorized access to a physical address by granting an entity permission to access the physical address based on identification, according to some embodiments of this disclosure.

[0012] Figure 5 This is a block diagram of an example computing device suitable for implementing some embodiments of the present disclosure; and

[0013] Figure 6 This is a block diagram of an example data center suitable for implementing some embodiments of the present disclosure. Detailed Implementation

[0014] Systems and methods related to using physical address access permission tables to prevent unauthorized memory access are disclosed. This disclosure provides an access permission table for verifying whether an entity associated with a request for memory access to a physical address is authorized to access that physical address. The disclosed methods can be used to enhance the security of memory access, for example, in address translation services.

[0015] In one or more embodiments, the system may record permissions corresponding to one or more entities and one or more physical addresses (PAs). Requests from entities for memory access using physical addresses can be authorized by determining one or more permissions to grant the entity access to that physical address.

[0016] In at least one embodiment, granting an entity permission to access a physical address may be done in response to a translation request being recorded in a physical address access permission table. For example, permission may be granted to an entity in response to a translation request, at least based on the entity being authorized to receive (translated from a virtual or logical address) a physical address. In response to receiving a memory access request associated with a physical address, the system may search for permissions granted to the entity and / or endpoint associated with the request to access that physical address. For example, an entity identifier or requester identifier included in the request may be used to locate the corresponding physical address access permission table, and the physical address may be extracted from the request and used to locate an entry indicating whether the entity has permission. If the entity has permission, the system may use the physical address to perform memory access. Otherwise, an error or fault code may be provided in response to the request.

[0017] By way of example and not limitation, the disclosed method can be implemented using the Address Translation Service (ATS) provided by PCI Express (PCIe), where a host can use a translation agent to translate a virtual address provided by an endpoint (e.g., a device interfaced with the root port) into a physical address in memory. In addition to providing data indicating the physical address to the endpoint, permissions granted to the endpoint and / or entity to access the physical address can be recorded in a Physical Address Access Permission Table (PAAPT). In at least one embodiment, each PAAPT may correspond to a corresponding entity identifier associated with an entity. Furthermore, each PAAPT may be stored in a mapping table entry (e.g., a flow table entry) for entities, which may also include a translation table for performing address translation. When an endpoint provides a memory access request for the translated address, it can include the physical address it receives in the translated address field and the entity identifier (such as a flow identifier) ​​in the flow identifier field. Therefore, this data can be used to locate the PAAPT and verify whether the endpoint is authorized to access the physical address.

[0018] In at least one embodiment, the host may include multiple virtual machines (VMs), and the endpoint may be part of a Trusted Execution Environment (TEE) of one VM, rather than part of the TEE of another VM. Using the disclosed method, the host can guarantee that the endpoint cannot access the memory of a VM whose TEE does not include the endpoint. Although permissions are described as corresponding to physical addresses, in at least one embodiment, permissions may correspond to translated addresses, such as intermediate virtual addresses. Furthermore, although permissions are described as relating to address translation, in at least one embodiment, permissions can be granted for physical addresses without address translation. By way of example and not limitation, the disclosed method can be implemented in various ATS and / or Compute Fast Link (CXL) memory systems.

[0019] The disclosed embodiments may be included in a variety of different systems, such as automotive systems (e.g., control systems for autonomous or semi-autonomous machines, perception systems for autonomous or semi-autonomous machines), systems implemented using robots, aerial systems, medical systems, rowing systems, smart area monitoring systems, systems for performing deep learning operations, systems for performing simulation operations, systems implemented using edge devices, systems including collaborative creation platforms for three-dimensional (3D) content, systems containing one or more virtual machines (VMs), systems implemented at least partially in a data center, systems implemented at least partially using cloud computing resources, and / or other types of systems.

[0020] refer to Figure 1A , Figure 1A This is an example schematic diagram of a memory access system 100 including a physical address access permission table according to some embodiments of this disclosure. It should be understood that this and other arrangements described herein are illustrative by way of example only. Other arrangements and elements (e.g., machines, interfaces, functions, sequences, functional groups, etc.) may be used in addition to or in place of the arrangements and elements shown, and some elements may be omitted entirely. Furthermore, many of the elements described herein are functional entities that can be implemented as discrete or distributed components, or in combination with other components, and in any suitable combination and in any suitable location. The various functions performed by the entities described herein can be performed by hardware, firmware, and / or software. For example, various functions can be performed by a processor executing instructions stored in memory.

[0021] Memory access system 100 may include host 102, one or more devices (such as device 104A and / or device 104B (which may also be collectively referred to as "device 104" or individually as "device 104")), managed software 106, one or more memories 108, one or more translation tables 110, one or more access permission tables 118, and other elements. One or more access permission tables 118 may also be referred to as one or more Physical Address Access Permission Tables (PAAPT). Host 102 may include interface manager 112 and memory manager 114. Device 104A or 104B may include one or more translation caches, such as translation cache 120A for device 104A and translation cache 120B for device 104B (which may also be collectively referred to as "translation cache 120" or individually as "translation cache 120").

[0022] In summary, host 102 may host managed software 106, which may include managing the execution of managed software 106. Interface manager 112 may be configured to manage communication between host 102, managed software 106, and device 104. For example, device 104 may submit a request to access one or more portions of memory 108. Memory manager 114 may be configured to manage memory 108, for example, to facilitate access to one or more portions of memory 108. For example, memory manager 114 may perform functions such as translating memory addresses using one or more translation tables 110, updating one or more translation tables 110, reading data from or writing data to locations corresponding to memory addresses, and / or allocating one or more portions of memory to one or more entities of managed software 106.

[0023] In one or more embodiments, memory manager 114 is configured to record permissions corresponding to one or more entities and one or more physical addresses (PAs) in PAAPT 118. Similarly, in at least one embodiment, memory manager 114 may be configured to verify memory access requests, such as those provided by device 104 using translation cache 120, based on the permissions recorded in PAAPT 118. In various examples, updates to PAAPT 118 may be performed by the hypervisor of host 102. As a further example, updates to PAAPT 118 may be performed by the operating system of host 102, such as in the absence of a hypervisor and / or virtualization. In various examples, PAAPT 118 may be managed by a privileged entity of host 102, which may be the same entity managing the Phase 2 address translation table (or direct virtual address to physical address translation table).

[0024] As described herein, host 102 may host managed software 106, which may include managing the execution of managed software 106. Host 102 may include any combination of hardware, software, and / or firmware that facilitates the hosting of managed software 106. By way of example and not limitation, host 102 may include one or more virtual machine managers (VMMs) such as a hypervisor, and managed software 106 may include one or more virtual machines (VMs), such as guest operating systems supported by the hypervisor. Additionally or alternatively, at least one entity of managed software 106 may include one or more processes, services, applications, and / or other software entities. Although PAAPT 118, memory 108, managed software 106, translation table 110, and device 104 are shown as being outside of host 102, any of these components may be included in host 102 and / or included on a system-on-a-chip (SoC) together with host 102. Furthermore, PAAPT 118 and / or translation table 110 may be stored at least partially in memory 108 and / or different memories. In at least one embodiment, memory 108 includes volatile memory, such as random access memory (RAM), which may include dynamic RAM (DRAM).

[0025] In at least one embodiment, device 104 may include a virtual machine (VM) or other software entity, such as the VM hosting software 106. Further examples of device 104 include hardware entities, such as peripheral hardware devices, non-limiting examples of which include a computer mouse or keyboard, expansion card, graphics card, network card, image scanner, tape drive, microphone, webcam, or digital camera. As used herein, examples of entities include hardware entities, such as hardware devices, or software entities, such as software entities.

[0026] Interface Manager 112 can be configured to manage communication between Host 102, Host Software 106, and Device 104. Interface Manager 112 can support any of a variety of host controller interfaces, such as those for Universal Serial Bus (USB), FireWire, Bluetooth, Ethernet, Peripheral Component Interconnect (PCI), PCI Express (PCIe), Near Field Communication (NFC), Vehicle-to-Everything (V2X), Car-to-Car, Cellular, WiFi, or other types of communication.

[0027] In at least one embodiment, interface manager 112 can provide address translation through one or more host controller interfaces, enabling device 104 or other entities (e.g., endpoints) to access one or more portions of memory 108. When providing the translation service, interface manager 112 can use memory manager 114 to translate addresses provided by device 104 or other endpoints into translated addresses in memory 108. Specifically, the memory manager can determine the translated address from the address using one or more translation tables 110 and / or other means. This translated address can be provided to device 104, which can store the translated address in translation cache 120. Subsequently, device 104 can use the translated address from translation cache 120 to make a memory access request to memory 108. For example, device 104 can use the translated address to request a direct memory access (DMA) transfer with memory 108. By using the translated address, memory manager 114 does not need to perform address translation for DMA.

[0028] In one or more embodiments, the address provided by device 104 may be a virtual address, and the translated address may be a physical address of memory 108 determined using one or more translation tables 110 (e.g., page tables and / or address translation and protection tables). However, certain aspects of this disclosure may be more generally applicable to address translation, which may or may not include virtual-to-physical address translation.

[0029] As an example, in at least one embodiment, interface manager 112 supports PCIe and includes a root complex (RC) for providing address translation service (ATS), and device 104 can communicate with host 102 via a root port managed by the RC. When providing ATS, interface manager 112 can use a translation agent of memory manager 114 to translate virtual addresses provided by device 104 into physical addresses in memory 108. For example, memory manager 114 may include an input-output memory management unit (IOMMU) that uses system memory management unit (SMMU) page tables 110 in one or more translation tables 110 for ATS.

[0030] When a DMA transfer is requested, there is a chance that the address provided by device 104 is not an address that device 104 is authorized to access. As a further complication, device 104 may be part of a Trusted Execution Environment (TEE) of a VM or other entity hosting software 106, rather than part of the TEE of another VM. Embodiments of this disclosure allow host 102 to guarantee that device 104 cannot access one or more portions of memory 108 associated with a VM whose TEE does not include device 104, even if device 104 provides a physical address associated with that VM.

[0031] To this end, memory manager 114 may record permission information, such as entries in PAAPT 118, which can be used to determine whether a requesting entity has one or more permissions to access one or more specific physical addresses. The permissions of one or more entities may be recorded and / or updated at any appropriate time. In at least one embodiment, based at least on an address translation request, memory manager 114 may translate an address provided by device 104 or other endpoints into a translated address in memory 108. Also based at least on an address translation request, memory manager 114 may record one or more permissions corresponding to the translated address (e.g., a physical address) and device 104 or other endpoints. When device 104 or other entity provides a memory access request, memory manager 114 may search one or more PAAPT 118s to verify whether the entity associated with the request is authorized to access one or more physical addresses associated with the request. For example, memory manager 114 may determine whether data provided by device 104 in connection with the request matches or otherwise corresponds to one or more entity identifiers and one or more physical addresses for which permissions have been granted according to one or more PAAPT 118s. If the memory manager 114 determines that the request does not correspond to the encrypted information, the request can be rejected. In at least one embodiment, a status code (such as an error or fault code) can be provided to the device 104 in response to an unauthorized request.

[0032] The memory manager 114 can implement various potential methods to generate and / or manage one or more PAAPTs 118. In at least one embodiment, the memory manager 114 can generate and / or manage one or more PAAPTs 118 for each device 104 and / or entity, or it can employ one or more PAAPTs 118 for a group of devices and / or entities.

[0033] In at least one embodiment, PAAPT 118 and / or one or more entries thereof may be stored in association with an entity ID, and / or may be identified for verifying permissions at least based on the entity ID associated with a request for memory access. The entity ID may correspond to an identifier of a single entity or a group of entities. For example, where the entity corresponds to a requester, the entity ID may be included in the request (e.g., by the entity). In such examples, the entity ID may correspond to a requester ID (the ID of the entity making the request). The memory manager 114 may use the entity ID to determine PAAPT 118 and / or one or more entries (if any) associated with the entity. In various examples, where the entity is a VM on a device, the entity ID may correspond to the VM ID of the VM, and each VM may have a different VM ID. In a further example, where the entity is a device, the entity ID may correspond to the device ID of that device, and each device may have a different device ID. Using device IDs may be particularly suitable for interfaces that do not readily or implicitly support lower-level IDs.

[0034] Also in at least one embodiment, PAAPT 118 and / or one or more entries thereof may be stored in association with physical addresses, and / or may be identified for verifying permissions at least based on the physical address associated with a request for memory access. For example, the request may include data indicating and / or identifying the physical address against which memory access is requested. In at least one embodiment, the request may include a physical address. By way of example and not limitation, the request may include a physical address in a system where address translation is unavailable or in a system that supports ATS. Additionally or alternatively, the request may include data used by memory manager 114 to identify physical addresses (e.g., translating virtual or intermediate addresses to physical addresses). In various examples, memory manager 114 may index or otherwise arrange one or more of PAAPT 118 by physical address and / or physical address range.

[0035] In at least one embodiment, the memory manager 114 uses an entity ID to identify the corresponding PAAPT 118. The memory manager 114 may also use a physical address to identify an entry in the corresponding PAAPT 118. This entry can indicate whether the entity corresponding to the entity ID has permission to access the physical address. In at least one embodiment, permissions for one or more physical addresses can be recorded in the PAAPT 118 using one or more permission bits. For example, a single permission bit can be used to record permissions, having a first value (e.g., 1) corresponding to allowed access and a second value (e.g., 0) corresponding to denied access. In other examples, more than one bit can be used. Furthermore, permissions for one or more specific physical addresses can be subdivided by access type, such as read, write, etc. However, using a single bit to record a single permission allows for a small memory size while still being suitable for many applications, including ATS.

[0036] In at least one embodiment, PAAPT 118 may include one or more permission bits indexed by one or more physical addresses (e.g., a single physical address or a range or other group of physical addresses). In at least one embodiment, PAAPT 118 may be stored in a page table format, wherein PAAPT 118 may store a mapping between physical addresses and permission bits, rather than storing a mapping between logical addresses and physical addresses as in a page table. In at least one embodiment, PAAPT 118 may store one or more permission bits per page, such as a single permission bit per page. Using a single permission bit per page allows more entries to be maintained in the permission check cache, which the memory manager 114 can use to verify permissions without having to go to memory to perform a lookup in PAAPT 118, thereby improving performance. For example, using a single permission bit per page allows table compression, where an entire address range can be packed. For example, the permissions of entries in PAAPT 118 can form a bitmap, thereby allowing bitmap compression.

[0037] In one or more embodiments, one or more PAAPT 118s may be stored using one or more translation granules of the address translation table of the memory access system 100. For example, PAAPT 118 may be stored using the smallest granule of the memory access system 100. Non-limiting examples include 4kb, 64kb, or 16KB granules. PAAPT 118 may correspond to a multi-level table structure, such as a two-level structure. The top level of PAAPT 118 may include a pointer to the next level table or the top level. By way of example and not limitation, PAAPT 118 may include 32-bit leaf entries. Each bit may cover at least 4kb of permissions. Thus, assuming a 4-byte word, permissions for 128kb of memory 108 can be recorded using 32-bit entries. In the page table, each entry is 64 bytes and provides translation for a 4kb page. By configuring PAAPT 118 in a page table format, permissions for 32 4kb pages can be packaged into a single 4-byte structure. However, various storage formats for one or more PAAPT 118s are compatible with this disclosure. One or more PAAPT 118s can be stored as one or more linked tables, or have a fixed size, or be stored using a combination of storage formats.

[0038] In at least one embodiment, one or more PAAPT 118s may be stored in one or more transaction mapping tables, examples of which are as follows: Figure 1B As shown. Now refer to Figure 1B , Figure 1B This is an example schematic diagram of a transaction mapping table 124 according to some embodiments of the present disclosure, which may include a physical address access permission table. The transaction mapping table 124 may include one or more mapping table entries 126A to 126N (which may also be referred to as "mapping table entry 126"). In embodiments where PAAPT 118 is included in an ARM architecture, the transaction mapping table 124 may be a flow entry table, and its mapping table entry 126 is a flow table entry. However, this is not intended to be limiting, and PAAPT 118 may be incorporated into other architectures and addressing structures and / or systems.

[0039] In at least one embodiment, a flow ID can be used to map transactions (such as transactions corresponding to memory access requests or address translation requests) to corresponding mapping table entries 126. Also in at least one embodiment, a flow ID can be used as an entity ID. For example, each flow ID from the same device can point to the same PAAPT 118. Therefore, one or more embodiments may use entity IDs defined, assigned, specified, and / or managed by the memory access interface. Using such entity IDs allows the use of the memory access interface's security mechanisms to prevent potential security issues, such as entity ID spoofing, without additional mechanisms. For example, PCIe includes security checks to ensure that the requesting device makes the request via an encrypted secure link and that the flow ID is within the range permitted for device use. In other examples, entity IDs and / or security mechanisms independent of the memory access interface may be included.

[0040] By way of example and not limitation, each mapping table entry 126A may include a stage configuration 130, one or more stage 1 context pointers 132, a VM identifier 134, one or more stage 2 table pointers 136, and one or more access permission table pointers 138. In at least one embodiment, in addition to or in place of a flow ID, the VM identifier 134 may also be used as an entity ID. In one or more embodiments, each VM is assigned a VM identifier that can be used to mark a Translation Backing Buffer (TLB) entry to identify which entry belongs to which VM. This marking can be used to allow translations for multiple different VMs to coexist in the TLB. In at least one embodiment, this marking can additionally or alternatively be used to allow permissions for multiple different VMs and / or entities to coexist in one or more physical address permission caches. Furthermore, in one or more embodiments, the VM may be an entity of a different type described herein.

[0041] Stage configuration 130 can be used to configure the type of transformation associated with mapping table entry 126. For example, stage configuration 130 can be used to select between bypassing both stage 1 and stage 2 transformations, using stage 1 transformations and bypassing stage 2 transformations, bypassing stage 1 transformations and using stage 2 transformations, using both stage 1 and stage 2 transformations, and / or other transformation modes or stages that the system can support. The disclosed methods can be used in conjunction with any of these various configurations. For example, in at least one embodiment, the configuration bits can indicate to memory manager 114 that both stage 1 and stage 2 are disabled, and memory manager 114 can still use mapping table entry 126 to verify permissions for physical addresses.

[0042] Phase 1 can be configured to translate a virtual address into a physical address or into an intermediate virtual address, depending on the mode selected by phase configuration 130 and / or the modes supported by the system. Phase 2 can be configured to translate an intermediate virtual address into a physical address. Although this example includes two phases, any number of phases, such as a single phase, can be used in various embodiments.

[0043] The Stage 1 context pointer 132 may point to a context descriptor 140 (e.g., a context descriptor table). The context descriptor 140 may include data defining how Stage 1 transformations are performed and may include one or more Stage 1 table pointers 142. One or more Stage 1 table pointers 142 may point to one or more Stage 1 transformation tables 110A used for transformations in Stage 1. In other examples, the context descriptor 140 may not need to include Stage 1 table pointers 142 or may not need to be included in mapping table entry 126A.

[0044] One or more Stage 2 table pointers 136 may point to one or more Stage 2 transition tables 110B used for transitions in Stage 2. Additionally, one or more access permission table pointers 138 may point to one or more PAAPT 118A used to verify memory access permissions for one or more entities.

[0045] In at least one embodiment, as part of registering one or more entities with memory access system 100 for memory access, memory manager 114 or other components may generate one or more mapping table entries 126 for one or more entities. For example, mapping table entries 126 for a device may be generated at least based on a device connecting to host 102 and / or requesting registration with memory access system 100. In at least one embodiment, mapping table entries 126 for entities may be generated as part of the startup process of an operating system (OS) (such as the OS and / or VM of host 102). For example, when the operating system starts, the operating system may identify and / or check devices associated with the operating system. Based on this identification, the operating system may register the corresponding mapping table entry 126. In embodiments where PAAPT 118 is included in mapping table entry 126, PAAPT 118 and / or one or more of its permissions may be generated, assigned, and / or updated as part of the device and / or entity registration process (e.g., as part of generating mapping table entry 126).

[0046] Additionally or alternatively, PAAPT 118 and / or one or more of its permissions may be generated, assigned, and / or updated at other suitable times. For example, PAAPT 118 and / or one or more of its permissions may be generated, assigned, and / or updated for an entity based at least on a translation request from and / or associated with that entity. For example, the request may include and / or indicate an entity ID, such as a stream ID, which memory manager 114 or other components may use to identify the mapping table entry 126 of PAAPT 118. Furthermore, the request may include and / or indicate an address to be translated, such as an intermediate virtual address. In response to a translation request, memory manager 114 or other components may use that address, for example, based at least on the result of the translation, to determine the physical address for which one or more permissions have been granted.

[0047] Memory manager 114 and / or other components of memory access system 100 may use one or more transaction mapping tables 124 for address translation. For example, transaction mapping table 124 may be used to map transactions to transaction flows and their corresponding translation contexts. In at least one embodiment, granting access to an entity or endpoint may be terminated in association with the invalidation of the entity's or endpoint's translation cache (e.g., upon determining that a predetermined period of time has elapsed, upon determining that an entity of managed software 106 has revoked access to and / or modified the translated address, upon determining that the translated address no longer belongs to the entity, based on termination of the entity owning the translated address, etc.).

[0048] The memory manager 114 can assign one or more permissions to one or more specific entities (e.g., device 104), functions, and / or processes. Furthermore, the memory manager 114 can store such assignments in one or more PAAPTs 118 for use in verifying permissions from entities for future communication. The memory manager 114 can generate and / or assign permissions at any appropriate time.

[0049] In embodiments where managed software 106 includes a VM, memory manager 114 can assign permissions for devices, functions, processes, etc., at least based on the movement of entities (e.g., endpoints) into the TEE of the VM. For example, in response to a request to move an entity into the TEE, memory manager 114 can generate and / or assign one or more permissions to the entity (e.g., one permission per entity, process, and / or function). As a further example, permissions can be generated or assigned in response to address translation requests from entities. In at least one embodiment, memory manager 114 can store permissions in one or more PAAPTs 118 by entity, function, process, and / or session.

[0050] The memory manager 114 can access one or more PAAPTs 118 to generate and / or grant entities permissions to physical addresses and / or verify one or more requests from entities. For example, the memory manager 114 can use information provided by and / or associated with the entity (e.g., in requests from the entity) as lookup criteria to access one or more associated entries used to generate PAAPT 118 and / or generate or update PAAPT 118 and / or one or more of its permissions.

[0051] In at least one embodiment, in response to a translation request, memory manager 114 grants one or more permissions. For example, memory manager 114 may include providing a translated address and granting one or more permissions for the translated address in response to a translation request. In at least one embodiment, memory manager 114 may receive a translation request from device 104. Among other potential information, the translation request may include data indicating the address to be translated (e.g., a virtual address). In response to the request, memory manager 114 may look up the address in translation table 110 and receive the corresponding translated address (e.g., a system physical address). Memory manager 114 may also generate and / or access one or more entries in PAAPT 118 associated with the translated address to grant one or more permissions.

[0052] In at least one embodiment, memory manager 114 can verify translated requests based on one or more permissions associated with one or more translated addresses. For example, host 102 may receive translated requests (e.g., memory access requests, such as DMA requests) from device 104. Memory manager 114 can analyze the translated requests to verify whether an entity has one or more permissions associated with a translated address authorized for requesting endpoints, processes, and / or functions. In at least one embodiment, the translated address can be extracted from the translated address field of the request, and the entity ID can be extracted from the entity ID field of the request. The extracted data can then be used to look up one or more entries in PAAPT 118 (if they exist).

[0053] If the memory manager 114 fails to recognize the corresponding permissions, the request will result in an error or fault code, which may be provided to the device 104. If the information is recognized, the request may match or otherwise correspond to the permissions assigned to an endpoint, process, function, etc.

[0054] As described herein, if memory manager 114 determines that the permissions do not match or do not otherwise correspond to the request, the request will result in an error or fault code, which may be provided to device 104. Otherwise, memory manager 114 may use the translated address provided by the request, for example, to perform a memory access at the corresponding location in memory 108. Memory manager 114 may also provide device 104 with data indicating successful verification and / or execution of the translated request in response to the request, such as a success code and / or retrieved data. The disclosed methods can be implemented entirely in hardware without modification to managed software 106.

[0055] Now for reference Figure 2 , Figure 2 An example process 200 is illustrated in which a physical address access permission table is used in the memory access system 100 of FIG1 to prevent unauthorized translated access, according to some embodiments of the present disclosure. Process 200 may include a device 104A providing a translation request 202 (e.g., an ATS request) to a host 102. An interface manager 112 may receive the translation request 202 and provide data corresponding to the translation request 202 to a memory manager 114. The memory manager 114 may perform a translation 204 of the address provided in the translation request 202 using one or more translation tables 110. For example, the memory manager 114 may retrieve a translated address from the translation table 110. The memory manager 114 may also perform a permission record 206 to grant permissions for memory access. This may include, for example, generating and / or updating one or more permission bits in an entry of PAAPT 118 corresponding to the translated address, function, and / or process of device 104A. The memory manager 114 may provide a translated address for a translation response 208, which the interface manager 112 may provide to device 104A.

[0056] Device 104A can perform translation caching 210 (such as ATS completion) on information extracted from translation response 208 (e.g., values ​​in the translated address field) in translation cache 120A. Device 104A can then perform cache access 212 on translation cache 120A to retrieve cached information for inclusion in access request 214 (or translated request), such as a DMA request. Device 104A can provide access request 214 to host 102. Interface manager 112 can receive access request 214 and provide data corresponding to access request 214 to memory manager 114. Memory manager 114 can use the data provided in access request 214 (e.g., values ​​in the translated address field) to perform permission checks 216. For example, memory manager 114 can use the entity ID corresponding to or associated with access request 214 for device 104A, function, and / or process to look up permissions (e.g., to identify the corresponding PAAPT 118). The memory manager 114 can also use a translated address identified from or associated with the access request 214 to look up permissions (e.g., to identify the corresponding entry in PAAPT 118).

[0057] If permission to access the translated address is granted, the memory manager 114 can determine whether the access request 214 is authorized. In response to determining that the access request 214 is authorized, the memory manager 114 can use the translated address to perform a memory access 218 to the memory 108 at the location corresponding to the translated address (e.g., to retrieve the corresponding page). In embodiments where memory access 218 is used to retrieve data, the memory manager 114 can provide the data retrieved by memory access 218 to be included in one or more access responses 220 sent to the device 104A. Otherwise, the memory manager 114 can provide a status code or other indicator for a successful memory access to the device 104A. In embodiments where permission to access the translated address is not granted, the access response can include a status code or other indicator, such as a fault or error code, for an unsuccessful memory access.

[0058] See Figure 3Each box of Method 300, and other methods described herein, include computational processes that can be performed using any combination of hardware, firmware, and / or software. For example, various functions can be performed by a processor executing instructions stored in memory. These methods can also be embodied as computer-usable instructions stored on a computer storage medium. These methods can be provided by standalone applications, services, or managed services (independently or in conjunction with another managed service) or plug-ins to another product, to name a few. Furthermore, examples are provided regarding… Figure 1A The system describes the method. However, the method may be performed additionally or alternatively by any one system, or by any combination of systems, including but not limited to those described herein.

[0059] Figure 3 This is a flowchart illustrating a method 300 that a host can employ to prevent unauthorized access to physical addresses based on searching for permissions corresponding to those physical addresses, according to some embodiments of this disclosure. At block B302, method 300 includes recording permissions corresponding to one or more physical addresses. For example, the memory manager 114 of host 102 may record permissions granted to one or more entities to access one or more physical addresses in one or more entries of PAAPT 118, wherein these entries correspond to one or more physical addresses.

[0060] At block B304, method 300 includes receiving data corresponding to a request for memory access to a physical address. For example, memory manager 114 may receive data corresponding to a request for memory access to a physical address.

[0061] At box B306, method 300 includes searching for permissions corresponding to a physical address. For example, memory manager 114 may search one or more PAAPTs 118 to obtain permissions corresponding to the physical address and entities associated with the request for memory access.

[0062] At box B308, method 300 includes providing a response to the request. For example, memory manager 114 may provide a response to the request based at least on the results of searching one or more PAAPTs 118.

[0063] refer to Figure 4 , Figure 4This is a flowchart illustrating a method 400 that a host can employ to prevent unauthorized access to a physical address based on the permissions granted to an entity for accessing that physical address, according to some embodiments of this disclosure. At B402, method 400 includes: recording the permissions granted to an entity for accessing the physical address. For example, the memory manager 114 of host 102 may record the permissions granted to an entity for accessing the physical address in PAAPT 118.

[0064] At B404, method 400 includes receiving data corresponding to a request for memory access to a physical address. For example, memory manager 114 may receive data corresponding to a request for memory access to a physical address.

[0065] At B406, method 400 includes: identifying the permissions granted to an entity to access a physical address. For example, memory manager 114 may identify the permissions granted to an entity to access a physical address based at least on the association between the entity and a request for memory access.

[0066] At B408, method 400 includes enabling memory access to physical addresses. For example, memory manager 114 may enable memory access to physical addresses at least based on recognized permissions.

[0067] Example computing device

[0068] Figure 5 This is a block diagram of an example computing device 500 suitable for implementing some embodiments of the present disclosure. The computing device 500 may include an interconnect system 502 directly or indirectly coupled to: a memory 504, one or more central processing units (CPUs) 506, one or more graphics processing units (GPUs) 508, a communication interface 510, input / output (I / O) ports 512, input / output components 514, a power supply 516, one or more presentation components 518 (e.g., one or more displays), and one or more logic units 520. In at least one embodiment, one or more computing devices 500 may include one or more virtual machines (VMs), and / or any component of its components may include virtual components (e.g., virtual hardware components). For a non-limiting example, one or more GPUs 508 may include one or more vGPUs, one or more CPUs 506 may include one or more vCPUs, and / or one or more logic units 520 may include one or more virtual logic units. Accordingly, one or more computing devices 500 may include discrete components (e.g., a full GPU dedicated to computing device 500), virtual components (e.g., a portion of the GPU dedicated to computing device 500), or a combination thereof.

[0069] although Figure 5 The various blocks are shown connected via an interconnect system 502 with wiring, but this is not intended to be limiting and is merely for clarity. For example, in some embodiments, a presentation component 518, such as a display device, may be considered an I / O component 514 (e.g., if the display is a touchscreen). As another example, CPU 506 and / or GPU 508 may include memory (e.g., memory 504 may represent a storage device other than the memory of GPU 508, CPU 506, and / or other components). In other words, Figure 5 The computing devices mentioned are merely illustrative. No distinction is made between categories such as "workstation," "server," "laptop," "desktop," "tablet," "client device," "mobile device," "handheld device," "game console," "electronic control unit (ECU)," "virtual reality system," and / or other device or system types, as all of these are considered within the same category. Figure 5 Within the scope of computing devices.

[0070] Interconnect system 502 may represent one or more links or buses, such as address buses, data buses, control buses, or combinations thereof. Interconnect system 502 may include one or more bus types, such as Industry Standard Architecture (ISA) buses, Extended Industry Standard Architecture (EISA) buses, Video Electronics Standards Association (VESA) buses, Peripheral Component Interconnect (PCI) buses, Peripheral Component Interconnect Fast (PCIe) buses, and / or another type of bus or link. In some embodiments, there is a direct connection between components. As an example, CPU 506 may be directly connected to memory 504. Furthermore, CPU 506 may be directly connected to GPU 508. In cases where there is a direct or point-to-point connection between components, interconnect system 502 may include a PCIe link to perform the connection. In these examples, a PCI bus is not required in computing device 500.

[0071] The memory 504 may include any medium of a wide variety of computer-readable media. A computer-readable medium can be any available medium that can be accessed by the computing device 500. Computer-readable media may include volatile and non-volatile media, as well as removable and non-removable media. For example and without limitation, computer-readable media may include computer storage media and communication media.

[0072] Computer storage media may include volatile and non-volatile media and / or removable and non-removable media, implemented in any way or by any method or technique for storing information such as computer-readable instructions, data structures, program modules, and / or other data types. For example, memory 504 may store computer-readable instructions (e.g., representing programs and / or program elements, such as an operating system). Computer storage media may include, but is not limited to, RAM, ROM, EEPROM, flash memory or other storage technologies, CD-ROM, digital versatile disc (DVD) or other optical disc storage devices, magnetic tape cassettes, magnetic tape, disk storage devices or other magnetic storage devices, or any other medium that can be used to store desired information and can be accessed by computing device 500. As used herein, computer storage media does not include the signal itself.

[0073] Computer storage media may contain computer-readable instructions, data structures, program modules, and / or other data types in modulated data signals such as carrier waves or other transmission mechanisms, and include any information transport medium. The term "modulated data signal" can refer to a signal whose characteristics are set or altered in a manner that encodes information into that signal. For example and without limitation, computer storage media may include wired media such as wired networks or direct wired connections, and wireless media such as sound, RF, infrared, and other wireless media. Any combination of the above should also be included within the scope of computer-readable media.

[0074] CPU 506 may be configured to execute at least some computer-readable instructions to control one or more components of computing device 500 to perform one or more of the methods and / or processes described herein. Each of CPU 506 may include one or more cores (e.g., one, two, four, eight, twenty-eight, seventy-two, etc.) capable of processing a large number of software threads simultaneously. CPU 506 may include any type of processor and may include different types of processors depending on the type of computing device 500 implemented (e.g., processors with fewer cores for mobile devices and processors with more cores for servers). For example, depending on the type of computing device 500, the processor may be an advanced RISC machine (ARM) processor implemented using Reduced Instruction Set Computing (RISC) or an x86 processor implemented using Complex Instruction Set Computing (CISC). In addition to one or more microprocessors or supplementary coprocessors such as math coprocessors, computing device 500 may also include one or more CPUs 506.

[0075] In addition to or in place of CPU 506, GPU 508 may be configured to execute at least some computer-readable instructions to control one or more components of computing device 500 to perform one or more methods and / or processes described herein. One or more GPUs 508 may be integrated GPUs (e.g., having one or more CPUs 506) and / or one or more GPUs 508 may be discrete GPUs. In embodiments, one or more GPUs 508 may be coprocessors of one or more CPUs 506. Computing device 500 may use GPUs 508 to render graphics (e.g., 3D graphics) or perform general-purpose computing. For example, GPUs 508 may be used for general-purpose computing on a GPU (GPGPU). GPUs 508 may include hundreds or thousands of cores capable of processing hundreds or thousands of software threads simultaneously. GPUs 508 may generate pixel data for outputting an image in response to rendering commands (e.g., rendering commands received from CPUs 506 via a host interface). GPUs 508 may include graphics memory, such as display memory, for storing pixel data or any other suitable data, such as GPGPU data. Display memory may be included as part of memory 504. 508 may include two or more GPUs operating in parallel (e.g., via a link). The link may connect the GPUs directly (e.g., using NVLINK) or via a switch (e.g., using NVSwitch). When combined, each GPU 508 may generate pixel data or GPGPU data for different portions of the output or different outputs (e.g., a first GPU for a first image and a second GPU for a second image). Each GPU may include its own memory or may share memory with other GPUs.

[0076] In addition to or replacing CPU 506 and / or GPU 508, logic unit 520 may be configured to execute at least some computer-readable instructions to control one or more components of computing device 500 to perform one or more methods and / or processes described herein. In embodiments, CPU 506, GPU 508, and / or logic unit 520 may perform any combination of methods, processes, and / or portions thereof, discretely or jointly. One or more logic units 520 may be part of and / or integrated with one or more of CPU 506 and / or GPU 508, and / or one or more logic units 520 may be discrete components or otherwise external to CPU 506 and / or GPU 508. In embodiments, one or more logic units 520 may be coprocessors of one or more CPUs 506 and / or one or more GPUs 508.

[0077] Examples of logic unit 520 include one or more processing cores and / or components thereof, such as a data processing unit (DPU), tensor core (TC), tensor processing unit (TPU), pixel vision core (PVC), vision processing unit (VPU), graphics processing cluster (GPC), texture processing cluster (TPC), streaming multiprocessor (SM), tree traversal unit (TTU), artificial intelligence accelerator (AIA), deep learning accelerator (DLA), arithmetic logic unit (ALU), application-specific integrated circuit (ASIC), floating-point unit (FPU), input / output (I / O) element, peripheral component interconnect (PCI) or peripheral component interconnect fast (PCIe) element, etc.

[0078] Communication interface 510 may include one or more receivers, transmitters, and / or transceivers that enable computing device 500 to communicate with other computing devices via electronic communication networks, including wired and / or wireless communications. Communication interface 510 may include components and functions that enable communication via any of several different networks, such as wireless networks (e.g., Wi-Fi, Z-Wave, Bluetooth, Bluetooth LE, ZigBee, etc.), wired networks (e.g., via Ethernet or wireless bandwidth communication), low-power wide area networks (e.g., LoRaWAN, SigFox, etc.), and / or the Internet. In one or more embodiments, one or more logic units 520 and / or communication interface 510 may include one or more data processing units (DPUs) for directly transmitting data received via a network and / or via interconnect system 502 to one or more GPUs 508 (e.g., their memory).

[0079] I / O port 512 enables computing device 500 to be logically coupled to other devices, including I / O component 514, presentation component 518, and / or other components, some of which may be built into (e.g., integrated into) computing device 500. Illustrative I / O component 514 includes microphones, mice, keyboards, joysticks, game pads, game controllers, satellite dish antennas, scanners, printers, wireless devices, and so on. I / O component 514 can provide a Natural User Interface (NUI) for processing user-generated air gestures, voice, or other physiological input. In some instances, the input may be transmitted to appropriate network elements for further processing. The NUI can implement any combination of voice recognition, stylus recognition, facial recognition, biometric recognition, on-screen and adjacent-screen gesture recognition, air gestures, head and eye tracking, and touch recognition associated with the display of computing device 500 (described in more detail below). Computing device 500 may include depth cameras such as stereo camera systems, infrared camera systems, RGB camera systems, touchscreen technology, and combinations thereof for gesture detection and recognition. In addition, computing device 500 may include an accelerometer or gyroscope that enables motion detection (e.g., as part of an inertial measurement unit (IMU)). In some examples, the output of the accelerometer or gyroscope may be used by computing device 500 to render immersive augmented reality or virtual reality.

[0080] Power supply 516 may include a hard-wired power supply, a battery power supply, or a combination thereof. Power supply 516 may supply power to computing device 500 so that the components of computing device 500 can operate.

[0081] Presentation component 518 may include a display (e.g., a monitor, touchscreen, television screen, head-up display (HUD), other display types, or combinations thereof), speakers, and / or other presentation components. Presentation component 518 may receive data from other components (e.g., GPU 508, CPU 506 DPU, etc.) and output that data (e.g., as images, videos, sounds, etc.).

[0082] Example Data Center

[0083] Figure 6 An example data center 600 that can be used in at least one embodiment of this disclosure is shown. The data center 600 may include a data center infrastructure layer 610, a framework layer 620, a software layer 630, and / or an application layer 640.

[0084] like Figure 6As shown, the data center infrastructure layer 610 may include a resource coordinator 612, grouped computing resources 614, and node computing resources (“nodes CR”) 616(1)-616(N), where “N” represents any complete positive integer. In at least one embodiment, nodes CR 616(1)-616(N) may include, but are not limited to, any number of central processing units (“CPUs”) or other processors (including DPUs, accelerators, field-programmable gate arrays (FPGAs), graphics processing units or graphics processing units (GPUs), etc.), memory devices (e.g., dynamic read-only memory), storage devices (e.g., solid-state drives or disk drives), network input / output (“NW I / O”) devices, network switches, virtual machines (“VMs”), power modules and / or cooling modules, etc. In some embodiments, one or more nodes CR 616(1)-616(N) may correspond to servers having one or more of the aforementioned computing resources. In addition, in some embodiments, nodes CR616(1)-616(N) may include one or more virtual components, such as vGPU, vCPU, etc., and / or one or more of nodes CR616(1)-616(N) may correspond to virtual machines (VMs).

[0085] In at least one embodiment, the grouped computing resources 614 may include individual groups (not shown) of node CR616 housed in one or more racks, or a plurality of racks (also not shown) housed in data centers in various geographic locations. Individual groups of node CRs within the grouped computing resources 614 may include computing, networking, memory, or storage resources that can be configured or allocated to support groups of one or more workloads. In at least one embodiment, several node CR616, including CPUs, GPUs, DPUs, and / or other processors, may be grouped within one or more racks to provide computing resources to support one or more workloads. One or more racks may also include any number of power modules, cooling modules, and / or network switches, in any combination.

[0086] Resource coordinator 612 can be configured or otherwise controlled to control one or more nodes CR616(1)-616(N) and / or groups of computing resources 614. In at least one embodiment, resource coordinator 612 may include a Software Design Infrastructure (“SDI”) management entity for data center 600. Resource coordinator 612 may include hardware, software, or some combination thereof.

[0087] In at least one embodiment, such as Figure 6As shown, framework layer 620 may include a job scheduler 632, a configuration manager 634, a resource manager 636, and / or a distributed file system 638. Framework layer 620 may include a framework of software 633 supporting software layer 630 and / or one or more applications 642 supporting application layer 640. Software 633 or application 642 may respectively include web-based service software or applications, such as services or applications provided by Amazon Web Services, Google Cloud, and Microsoft Azure. Framework layer 620 may be, but is not limited to, a free and open-source software web application framework, such as Apache Spark, which can utilize distributed file system 638 for large-scale data processing (e.g., "big data"). TM (Hereinafter referred to as "Spark"). In at least one embodiment, job scheduler 632 may include Spark drivers to facilitate the scheduling of workloads supported by various layers of data center 600. Configuration manager 634 may be able to configure different layers, such as software layer 630 and framework layer 620 including Spark and distributed file system 638 for supporting large-scale data processing. Resource manager 636 is able to manage cluster or grouped computing resources mapped to or allocated to support distributed file system 638 and job scheduler 632. In at least one embodiment, cluster or grouped computing resources may include grouped computing resources 614 on data center infrastructure layer 610. Resource manager 636 may coordinate with resource coordinator 612 to manage these mapped or allocated computing resources.

[0088] In at least one embodiment, the software 633 included in the software layer 630 may include software used by at least a portion of nodes CR616(1)-616(N), grouped computing resources 614, and / or the distributed file system 638 of the framework layer 620. One or more types of software may include, but are not limited to, Internet web page search software, email virus scanning software, database software, and streaming video content software.

[0089] In at least one embodiment, one or more applications 642 included in application layer 640 may include one or more types of applications used by at least a portion of nodes CR616(1)-616(N), grouped computing resources 614, and / or the distributed file system 638 of framework layer 620. One or more types of applications may include, but are not limited to, any number of genomics applications, cognitive computing and machine learning applications, including training or inference software, machine learning framework software (e.g., PyTorch, TensorFlow, Caffe, etc.), and / or other machine learning applications used in conjunction with one or more embodiments.

[0090] In at least one embodiment, any of the configuration manager 634, resource manager 636, and resource coordinator 612 can perform any number and type of self-modification actions based on any amount and type of data acquired in any technically feasible manner. Self-modification actions can mitigate potentially poor configuration decisions by data center operators of data center 600 and can prevent underutilization and / or poor performance of the data center.

[0091] Data center 600 may include tools, services, software, or other resources to train one or more machine learning models or to use one or more machine learning models to predict or infer information according to one or more embodiments described herein. For example, a machine learning model can be trained by calculating weight parameters based on a neural network architecture using the software and / or computing resources described above with respect to data center 600. In at least one embodiment, information can be inferred or predicted using trained or deployed machine learning models corresponding to one or more neural networks using the resources described above with respect to data center 600 by using weight parameters calculated through one or more training techniques such as, but not limited to, those described herein.

[0092] In at least one embodiment, the data center 600 may use a CPU, application-specific integrated circuit (ASIC), GPU, FPGA, and / or other hardware (or corresponding virtual computing resources) to perform training and / or inference. Furthermore, one or more of the aforementioned software and / or hardware resources may be configured as a service to allow a user to train or perform information inference, such as image recognition, speech recognition, or other artificial intelligence services.

[0093] Example network environment

[0094] A network environment suitable for implementing embodiments of this disclosure may include one or more client devices, servers, network-attached storage (NAS), other backend devices, and / or other device types. Client devices, servers, and / or other device types (e.g., each device) may be... Figure 5 This is implemented on one or more instances of computing devices 500—for example, each device may include similar components, features, and / or functions of one or more computing devices 500. Furthermore, in the case of implementing backend devices (e.g., servers, NAS, etc.), the backend devices may be included as part of a data center 600, examples of which are described in this document. Figure 6 To describe in more detail.

[0095] Components of a network environment can communicate with each other via one or more networks, which can be wired, wireless, or both. A network may include multiple networks or one of multiple networks. For example, a network may include one or more wide area networks (WANs), one or more local area networks (LANs), one or more public networks such as the Internet and / or the Public Switched Telephone Network (PSTN), and / or one or more private networks. In cases where the network includes a wireless telecommunications network, components such as base stations, communication towers, or even access points (and other components) can provide wireless connectivity.

[0096] A compatible network environment may include one or more peer-to-peer network environments (in which case the server may not be included in the network environment) and one or more client-server network environments (in which case one or more servers may be included in the network environment). In a peer-to-peer network environment, the functionality described herein with respect to the server can be implemented on any number of client devices.

[0097] In at least one embodiment, the network environment may include one or more cloud-based network environments, distributed computing environments, combinations thereof, etc. A cloud-based network environment may include a framework layer, a job scheduler, a resource manager, and a distributed file system implemented on one or more servers, which may include one or more core network servers and / or edge servers. The framework layer may include a framework of software supporting the software layer and / or one or more applications supporting the application layer. The software or applications may respectively include web-based service software or applications. In embodiments, one or more client devices may use web-based service software or applications (e.g., by accessing the service software and / or applications via one or more application programming interfaces (APIs)). The framework layer may be, but is not limited to, free and open-source software web application frameworks, such as those used for large-scale data processing (e.g., "big data") using a distributed file system.

[0098] A cloud-based network environment can provide cloud computing and / or cloud storage for any combination of the computing and / or data storage functions (or one or more portions thereof) described herein. Any of these different functions can be distributed across multiple locations from a central or core server (e.g., distributed across one or more data centers at the state, region, country, global, etc.). The core server may assign at least a portion of the functionality to the edge server if the connection to the user (e.g., a client device) is relatively close to the edge server. A cloud-based network environment can be private (e.g., limited to a single organization), public (e.g., available to many organizations), and / or a combination thereof (e.g., a hybrid cloud environment).

[0099] One or more client devices may include the information described in this article. Figure 5 The components, features, and functions of one or more example computing devices 500 described are at least some of the components, features, and functions described. By way of example and not limitation, the client device may be embodied as a personal computer (PC), laptop computer, mobile device, smartphone, tablet computer, smartwatch, wearable computer, personal digital assistant (PDA), MP3 player, virtual reality headset, global positioning system (GPS) or device, video player, camera, surveillance equipment or system, vehicle, ship, spacecraft, virtual machine, drone, robot, handheld communication device, hospital equipment, gaming equipment or system, entertainment system, vehicle computer system, embedded system controller, remote control, electrical appliance, consumer electronics device, workstation, edge device, any combination of these described devices, or any other suitable device.

[0100] This disclosure can be described in the general context of machine-usable instructions or computer code, including computer-executable instructions such as program modules, which are executed by a computer or other machine such as a personal digital assistant or other handheld device. Typically, a program module, including routines, programs, objects, components, data structures, etc., refers to code that performs a specific task or implements a specific abstract data type. This disclosure can be practiced in a wide variety of system configurations, including handheld devices, consumer electronics, general-purpose computers, more specialized computing devices, etc. This disclosure can also be practiced in distributed computing environments in which tasks are performed by remote processing devices linked via a communication network.

[0101] As used herein, statements relating to two or more elements with respect to “and / or” should be interpreted as referring to only one element or a combination of elements. For example, “element A, element B, and / or element C” can include only element A, only element B, only element C, element A and element B, element A and element C, element B and element C, or element A, B, and C. Furthermore, “at least one of element A or element B” can include at least one of element A, at least one of element B, or at least one of element A and at least one of element B. Further, “at least one of element A and element B” can include at least one of element A, at least one of element B, or at least one of element A and at least one of element B.

[0102] This document describes in detail the subject matter of this disclosure to meet legal requirements. However, the description itself is not intended to limit the scope of this disclosure. Rather, the inventors have envisioned that the claimed subject matter may also be embodied in other ways to include steps different from or similar combinations of steps described herein in conjunction with other current or future techniques. Moreover, although the terms “step” and / or “box” may be used herein to imply different elements of the method employed, these terms should not be construed as suggesting any particular order among or between the various steps disclosed herein, unless the order of the steps is explicitly described.

Claims

1. A method for memory access, comprising: Receive a translation request from a first entity to translate a virtual address to a physical address, wherein the virtual address belongs to a memory portion owned by a second entity; Determine that the first entity is authorized to respond to the conversion request to receive the physical address; At least based on the determination and in response to the conversion request: Permissions are recorded in entries corresponding to the physical address in one or more tables of the host, the permissions enabling the first entity to access the physical address of the memory portion of the second entity using direct memory access via the host controller interface of the host, wherein mapping table entries associated with the translation request are accessed to enable the permissions to be verified using one or more pointers to the one or more tables stored in the mapping table entries. as well as The physical address translated from the virtual address is sent to the first entity using at least one translation table accessed from the mapping table entry; The host controller interface receives the physical address in a request from the first entity for accessing the memory portion of the second entity using the direct memory access, the request being made using the physical address received by the first entity in response to the translation request; The verification is performed to authorize the first entity to provide the physical address through the host controller interface to access the memory portion of the second entity using the direct memory access, the verification including the host accessing the one or more tables to obtain the permission based at least on associating the mapping table entry with the request and using the one or more pointers stored in the mapping table entry; as well as Based at least on the verification results, a response to the request is provided to the first entity through the host controller interface.

2. The method of claim 1, wherein the access uses a stream identifier included in the request to locate the mapping table entry corresponding to the stream identifier, and the one or more pointers are stored in the mapping table entry.

3. The method of claim 2, wherein the host is configured to point each flow ID corresponding to the first entity to the one or more tables.

4. The method of claim 1, wherein the mapping table entry further stores a phase configuration for disabling address translation, and the host performs the verification based at least on determining that the phase configuration indicates that address translation is disabled.

5. The method of claim 1, wherein the access includes: The table is identified from one or more tables using the entity identifier extracted from the request; as well as The permissions are identified using the physical address extracted from the request.

6. The method of claim 1, wherein each entry corresponds to a permission bitmap of a plurality of physical addresses, and the recording includes compressing the permission bitmap of the plurality of physical addresses in memory.

7. The method of claim 1, wherein in response to the conversion request, the one or more pointers are stored in the mapping table entry.

8. The method of claim 1, wherein at least based on the first entity being moved into the Trusted Execution Environment (TEE) of the second entity, the first entity is authorized to respond to the translation request to receive the physical address.

9. The method of claim 1, wherein the mapping table entries further store configuration information for selectively enabling and disabling the verification.

10. A system for memory access, comprising: One or more processing units are used to perform operations including the following: Receive a translation request from a first entity to translate a virtual address to a physical address, wherein the virtual address belongs to a memory portion owned by a second entity; Determine that the first entity is authorized to respond to the conversion request to receive the physical address; At least based on the determination and in response to the conversion request: Permissions are recorded in entries corresponding to the physical address in one or more tables of the host, the permissions enabling the first entity to provide access to the physical address of the memory portion of the second entity using direct memory access via the host controller interface of the host, wherein mapping table entries associated with the translation request are accessed to enable the permissions to be verified using one or more pointers to the one or more tables stored in the mapping table entries. as well as The physical address translated from the virtual address is sent to the first entity using at least one translation table accessed from the mapping table entry; The host controller interface receives the physical address from the first entity in a request to access the memory portion of the second entity using the direct memory access; The verification is performed to authorize the first entity to provide the physical address through the host controller interface to access the memory portion of the second entity using the direct memory access, the verification including the host accessing the one or more tables to obtain the permission based at least on associating the mapping table entry with the request and using the one or more pointers stored in the mapping table entry; as well as Based at least on the verification, direct memory access to the physical address via the host controller interface is enabled.

11. The system of claim 10, wherein the permissions are stored in a table using one or more permission bits indexed by one or more physical addresses.

12. The system of claim 10, wherein the permissions are stored in a transaction mapping table used to translate the physical address from the logical address.

13. The system of claim 10, further comprising providing the physical address to the first entity at least based on the determination and in response to the conversion request.

14. The system of claim 10, wherein the permission is identified using an entity identifier extracted from the request and the physical address extracted from the request.

15. The system of claim 10, wherein the request for accessing the memory portion of the second entity includes a direct memory access transfer request.

16. The system of claim 10, wherein the system comprises at least one of the following: Control systems for autonomous or semi-autonomous machines; Sensing systems for autonomous or semi-autonomous machines; A system used to perform simulation operations; A system used to perform deep learning operations; Systems implemented using edge devices; Systems implemented using robots; A system containing one or more virtual machines (VMs); A system that is at least partially implemented in a data center; Including systems for collaborative creation platforms of 3D content; or A system that utilizes cloud computing resources at least in part.

17. A processor, comprising: One or more circuits are configured to control access to a memory portion of a first entity, based at least on the result of authentication performed by a host, which accesses one or more tables from the mapping table entries by associating them with requests via the host controller interface, to obtain permission for a second entity to access the memory portion using direct memory access by providing a physical address via the host controller interface. The request originates from the second entity and is intended to access the memory portion of the first entity using the direct memory access. At least based on the determination that the second entity is authorized to receive the physical address in response to a conversion request from the second entity, the permission is recorded in entries in one or more tables, wherein the entries are accessed from one or more pointers in the one or more tables stored in the mapping table entries associated with the conversion request for the purpose of the verification. The physical address is translated from the virtual address using at least one translation table accessed from the mapping table entry, and in response to the translation request, the physical address is sent to the second entity.

18. The processor of claim 17, wherein the permission is derived from permissions stored in the one or more tables using one or more permission bits indexed by one or more physical addresses.

19. The processor of claim 18, wherein at least one of the one or more tables is stored in a transaction mapping table, the transaction mapping table being used to translate the physical address from the logical address.

20. The processor of claim 17, wherein the permissions are set by a host process of the host, the first entity is a virtual machine managed by the host, and the second entity corresponds to a device outside the host.

Citation Information

Patent Citations

  • Memory access information acquisition method, computing device and storage medium

    CN113434371A

  • Data processing apparatus and method with ownership table

    US20180129611A1