Migration of pages of memory accessible by I / O devices

Abstract

The electronic device includes a memory, an input / output memory management unit (IOMMU), a processor executing software entities, and a page migration engine. The software entities and the page migration engine perform operations to prepare for migrating a page of memory accessible by at least one IO device in the memory, and the software entities and the page migration engine set migration state information in a page table entry for the page of memory based on the operations being performed. Upon completion of the operations to prepare for migrating the page of memory, the page migration engine migrates the page of memory in the memory. The IOMMU uses the migration state information in the page table entry to control one or more operations of the IOMMU.

Description

[Background technology]

[0001] (Related Technology) Some electronic devices include a processor (e.g., a central processing unit, etc.) that performs computation, control, memory access, and other operations, along with a memory in which data is stored (here, "data" is used to collectively refer to information such as program code instructions, input or result data for and from computational operations, constant values, etc.). Many such electronic devices also include input / output (IO) devices such as network interface devices, disk controllers, etc. IO devices may interact with the processor and memory to perform various operations. For example, a network interface device may store data received over a network in memory and then signal to the processor that the data stored in memory is awaiting processing.

[0002] In some cases, data stored in memory within an electronic device may be stored in the memory in a way that makes accessing the data inefficient. For example, the memory may be implemented using a combination of two different types of memory, one of which is a faster-access but more expensive memory type and the other of which is a slower-access but less expensive memory type. Inefficiencies can arise in such memory when frequently accessed, high-priority, and / or time-critical data is stored in the slower type of memory, or vice versa. As another example, inefficiencies can arise when data is stored in a remote portion of memory, such as a portion of memory in a remote socket of a non-uniform memory access (NUMA) electronic device.

[0003] Because inefficiencies in accessing data in memory can affect the overall performance of an electronic device, some electronic devices include a migration mechanism for dynamically rearranging or “migrating” data in memory so that the data is stored in a more appropriate location in memory. For example, data in memory may be organized into contiguous blocks of data, or “memory pages,” of a specified size (e.g., 4 KiB, 2 MiB, etc.), for memory management and migration purposes. The migration mechanism may monitor accesses of the memory pages and selectively migrate the memory pages based on specified patterns or characteristics of the memory page accesses. For example, in an electronic device having the two different types of memory described above, if a memory page stored in the slower type of memory is accessed sufficiently frequently, the migration mechanism may migrate the memory page from the slower type of memory to the faster type of memory. In some electronic devices, the migration mechanism migrates memory pages automatically and autonomously; thus, the memory page may be migrated without communicating information about the migration to each accessing entity (e.g., processor, IO device, etc.) that has access to the memory page. In other words, the migration mechanism "stealthily" migrates pages of memory without each of the accessing entities necessarily having direct knowledge of, providing approval for, and / or participating in the migration.

[0004] In some electronic devices, some or all IO devices do not provide support for migrating pages of memory. For example, the IO devices may be older or simpler IO devices that do not include software and / or hardware support for handling faults (e.g., page faults, etc.) that can occur when a page of memory accessible to such an IO device is migrated and the IO device attempts to access the page of memory or information associated with the page of memory (e.g., address translation information, etc.) during the migration, the IO device and / or other functional blocks and devices within the electronic device (e.g., processor, etc.) may crash, experience errors, or behave in an unexpected or undesirable manner. [Brief explanation of the drawings]

[0005] [Figure 1] FIG. 1 is a block diagram illustrating an electronic device according to some embodiments. [Figure 2] FIG. 1 is a block diagram illustrating functional blocks and devices within an operating system and an electronic device, according to some embodiments. [Figure 3] FIG. 2 is a block diagram illustrating a hypervisor and functional blocks and devices within an electronic device, according to some embodiments. [Figure 4] FIG. 2 is a block diagram illustrating a page table, according to some embodiments. [Figure 5] FIG. 1 is a block diagram illustrating metadata in a page table entry, according to some embodiments. [Figure 6] FIG. 1 is a state diagram illustrating transition states, according to some embodiments. [Figure 7] FIG. 1 is a flow diagram illustrating a process for migrating pages of memory, according to some embodiments. DETAILED DESCRIPTION OF THE INVENTION

[0006] Throughout the drawings and description, like numbers refer to like drawing elements.

[0007] The following description is presented to enable any person skilled in the art to make and use the described embodiments, and is provided in the context of a particular application and its requirements. Various modifications to the described embodiments will be readily apparent to those skilled in the art, and the general principles described herein may be applied to other embodiments and applications. Thus, the described embodiments are not limited to the embodiments shown, but are to be accorded the widest scope consistent with the principles and features described herein.

[0008] (term) In the following description, various terms are used to describe embodiments. The following is a simplified general description of one of the terms. It should be noted that this term may have important additional aspects that are not described herein for clarity and conciseness, and therefore the description is not intended to be limiting of this term.

[0009] Functional Block: A functional block refers to a set of interrelated circuitry, such as an integrated circuit configuration, a discrete circuit configuration, or the like. The circuitry is "interrelated" in that the circuit elements within the circuitry share at least one characteristic. For example, the circuits may be contained in, fabricated on, or otherwise coupled to a particular integrated circuit chip, substrate, circuit board, or portion thereof, may be involved in performing particular operations (e.g., computational operations, control operations, storage operations, etc.), may be controlled by a common control element and / or a common clock, etc. The circuitry of a functional block can have any number of circuit elements, from a single circuit element (e.g., a single integrated circuit logic gate or discrete circuit element) to millions or billions of circuit elements (e.g., integrated circuit memory). In some embodiments, the functional block performs operations "in hardware," using circuitry that performs operations without executing program code.

[0010] Data: Data is a generic term referring to information that can be stored in memory and / or used in computation, control, and / or other operations. Data includes information such as actual data (e.g., results of computation or control operations, outputs of processing circuits, inputs for computation or control operations, variable values, sensor values, etc.), files, program code instructions, control values, and / or other information. Data may be organized into logical blocks (e.g., 4 KiB or 2 MiB pages of memory, etc.) that contain one or more of the above types of information for operations such as loading, migrating, etc. data into memory.

[0011] Access: Access as applied to interactions with data stored in memory (e.g., main memory, cache memory, etc.), i.e., "memory access," refers to all forms of interaction that may be performed for, on, using, and / or with the data and corresponding metadata and / or control values. For example, access may include reading or loading data from memory, writing or storing data to memory, invalidating or deleting data in memory, reading or writing metadata to data in memory, changing the status, coherency state, or permissions for data in memory, etc. Data is "accessible" to a given functional block or device if a particular type of memory access is permitted / authorized for that functional block or device.

[0012] (Virtual Memory) In the described embodiment, the electronic device uses virtual memory technology to handle data accesses by software entities (e.g., application programs, operating systems, device drivers, virtual machines, etc.) running within the electronic device or by input / output (IO) devices (e.g., network interface devices, Peripheral Component Interface Express (PCIe) bus devices, disk controllers, etc.). Generally, when data is first accessed by a software entity or an IO device, a block or page of memory of a predetermined size (e.g., 4 KiB, 2 MiB, etc.) containing the data is copied from a mass storage device (e.g., a disk drive or non-volatile semiconductor memory) to an available physical location in memory (e.g., main memory) within the electronic device, or a page of memory is newly created in memory (e.g., to store the results of a calculation or other operation, etc.). The electronic device tracks the physical locations of pages for the software entity or IO device so that the software entity and the IO device do not need to track the physical locations of pages in memory. Instead of accessing memory using addresses based on the physical location (or physical address) of data in memory, the software entity and the IO device access memory using “virtual” addresses in a virtual address space, which is a local address space specific to the corresponding software entity or IO device. From the perspective of a software entity or an IO device, a virtual address indicates the actual physical location where data is stored in memory, and memory accesses are made by the software entity and the IO device accordingly using the virtual address. However, the virtual address may not directly map to the physical address of the physical location where the data is stored in a page in memory. As part of keeping track of the physical location of pages, the electronic device translates the virtual addresses used by the software entity and the IO device in memory access requests into the physical address where the data is actually located.The electronic device then uses the physical addresses to perform memory accesses for the software entities and IO devices.

[0013] To enable the above-described virtual-to-physical address translation, an electronic device includes a page table. A page table is a record stored in the memory of an electronic device, including entries, or “page table entries,” that contain virtual-to-physical address translation information and other information about pages of data stored in the memory. In other words, the page table includes a mapping between a virtual address and a corresponding physical address for each page of data present in the memory. Upon receiving a request to access memory at a given virtual address from a software entity or an IO device, the electronic device obtains corresponding physical address information from the page table by performing a page table walk. During the page table walk, the page table is searched for a page table entry that provides a physical address associated with the virtual address. For example, upon receiving a request to access memory at a given virtual address from an operating system, a memory management unit (MMU) in a central processing unit (CPU) core in the electronic device may perform a page table walk to obtain corresponding physical address information from the page table and process the memory access using the physical address information. As another example, upon receiving a request from an IO device to access memory at a given virtual address, an input-output memory management unit (IOMMU) in the electronic device may perform a page table walk to obtain corresponding physical address information from the page table and process the memory access using the physical address information.

[0014] Because the page table walk described above is relatively slow, it is desirable to avoid performing a page table walk. Therefore, electronic devices include a translation lookaside buffer (TLB), which is a local cache used to store a limited number of copies of address translation information (i.e., information based on page table entries) obtained during a page table walk. For example, a CPU may include a TLB used to locally store copies of information based on page table entries used in memory accesses for software entities (or copies of the page table entries themselves). As another example, an IOMMU may include a TLB used to locally store copies of information based on page table entries used in memory accesses for IO devices (or copies of the page table entries themselves). During operation, a CPU core or an IOMMU first attempts to retrieve a cached page table entry from the corresponding TLB to perform a virtual-to-physical address translation. If a copy of the corresponding page table entry is not present in the TLB (i.e., a “miss” occurs), the CPU core or IOMMU performs a page table walk to retrieve the desired page table entry. The CPU core or IOMMU may then cache a copy of the retrieved page table entry in its respective TLB for later use.

[0015] In some embodiments, the IOMMU and IO devices support a communications protocol for address translation, such as PCI Express (PCIe) Address Translation Services (ATS). In the case of ATS, input / output (IO) devices may include a corresponding local cache or “address translation cache” (ATC) that each IO device uses to store copy information based on page table entries (or the page table entries themselves). Generally, when an IO device wants a local copy of information based on a page table entry (or, more simply, a copy of the entire page table entry), the IO device requests the information based on the page table entry from the IOMMU. The IOMMU verifies that the IO device is authorized to have the information and then provides the information based on the page table entry to the IO device. The IO device then stores the information based on the page table entry in the ATC for later use. Thus, using the ATC allows the IO device to avoid having to repeatedly request information based on page table entries from the IOMMU.

[0016] (memory page migration) In described embodiments, pages of memory may be migrated within memory. To migrate, a page of memory is physically moved within memory, resulting in the page being relocated from a first location within memory to a second location within memory. For example, if a page of memory is an 8 KiB page of memory and is initially located at addresses A through A+8 KiB−1, the page may be migrated to addresses B through B+8 KiB−1. In some embodiments, pages of memory are migrated to relocate the page of memory to a location within memory that is more suitable for the page of memory and / or the memory itself. For example, a frequently accessed or higher priority page of memory may be migrated from a first type of memory having a slower access speed to a second type of memory having a faster access speed, or vice versa. As another example, pages of memory may be migrated within memory to avoid wear and tear on memory circuitry within the memory. As yet another example, pages of memory may be migrated within memory to place the page of memory closer to other pages of memory being accessed. As yet another example, in some embodiments, the memory is configured for non-uniform memory access (NUMA), with multiple portions of the memory each located near a respective processing node, and pages of the memory can be migrated between portions of the memory within a node.

[0017] In some embodiments, the decision to migrate a page of memory is made by a software entity and / or functional block or device within the electronic device based on one or more migration rules (i.e., guidelines, standards, thresholds, etc.) that identify the conditions under which the page of memory should be migrated. For example, an operating system or hypervisor executed by a processor within the electronic device may determine that a page of memory should be migrated based on the frequency or type of accesses made to the page of memory. As another example, a memory management unit functional block within the processor may determine that a page of memory should be migrated from slower access memory to faster access memory based on a priority identified in a memory access request for the page of memory.

[0018] Although a processor is capable of migrating pages of memory within memory, i.e., physically moving individual bytes of a page of memory within memory, using the processor to perform the migration may consume processor resources that are better used for other operations (e.g., computational operations, other types of memory accesses, etc.). Therefore, in some embodiments, the migration of pages of memory is offloaded from the processor to a page migration engine functional block or device (which may include a direct memory access (DMA) functional block that performs operations to physically move pages of memory within memory). The page migration engine is capable of, and may be optimized to, perform the migration of pages of memory given an identification of a page of memory and a destination location within memory.

[0019] (overview) In a described embodiment, an electronic device includes a processor and one or more input / output (IO) devices (IO devices may include functional blocks or actual devices such as a network interface, a disk controller, a graphics processing unit, etc.). The electronic device also includes memory used to store data for use by the processor and / or the IO devices. The electronic device further includes at least one page migration engine functional block that performs operations to copy, move, and otherwise manipulate data stored in the memory. As part of these operations, the page migration engine performs operations associated with migrating pages of memory (e.g., 4 KiB pages of memory), which involves relocating the pages of memory within the memory according to migration rules. The electronic device also includes an input / output memory management unit (IOMMU) that manages memory access by the IO devices. In a described embodiment, the IOMMU performs operations to control IO device access of pages of memory that are accessible to the IO devices and that are or are being migrated, and to control use of information from page table entries for such pages of memory. The actions performed by the IOMMU are directed to ensuring that IO devices (and more generally electronic devices) do not experience errors or faults that could occur if an IO device accesses a page of memory that has been migrated (or encounters a missing page of memory) and / or uses incorrect information from a page table entry for such a page of memory.

[0020] In the described embodiment, the page table includes migration information in the page table entries that is used to help control access of the page of memory being migrated and the respective page table entry. The page table entry includes migration state information, along with the translation information and metadata described above. The migration state information includes an indication of whether the page of memory associated with the page table entry is being prepared for migration or whether the page of memory is being migrated (or not). For example, in some embodiments, the migration state information includes two bits, with each possible combination of the two bits identifying a corresponding migration state from a set of migration states. In a first or "non-migration" migration state, identified by 00, the page of memory is not being migrated. In second and third migration states, identified by 01 and 10, respectively, corresponding preparations are being made to migrate the page of memory. In a fourth migration state, identified by 11, final preparations are being made to migrate the page of memory or the page of memory is being migrated (i.e., is actually being relocated in memory).

[0021] In some embodiments, the processor executes a software entity, in combination with the page migration engine, that prepares a page of memory for migration and performs at least some of the operations to process the migration of the page of memory. For example, the software entity may be or include a hypervisor, an operating system, an application program, etc. Among the operations performed by the software entity and / or the page migration engine to prepare a page of memory for migration is setting migration state information for the page of memory. For example, as functional blocks and devices within the electronic device progress through each of the transition states described above, the software entity or the page migration engine may set the migration state information accordingly. Another operation performed by the software entity and / or the page migration engine is invalidating existing copies of information in page table entries for migrating the page stored in caches within the IOMMU or IO device. A further operation performed by the page migration engine is, after migrating the page of memory, updating the page table entry for the page of memory to identify a new location in memory for the page of memory and setting the migration state information in the page table entry to indicate a non-migration state.

[0022] In some embodiments, the IOMMU enforces access restrictions on pages of memory and page table entries based on migration state information in the page table entries. For example, if the migration state information indicates that a page of memory is being prepared for migration or that the page of memory has been migrated, the IOMMU may prevent itself and IO devices from storing or using copies of information from the page table entry in their local caches. As another example, if the migration information in a page table entry indicates that a page of memory is being prepared for migration or has been migrated, the IOMMU may ensure that accesses of the page of memory are handled accordingly. That is, the IOMMU may ensure that existing memory accesses of the page of memory are completed before the page of memory is migrated, and that newly encountered memory accesses of the page of memory are stalled (i.e., held, buffered, etc.) until after the page of memory has been migrated. In contrast, if the migration information in the page table entry indicates that the page of memory is in a non-migration state (and therefore not migrated), the IOMMU may allow normal accesses of the page of memory and page table entry.

[0023] In some embodiments, some or all of the IO devices support address translation services (ATS), such as PCI Express (PCIe) address translation services, which are a standard by which an IO device may request information from an IOMMU from a page table entry that is cached locally in a local cache, or entry in an “address translation cache (ATC),” within the IO device. As part of the operations described above to prevent a copy of information from a page table entry from being stored in a cache within the IO device, the IOMMU may reject / deny an ATS request for information from a page table entry associated with a page of memory that is being migrated or migrated. For example, in some embodiments, the IOMMU responds to the ATS request by notifying the requesting IO device that the page of memory does not exist, thereby causing the IO device to proceed with operations to make the page of memory present in the IO page table. As another example, the IOMMU may notify the requesting IO device that an untranslated address should be used to access the page of memory, and therefore the IO device will not be provided with information from the IO page table entry.

[0024] While the operations described above are performed for pages of memory that are accessible to IO devices and that are preparing for or migrating, pages of other types of memory may be handled differently when migrated. For example, in some embodiments, pages of memory that are not accessible to IO devices but are instead accessible only to the processor may be migrated by marking the pages as "not present" in their respective page table entries and invalidating any copies of page table information for such pages of memory in caches (i.e., translation lookaside buffers) within the processor. In this case, the processor includes mechanisms for handling missing pages (e.g., via page faults, etc.). Additionally, pages of memory that are not preparing for or migrating, and their corresponding page table entries, may be accessed normally, even if they are accessible to IO devices, subject to memory access ordering rules, etc.

[0025] By handling the migration of pages of memory accessible to IO devices, the described embodiments allow such pages of memory to be more freely migrated within memory despite the presence of IO devices that may not themselves handle memory page migration properly. Migrating these memory pages can help ensure that the memory pages are in desired locations within memory. This can improve memory operation, which in turn improves operation of processors and IO devices that use the memory pages within memory.

[0026] (Electronic Devices) FIG. 1 is a block diagram illustrating an electronic device 100, according to some embodiments. As seen in FIG. 1, the electronic device 100 includes a processor 102, a memory 104, a mass storage device 106, input / output (IO) devices 108-110, an input / output (IO) hub 112, and a page migration engine 114. The processor 102, the memory 104, the mass storage device 106, the IO devices 108-110, the IO hub 112, and the page migration engine 114 are all implemented in "hardware," i.e., using corresponding integrated circuits, discrete circuits, and / or devices. For example, in some embodiments, the processor 102, the memory 104, the mass storage device 106, the IO devices 108-110, the IO hub 112, and the page migration engine 114 are implemented in integrated circuits on one or more semiconductor chips, in combination with discrete circuits and / or devices, or in discrete circuits and / or devices. In FIG. 1, electronic device 100 is partially shaded to allow the various diagram elements to be more easily distinguished.

[0027] Processor 102 is a functional block that performs calculations, memory access, control, and / or other operations in electronic device 100. Processor 102 includes cores 116-118, each of which includes one or more central processing unit (CPU) cores, graphics processing unit (GPU) cores, embedded processors, application specific integrated circuits (ASICs), and / or other computing functional blocks.

[0028] The processor 102 includes cache memory, or "cache," which is a functional block used to store copies of data that can be used by the cores 116-118 to perform various operations. As seen in FIG. 1 , the cache in the processor 102 includes level 1 (L1) caches 120-122 (L1 120 and L1 122) in the cores 116-118, respectively. Each of the L1 caches 120-122 includes memory circuitry for storing data and control circuitry for handling accesses of the data stored in the memory circuitry. The processor 102 also includes a shared level 2 (L2) cache 124 and a level 3 (L3) cache 126, each of which includes memory circuitry for storing data and control circuitry for handling accesses of the data stored in the memory circuitry.

[0029] Processor 102 includes a platform security processor (PSP) 128, which is a functional block used to perform security-related operations in electronic device 100. For example, in some embodiments, PSP 128 includes a CPU core, an ASIC, and / or a microcontroller. PSP 128 includes circuitry designed to be secure against specified malicious or erroneous behavior of other functional blocks and devices within processor 102 and / or software entities executed by processor 102. Thus, PSP 128 may be used to secure the operation of other functional blocks, devices, and / or software entities that are susceptible to such behavior. In other words, PSP 128 may perform operations associated with enabling a trusted execution environment in electronic device 100. To this end, PSP 128 may perform operations for encryption / decryption (e.g., key generation, data encryption / decryption, etc.), registration and / or authentication of hardware and / or software entities, access permission verification, etc. In some embodiments, PSP 128 performs at least some of the operations described herein to handle page transitions accessible to IO devices 108-110. For example, a software entity may communicate a request to migrate a page of memory to PSP 128, which then verifies that the memory page migration is authorized (i.e., that the software entity is allowed to move a particular page of memory to a destination location in memory) before forwarding the request to migrate the memory page to page migration engine 114 for subsequent processing.

[0030] Memory 104 is a functional block used to store data for other functional blocks within electronic device 100. For example, in some embodiments, memory 104 is the "main" memory within electronic device 100. Memory 104 includes memory circuitry for storing data and circuitry for handling access of data stored in the memory circuitry.

[0031] In some embodiments, memory 104 includes two or more different types of memory arranged such that a different portion of the set of addressable locations in memory 104 is in each type of memory. For example, in some embodiments, half of the addressable locations are in a first type of memory and are therefore implemented using memory circuits of the first type, and half of the addressable locations are in a second type of memory and are therefore implemented using memory circuits of the second type. The use of two types of memory is illustrated in FIG. 1 by memory type 130 and memory type 132. For example, memory type 130 may be fifth generation double data rate synchronous dynamic random access memory (DDR5 DRAM) or another type of memory, and memory type 132 may be 3D cross point (3D XPoint) memory or another type of memory. Each memory type has respective memory characteristics. For example, memory characteristics may include some or all of the following: access speed / latency, access bandwidth, data protection / verification / error correction, reliability / mean time between failures, power consumption, heat generation, data addressability (e.g., byte or block addressability), data compatibility / specifications, monetary cost, design complexity, etc.

[0032] Mass storage device 106 is a functional block and / or device that stores data used by other functional blocks and devices within electronic device 100. For example, mass storage device 106 may be or include semiconductor memory, a disk drive, an optical drive, etc. Mass storage device 106 includes circuitry and / or devices that retain stored data even when power to mass storage device 106 is interrupted (or otherwise reduced), and thus serves as non-volatile “long-term” storage for data. At runtime (i.e., when electronic device 100 is operating), copies of data are retrieved from mass storage device 106 and stored in volatile memory 104 (and possibly one or more caches) for subsequent use by functional blocks within electronic device 100. For example, data may be retrieved / read from mass storage device 106 in blocks or pages of a predetermined size (e.g., 4 KiB, 2 MiB, 1 GiB, etc.), and the pages may be stored in memory 104 as “pages of memory.” Additionally, pages of memory generated by other functional blocks and devices within electronic device 100 may be stored within memory 104 (e.g., to store computation results, files, configuration values, etc.) and eventually written out to mass storage device 106. While stored in memory 104, the pages of memory may be accessible to other functional blocks and devices in accordance with the access rules and permissions for the pages of memory and / or the data therein.

[0033] Returning to processor 102, memory management unit (MMU) 134 is a functional block that processes memory access requests and requests for information from page tables. When data is to be accessed by a functional block within processor 102, the functional block sends the memory access request to MMU 134. For example, a software entity (e.g., a program, an operating system, etc.) being executed by core 116 may cause a load / store unit in a processing circuit within core 116 to send a memory access request (e.g., to load or store data, etc.) to MMU 134. MMU 134 then sends a corresponding memory access request to one or more of L2 cache 124, L3 cache 126, and memory 104 to satisfy or resolve the memory access request. For example, when data is to be loaded, MMU 134 may retrieve the data from L2 cache 124, L3 cache 126, or memory 104 and forward the data to the requesting functional block. This may mean loading one or more memory pages containing data from mass storage device 106 into memory 104 if the data is not already present in memory 104.

[0034] MMU 134 includes table walker (TW) 136, a functional block that performs operations related to obtaining address translation information and other information from page tables via page table walks. For example, as described in more detail above, in some embodiments, electronic device 100 uses virtual memory to allow software entities (e.g., executed by cores 116-118) to access memory using virtual addresses that are translated to physical addresses. Upon receiving a memory access request from a software entity with a virtual address, table walker 136 performs a page table walk operation to translate the virtual address into the physical address of the page where the data is located in memory 104. During a page table walk operation, table walker 136 may check page table entries and / or other records to ensure that the functional block and / or software entity requesting the respective memory access is authorized to perform such access, i.e., is allowed to access memory at a physical address, etc., and that the page tables and other records used for the translation have not been tampered with or impermissibly modified. In some embodiments, the table walker 136 also checks the migration state information in the page table entry as part of the operations described herein for handling page migrations.

[0035] An example of the page table described above is shown in FIG. 1 as page table 148. Generally, page table 148 is a record having entries, or “page table entries,” containing virtual-to-physical address translation information and other information for each page of data currently stored in memory 104. Within each page table entry, page table 148 includes respective migration state information used to handle migration of pages of memory as described herein. While shown as a single entity in FIG. 1, in some embodiments, page table 148 is or includes multiple individual page subtables that are used in combination to perform virtual-to-physical address translations. Additionally, in some embodiments, page table 148 includes or is included in a hierarchy of page tables (e.g., host page table, IOMMU page table, etc.) used to perform virtual-to-physical address translations for virtual machines, IO devices, etc., i.e., to perform multiple translations for guest virtual addresses, host virtual addresses, and host physical addresses. For example, in some embodiments, page tables 148 include host page tables used by processor 102 to perform virtual-to-physical address translations (and other operations) for software entities executing on processor 102, and IOMMU page tables used by IOMMU 140 to perform virtual-to-physical address translations (and other operations) for IO devices 108-110. For clarity, although a single page table is used in the examples herein, in some embodiments, multiple page tables, hierarchies of page tables and / or separate page tables may be used, along with the corresponding operational coordination described herein.

[0036] MMU 134 includes a translation lookaside buffer (TLB) 138, which is a functional block used to store copies of information obtained from page table entries. TLB 138 includes memory circuitry for caching and storing copies of page table entries or portions thereof obtained during a page table walk by table walker 136 (or from other sources). To avoid performing a page table walk, MMU 134 obtains address translation information and / or other page table entry information from TLB 138, when possible. However, if the address translation information and / or other page table entry information is not present in TLB 138, table walker 136 performs a table walk to obtain the information. In some embodiments, specified information in TLB 138 is invalidated before the corresponding page is migrated, as described herein.

[0037] Input / output (IO) devices 108-110 are functional blocks or devices that interact with processor 102 and other functional blocks and devices within electronic device 100. Thus, processor 102 and other functional blocks may receive “input” data from or send “output” data to IO devices 108-110. IO devices 108-110 may also interact with functional blocks or devices external to electronic device 100. For example, I / O devices 108-110 may include network interface devices, disk controllers, devices coupled to corresponding wired or wireless buses or interfaces (e.g., Peripheral Controller Interface Express (PCIe) bus, Universal Serial Bus (USB), Wi-Fi network, etc.), graphics processing units, etc. The specific operations performed by each of IO devices 108-110 depend on the nature of the respective IO device. For example, if IO device 108 is a disk controller, IO device 108 can retrieve data from a disk (e.g., mass storage device 106) and write data to memory 104, or vice versa. As another example, if IO device 110 is a network interface device, IO device 110 can store data received over a network (not shown) in memory 104, retrieve data from memory 104 that is sent over the network to a receiving device, provide data to or retrieve data from processor 102, etc.

[0038] IO hub 112 is a functional block or device that performs operations to interface between IO devices 108-110 and other functional blocks within electronic device 100. In other words, IO hub 112 performs operations to route communications and other data between IO devices 108-110 and functional blocks such as processor 102, memory 104, etc. The particular communications routed by IO hub 112 and the operations performed to route the communications depend on the nature of IO devices 108-110, but may include memory access, data communications, control and configuration communications, etc.

[0039] IO hub 112 includes input / output memory management unit (IOMMU) 140, which is a functional block that performs operations to process memory accesses by IO devices 108-110. When data in memory 104 is accessed by an IO device, the IO device sends a corresponding memory access request. IOMMU 140 intercepts the memory access request from the IO device, processes the request internally to determine whether the memory access request can proceed, and then (assuming the memory access request can proceed) sends a corresponding request to memory 104 to access the data.

[0040] Among the operations performed by IOMMU 140 to process memory access requests from IO devices 108-110 is performing address translation for memory accesses to IO devices 108-110 (i.e., to obtain a physical address in memory associated with a virtual address used by IO devices 108-110 in a memory access request). IOMMU 140 includes input-output table walker (IOTW) 142, which is a functional block that performs operations related to obtaining address translations from page tables (e.g., page table walks, etc.). The operations performed by IOTW 142 are similar to those performed by table walker 136, but with respect to memory accesses from IO devices 108-110 (rather than processor 102). In some embodiments, along with performing address translation, IOTW 142 checks page information, such as metadata and migration state information, to determine whether memory accesses from IO devices 108-110 are permitted for a page of memory and / or whether the page of memory has been migrated as described herein. In these embodiments, I / O table walker 142 may block or otherwise handle memory accesses to avoid inappropriate memory accesses or memory accesses to pages being migrated. In some embodiments, I / O table walker 142 uses a hierarchy of page tables, including page tables associated with IOMMU 140, host page tables, and / or nested page tables associated with software entities (e.g., hypervisors, virtual machines, etc.), and therefore performs table walks in that hierarchy.

[0041] IOMMU 140 also includes a translation lookaside buffer (TLB) 144, which is a functional block used to store copies of information obtained from page table entries. TLB 144 includes memory circuitry for caching and storing copies of page table entries or portions thereof obtained during a page table walk by table walker I / O table walker 142 (or from other sources). To avoid performing a page table walk, IOMMU 140 obtains address translation information and / or other page table entry information from TLB 144, when possible. However, if the address translation information and / or other page table entry information is not present in TLB 144, I / O table walker 142 performs a table walk to obtain the information. In some embodiments, the specified information in TLB 144 is invalidated before the corresponding page is migrated, as described herein.

[0042] In some embodiments, some or all of the IO devices 108-110 include a local cache for storing copies of information obtained from page table entries. For example, in some embodiments, some or all of the IO devices 108-110 and the IOMMU 140 provide support for address translation services (ATS), under which the IOMMU 140 may provide and cache copies of information obtained from page table entries to the IO devices 108-110. An example of such a cache is shown as an address translation cache (ATC) 146 in the IO device 108. The ATC 146 includes memory circuitry for caching copies of page table entries or portions thereof obtained during page table walks by the I / O table walker 142 (or from other sources). To avoid performing page table walks, the IO device 108 obtains address translation information and / or other page table entry information from the ATC 146, when possible. However, if the address translation information and / or other page table entry information is not present in the ATC 146, the I / O table walker 142 performs a table walk to obtain the information (or uses cached information from the TLB 144). In some embodiments, the specified information in the ATC 146 is invalidated before the corresponding page is migrated, as described herein.

[0043] In some embodiments, although shown as a single entity in FIG. 1 , IOMMU 140 includes multiple individual IOMMUs (e.g., multiple instances of an IOMMU functional block). For example, in some embodiments, electronic device 100 includes at least two IOMMU functional blocks, each controlling memory accesses by a subset of the set of IO devices in electronic device 100. In these embodiments, these IOMMUs work together or through a “master” IOMMU or other functional block to ensure that the IOMMUs use information in the page tables to properly access the memory of the IO devices, including when there are pages of memory in transition as described herein. For example, the IOMMUs may broadcast requests and acknowledgments, such as invalidating TLBs, completing or stalling memory accesses, over the communication link to which all IOMMUs are connected to ensure that all of the IOMMUs are synchronized before performing operations such as allowing a given IOMMU to access information in a page table entry or allowing a memory access from an IO device to proceed.

[0044] The page migration engine 114 is a functional block that performs operations associated with accessing data in memory 104. The page migration engine 114 may be used to offload memory access operations from other functional blocks in the electronic device 100. For example, in some embodiments, the page migration engine 114 offloads, and thus receives and performs, memory accesses on behalf of the cores 116-118, thereby allowing the cores 116-118 to avoid performing memory access operations. In some embodiments, the page migration engine 114 includes, among other functional blocks, one or more direct memory access (DMA) functional blocks that perform operations to move pages of memory within the memory 104. Some memory access operations performed by the page migration engine 114 may "migrate" pages of memory within the memory 104. Upon receiving a request for migration from one of cores 116-118 (e.g., from an operating system running by core 116) or from another source, such as PSP 128, identifying a page of memory and a new location within memory where the page of memory will be stored, page migration engine 114 moves the page of memory to the new location (i.e., physically moves individual bits / bytes within the page of memory to the new location in one or more data move operations). In conjunction with migrating a page of memory, page migration engine 114 performs operations to handle the migration of a page of memory that is accessible to an IO device, as described herein.

[0045] 1 as a single entity, page migration engine 114 includes multiple individual page migration engines (e.g., multiple instances of a page migration engine functional block). For example, in some embodiments, page migration engine 114 includes at least two page migration engines, each arranged to perform memory accesses, including migrating pages of memory as described herein, on behalf of other functional blocks within electronic device 100. In these embodiments, page migration tasks / requests are distributed among two or more page migration engines according to a distribution scheme (e.g., round robin, by memory address or location in memory, etc.), the page migration engines may coordinate accesses to avoid designated memory accesses, etc.

[0046] In some embodiments, communication paths are coupled between functional blocks in electronic device 100, as indicated by arrowed lines between the functional blocks. The communication paths include one or more buses, wires, guides, and / or other connections, possibly involving controllers, fabric elements (e.g., switches, routers, etc.), etc. The communication paths are used to route commands, data, control signals, and / or other information between the functional blocks. For example, in some embodiments, an interconnect fabric is coupled between IO hub 112, processor 102 (e.g., MMU 134), and memory 104. Note that some communication paths are not shown in FIG. 1 for clarity.

[0047] 1 with a particular number and arrangement of functional blocks and devices, in some embodiments, electronic device 100 includes a different number and / or arrangement of functional blocks and devices. For example, in some embodiments, processor 102 includes a different number of cores. As another example, in some embodiments, a different number and / or arrangement of caches are present in processor 102. As yet another example, in some embodiments, IO device 108 does not include an address translation cache, or both IO devices 108-110 include a translation cache. Generally, in the described embodiments, electronic device 100 includes a sufficient number and / or arrangement of functional blocks to perform the operations described herein.

[0048] 1 is simplified for purposes of explanation. However, in some embodiments, electronic device 100 and / or processor 102 include additional or different elements and mechanisms for performing the operations described herein and other operations. For example, electronic device 100 and / or processor 102 may include power functional blocks or devices, human interface functional blocks or devices, etc.

[0049] 1 are implemented together. For example, in some embodiments, IO hub 112 and some or all of IO devices 108-110 are incorporated within / with processor 102, such as by being fabricated on the same integrated circuit chip. In other words, in such embodiments, IO hub 112 and IO devices 108-110 may be integrated with processor 102 (e.g., as a "system-on-chip" or otherwise). Alternatively, in some embodiments, functional blocks shown as part of other functional blocks may be separate. For example, in some embodiments, platform security processor 128 is implemented separately from processor 102.

[0050] Electronic device 100 may be or may be included in any electronic device that performs computing operations. For example, electronic device 100 may be or may be included in a desktop computer, a laptop computer, a wearable electronic device, a tablet computer, a smartphone, a server, an artificial intelligence device, a virtual or augmented reality device, a network device, a toy, an audiovisual device, a home appliance, a controller, a vehicle, etc., and / or combinations thereof.

[0051] (operating system) In some embodiments, one or more software entities interact with functional blocks within the electronic device to perform operations to handle migration of pages of memory accessible to the IO device. In some of these embodiments, the one or more software entities are or include an operating system. Figure 2 is a block diagram illustrating an operating system and functional blocks and devices within the electronic device, according to some embodiments. Note that Figure 2 is simplified and generally illustrates the relationship between the operating system and the electronic device hardware. In some embodiments, some or all of the elements shown in Figure 2 are not present and / or are arranged differently.

[0052] As seen in FIG. 2 , operating system 200 interfaces between electronic device hardware 202 (i.e., between functional blocks and devices of electronic device 100, such as processor 102) and a set of programs 204-208. For example, operating system 200 may be an operating system such as Windows® from Microsoft (Redmond, WA) or macOS® from Apple, Inc. (Cupertino, CA), and each of programs 204-208 may be a productivity application, a scientific computing application, a web browser, etc. IOMMU 210 interfaces between IO devices 212 and electronic device hardware 202 (e.g., memory 104, etc.). In some embodiments, the functional blocks and devices of FIG. 2 , i.e., electronic device hardware 202, IOMMU 210, and IO devices 212, are similar to the hardware (e.g., processor 102, memory 104, page transition engine 114, etc.), IOMMU 140, and IO devices 108-110, respectively, in electronic device 100, as shown in FIG. 1 .

[0053] (Virtual Machines and Hypervisors) In some embodiments, one or more software entities interact with functional blocks within the electronic device to perform operations to handle migration of pages of memory accessible to the IO device. In some of these embodiments, the one or more software entities are or include a hypervisor. Generally, in some embodiments, a processor within the electronic device executes one or more virtual machines. A virtual machine is a software entity that emulates or otherwise interfaces with the processor and other functional blocks and devices (e.g., memory, IO devices, etc.) within the electronic device to provide support for executing software programs. For example, a virtual machine may provide support for running one or more instances of an operating system, called a guest operating system. The guest operating system, in turn, provides support for running other software programs, such as applications, databases, etc. In some embodiments, the processor also executes a hypervisor, which is a software entity that performs operations to control / manage the execution of the virtual machines. For example, the hypervisor may start and initialize virtual machines, help control the virtual machines' access to functional blocks and devices within the electronic device (e.g., by directing which areas of memory and / or IO devices the virtual machines are allowed to access), terminate or shut down virtual machines, etc. Figure 3 is a block diagram illustrating a hypervisor and functional blocks and devices within an electronic device, according to some embodiments. Note that Figure 3 is simplified and generally illustrates the relationship between the hypervisor and the electronic device hardware. In some embodiments, some or all of the elements shown in Figure 3 are not present and / or are located differently.

[0054] As shown in FIG. 3 , there are three virtual machines (VMs) 300-304, each running a corresponding guest operating system (GUEST OS) 306-310 and one or more programs (PRGRMS) 312-316. A hypervisor 318 interfaces between a host operating system 320 and the virtual machines 300-304. The host operating system 320 interfaces between the electronic device hardware 322 and the hypervisor 318. An IOMMU 324 interfaces between an IO device 326 and the electronic device hardware 322. In some embodiments, the functional blocks and devices of FIG. 3 , i.e., the electronic device hardware 322, the IOMMU 324, and the IO device 326, are similar to the hardware (e.g., the processor 102, the memory 104, the page migration engine 114, etc.), the IOMMU 140, and the IO devices 108-110, respectively, in the electronic device 100, as shown in FIG. 1 .

[0055] (page table entry) In described embodiments, functional blocks and devices within an electronic device (e.g., processor 102, IOMMU 140, etc.) use one or more page tables to perform virtual-to-physical address translations and for other operations. FIG. 4 is a block diagram illustrating a page table 400, according to some embodiments. As seen in FIG. 4, page table 400 includes several page table entries 402 (one of which is highlighted using dashed lines), each of which may store a virtual address (VA) to physical address (PA) translation 404 along with corresponding metadata 406. In some embodiments, page table 148 of FIG. 1 is arranged internally similar to page table 400.

[0056] Generally, when a page of memory (i.e., a block, section, or portion of memory of a specified size, such as 4 KiB, 2 MiB, etc.) is retrieved from mass storage 106 and stored in memory 104, or newly created in memory 104, a corresponding page table entry 402 is added to page table 400 along with a virtual-to-physical address translation 404 and metadata 406. Thus, if a page of memory is available in memory 104, page table 400 should include the corresponding page table entry 402. Page table entry 402 is added to page table 400 to enable tracking of the relationship between the physical address of the page in memory and the virtual addresses used by software entities (e.g., programs, firmware, operating systems, etc.) and devices to access the page of memory as described above.

[0057] In some embodiments, the virtual address to physical address translation 404 in each page table entry 402 in page table 400 includes information that can be used to determine the physical addresses of corresponding pages in memory associated with one or more virtual addresses. In other words, each virtual address to physical address translation 404 includes information that can be used to identify the location in memory 104 of a page of memory that is addressed by a software entity and / or device using the respective virtual address. For example, in some embodiments, each virtual address to physical address translation 404 includes a first field with some or all of one or more virtual addresses (e.g., N bits of the M bits of the respective virtual address, where N≦M) and a second field with some or all of the physical addresses to which the one or more virtual addresses map / match.

[0058] Metadata 406 includes information associated with, characterizing, controlling, and / or otherwise relating to a corresponding virtual-to-physical address translation 404. When translation information for a page of memory is added to a page table entry 402 in page table 400, metadata is obtained, generated, etc., and added to that page table entry 402. FIG. 5 is a block diagram illustrating metadata 406 in a page table entry, according to some embodiments. As seen in FIG. 5, metadata 406 includes validity 500, permission 502, control 504, and migration state information (MIG STATE INF) 506. Validity 500 includes one or more values ​​related to the validity of the page table entry 402 of the page table, the virtual-to-physical address translation 404 in that page table entry 402, and / or the corresponding page of memory in memory 104. For example, validity 500 may include one or more bits indicating whether the page table entry 402 itself is valid / accessible and / or whether the corresponding page in memory 104 is valid / accessible.

[0059] Permissions 502 include one or more values ​​related to access permissions for the corresponding page in memory 104. For example, permissions 502 may include one or more bits that indicate whether the corresponding page in memory 104 has read-only or read-write permissions set, whether the page is accessible only by a particular privilege (administrator, user, kernel, etc.), and / or other permission information.

[0060] Control 504 includes one or more values ​​related to the use of page table entry 402 and / or the corresponding page in memory 104. For example, control 504 may include a page size indicator, a dirty indicator (if the corresponding page in memory 104 has been modified and therefore does not match the associated block of memory in mass storage device 106), an access indicator (if the page in memory 104 has been accessed one or more times), a write-through indicator (if modifications to a page in memory 104 are immediately reflected in the associated block of memory on mass storage device 106), and / or other values.

[0061] The migration state information 506 includes one or more values ​​that indicate whether the associated page is being prepared for migration or whether the associated page is being migrated. For example, in some embodiments, the migration state information includes a sufficient number of bits to uniquely identify each possible migration state for the corresponding page of memory. For example, if there are six migration states, with a first migration state for a page that is not being migrated, a sixth migration state for a page that is actively being migrated, and four intermediate migration states for various preparatory operations to prepare the page of memory for migration, the migration state information may be stored in three bits. Functional blocks or devices that access the page table entry may use the migration state information 506 to determine which operations are (or are not) permitted for the page of memory and / or the information in the page table entry 402 of the corresponding page table. For example, in some embodiments, if the migration state indicates that a page of memory is being prepared for migration or that a page of memory is being migrated, the accessing functional block or device may determine that a copy of information from the page table entry is not allowed to be cached in a local cache and / or that some or all memory accesses to the page of memory are restricted.

[0062] In some embodiments, one or both of virtual to physical address translation 404 and metadata 406 may be modified / changed, updated, etc. after being added to page table 400. For example, if a page is moved from a first location to a second location in memory 104, the virtual to physical address translation 404 in the corresponding page table entry 402 may be updated. As another example, in embodiments in which metadata 406 includes permissions 502 (e.g., read / write permissions), permissions 502 may be updated to indicate read-only, read / write, etc. permissions for the corresponding page in memory 104. As yet another example, migration state information 506 may be updated as functional blocks and devices progress through migration states to migrate pages of memory.

[0063] As described above, when attempting to obtain physical address information or metadata for a specified virtual address, MMU 134, IOMMU 140, or another entity within electronic device 100 may perform a page table walk. During the page table walk, MMU 134, IOMMU 140, etc., searches page table 400 to find a page table entry 402 that holds a corresponding virtual-to-physical address translation 404, if such a page table entry 402 exists. Upon encountering such a page table entry 402, MMU 134, IOMMU 140, etc., obtains the physical address (i.e., the virtual-to-physical address translation 404 in page table entry 402) or metadata for the specified virtual address from the page table entry 402. If MMU 134, IOMMU 140, etc., cannot find a corresponding page table entry 402, an error handling operation is performed (e.g., a page fault is issued and then handled, etc.). In described embodiments, functional blocks and devices (e.g., IOMMU, page migration engine, etc.) within an electronic device perform operations to prevent an IO device from encountering problems with a missing or unavailable page table entry (or corresponding page of memory) due to the migration of the corresponding page of memory. For example, in some embodiments, when determining the virtual to physical address translation for a memory access request, the I / O table walker 142 checks the migration state information 506 in each page table entry 402 to determine whether the virtual to physical address translation 404 is allowed to be cached by the IOMMU 140 and / or the IO devices 108-110 and / or whether the memory access will be stalled due to the current migration state.

[0064] While page table 400 is shown with a particular number of page table entries 402, some embodiments include a different number of page table entries 402 (as indicated by the ellipsis in FIG. 4 ). Further, while page table entries 402 and metadata 406 are shown with a particular arrangement and type of information, in some embodiments, one or both of page table entries 402 and metadata 406 include different information. For example, in some embodiments, at least some of the metadata described above is stored in a location other than page table entries 402. For example, in some embodiments, a separate in-memory data structure is used to store transition state information. In general, page table 400 includes sufficient information to enable functional blocks and devices within an electronic device to store and retrieve virtual-to-physical address translation information and metadata as described herein.

[0065] Although page table 400 is shown as a single page table, in some embodiments, page table 400 is organized differently. For example, in some embodiments, page table 400 is implemented using two or more sub-tables arranged in a hierarchy. In these embodiments, a search of each sub-table directs a search functional block or device to the next sub-table in the hierarchy until the final sub-table is reached, where the virtual to physical address translation 404 and metadata 406 are stored in the corresponding page table entry 402.

[0066] (Transition state) In some embodiments, functional blocks, devices, and / or software entities within the electronic device (e.g., IOMMU 140, page migration engine 114, processor 102, operating system 200, and / or hypervisor 318) progress through a set of migration states as pages of memory are prepared for migration and then migrated. In each of the migration states, apart from an initial non-migration migration state, respective operations are performed to prepare pages of memory for migration and / or to migrate pages of memory. Requests for access to information within pages of memory and / or respective page table entries to be migrated or being migrated are processed by functional blocks and devices within the electronic device (e.g., IOMMU 140, page migration engine 114, etc.) based on the current migration state of the pages of memory. Generally, the requests are processed such that the functional blocks and devices continue to operate correctly while the operations of the respective migration states are performed. For example, IO devices (eg, IO devices 108-110) and / or processors (eg, processor 102) are protected from errors and faults that may result from accessing pages of memory and / or respective page table entries during migration.

[0067] 6 is a state diagram illustrating transition states, according to some embodiments. Generally, the transition states illustrated in FIG. 6 are one example of transition states that functional blocks, devices, and / or software entities within an electronic device (e.g., electronic device 100) may progress through as they prepare for and then migrate pages of memory. While a particular number and arrangement of transition states and transitions between transition states are illustrated in FIG. 6, in some embodiments, a different number and / or arrangement of transition states and / or different transitions between transition states may be used.

[0068] In Figure 6, the transitions between the transition states are shown using arrowed lines between the transition states. A first set of transitions between the transition states are shown using thicker lines, and other transitions between the transition states are shown using thinner lines. In the following description, the first set of transitions between the transition states will be described, followed by other transitions between the transition states. However, it should be noted that the use of different line thicknesses is merely for clarity in describing the transition states and the transitions between the transition states.

[0069] As shown in FIG. 6 , the migration states include migration states (MS) 600-606. In migration state 600, which is a “non-migration” migration state, a page of memory has not been migrated and therefore will remain in its current location in memory. Thus, migration state 600 is a migration state in which a page of memory is maintained until it is migrated (or, more generally, a page of memory is retained until it is migrated). In migration state 600, migration state information (e.g., migration state information 506) in the page table entry for the page of memory is set to a bit sequence, value, etc. that represents or identifies the page of memory as being in migration state 600. For example, assuming the migration state information includes two bits, the migration state information (MS) may be set to 00 to represent or identify migration state 600.

[0070] In the migration state 600, the IOMMU allows accesses of the page of memory and the respective information in the page table entry from the IO device to proceed normally because the migration state information in the page table entry identifies the page of memory as being in the migration state 600. That is, because no preparations have been made to migrate the page of memory and the page of memory has not been migrated, accesses of the page of memory and the information in the page table entry are not prevented, stalled, or otherwise restricted by the IOMMU. In other words, in the migration state 600, the IOMMU uses the information from the page table entry normally and performs memory accesses of the page of memory normally.

[0071] However, in some embodiments, although access of the page of memory and its respective page table entry is not restricted in the transition state 600 due to the transition of the page of memory, other restrictions on access of the information within the page of memory and page table entry may still be enforced. For example, if the page of memory is not accessible to IO devices because it is a private page of memory that is not normally accessible to IO devices, then being in the transition state 600 does not change such access restrictions.

[0072] Upon encountering a request to migrate a page of memory from a software entity (e.g., a hypervisor, an operating system, etc.) or a request forwarded from a platform security processor (e.g., PSP 128), the functional blocks, devices, and software entities proceed to transition state 602 (as indicated by the thick arrowed line between transition states 600 and 602). When entering transition state 602, the software entity sets the migration state information in the page table entry for the page of memory to a bit sequence, value, etc. that represents or identifies transition state 602. For example, assuming the migration state information includes two bits, the migration state information may be set to 01 to represent or identify transition state 602.

[0073] In the migrating state 602, initial preparations for migrating a page of memory within memory occur. The preparations include the IOMMU preventing caching (i.e., storing) a new copy of information from the page table entry for the page of memory in local caches within the IOMMU and / or IO device (e.g., TLB 144, ATC 146, etc.). Generally, because a subsequent migration of the page of memory would cause the copy of information from the page table entry to be incorrect due to the page of memory being located at a new physical address in memory, the copy of information from the page table entry is prevented from being stored in local caches within the IOMMU or IO device until the page of memory is migrated and the page table entry is updated. Thus, in the migrating state 602, because the migration state information in the page table entry identifies the page of memory as being in the migrating state 602, the IOMMU does not obtain a copy of information from the page table entry to cache such a copy within its own local cache and / or provide such a copy to the IO device for storage within the IO device's local cache.

[0074] In some embodiments, the IOMMU denies an ATS request from an IO device for a copy of information from a page table entry if it does not provide the IO device with a copy of information from the page table entry. For example, in some embodiments, the IOMMU can respond to the ATS request by notifying the requesting IO device that the page of memory does not exist, causing the IO device to proceed with the operation to bring the page into existence. As another example, the IOMMU can notify the requesting IO device that an untranslated address should be used to access the page of memory, such that information from the page table entry is not provided to the requesting IO device.

[0075] In transition state 602, a software entity causes the IOMMU to invalidate any existing copies of information from page table entries in the IO device's local cache, e.g., in an Address Translation Cache (ATC). Invalidating these entries prevents subsequent invalidation and / or modification of copies of information from page table entries in the IO device's local cache. Note, however, that copies of information from page table entries in the IOMMU's local cache that may still be needed to perform memory accesses in transition state 602 and subsequent transition states are retained in transition state 602 and are eventually invalidated in the subsequent transition state (i.e., transition state 604).

[0076] In migration state 602, as opposed to subsequent migration states (i.e., migration states 604 and 606), the IOMMU allows memory accesses from IO devices to the page of memory to proceed without restriction. In other words, both existing / outstanding memory accesses from IO devices and newly encountered memory accesses are allowed to proceed. Allowing memory accesses to proceed clears / completes memory accesses for pages of memory in preparation for migrating the page of memory (because pages of memory should not be migrated with memory accesses outstanding) without unnecessarily delaying the operation of the IO device.

[0077] From transition state 602, functional blocks, devices, and software entities progress to transition state 604 (as indicated by the thick arrowed line between transition states 602 and 604). For example, after performing the operations of transition state 602, the software entities may request that a page migration engine migrate a page of memory, causing entry into transition state 604. When entering transition state 604, the page migration engine sets migration state information in the page table entry for the page of memory to a bit sequence, value, etc. that represents or identifies transition state 604. For example, assuming the transition state information includes two bits, the migration state information may be set to 10 to represent or identify transition state 604.

[0078] In the migrating state 604, preparations continue to be made to migrate the page of memory within the memory. The preparations include the IOMMU stalling newly encountered memory accesses of a first type from the IO device to the page of memory. For example, in some embodiments, the first type of memory accesses include memory accesses such as reads, compares, and swaps that cause a response (e.g., returned data, etc.) from the memory to the requesting IO device, as opposed to memory accesses of a second type such as writes, invalidates, etc. that do not cause a response. Thus, in the migrating state 604, because the migration state information in the page table entry identifies the page of memory as being in the migrating state 604, the IOMMU stalls newly encountered memory accesses of the first type until the migration of the page of memory is complete (e.g., returning to the migrating state 600). For example, the IOMMU may hold the newly encountered memory accesses of the first type in a buffer, memory element, etc. (e.g., by storing information about the memory access request from the IO device), and then release the held memory accesses from the buffer, memory element, etc. after the migration of the page of memory is complete. Note, however, that existing / outstanding memory accesses of the first type that were in progress before entering transition state 604 are allowed to complete, and memory accesses of the second type, both existing / outstanding memory accesses and newly encountered memory accesses, are allowed to proceed. In some embodiments, newly encountered memory accesses of the first type are stalled separately from newly encountered memory accesses of the second type (which are stalled in transition state 606, as described below) to avoid contention, deadlock conditions, and / or other problems that may arise between memory accesses of the first type and memory accesses of the second type.

[0079] In the migrating state 604, the page migration engine invalidates any existing copies of information from the page table entry in the IOMMU's local cache (recall that existing copies of information from the page table entry in the IO device's local cache were previously invalidated in the migrating state 602). For example, the page migration engine may issue an invalidation request to the IOMMU, causing the IOMMU to invalidate any existing copies of information from the page table entry in its local cache. In the migrating state 604, the IOMMU continues to prevent the IOMMU and / or the IO device from storing copies of information from the page table entry for the page of memory in their local caches, as described above for the migrating state 602.

[0080] From transition state 604, functional blocks, devices, and software entities progress to transition state 606 (as indicated by the thick arrowed line between transition states 604 and 606). For example, the page migration engine may enter transition state 606 after completing invalidation of any existing copies of information from page table entries in the IOMMU's local cache in transition state 604. When entering transition state 606, the page migration engine sets migration state information in the page table entry for the page of memory to a bit sequence, value, etc. that represents or identifies transition state 606. For example, assuming the transition state information includes two bits, the migration state information may be set to 11 to represent or identify transition state 606.

[0081] In the migrating state 606, the memory is prepared to migrate the page of memory, and then the page of memory is migrated. The operation includes the IOMMU stalling all newly encountered memory accesses from IO devices to the page of memory. Thus, in the migrating state 606, because the migration state information in the page table entry identifies the page of memory as being in the migrating state 606, the IOMMU stalls newly encountered memory accesses of both the first type and the second type until the migration of the page of memory is complete (e.g., until returning to the migrating state 600). For example, the IOMMU may hold newly encountered memory accesses of both the first type and the second type in a buffer, memory element, etc. (e.g., by storing information about the memory access request from the IO device), and then release the held memory accesses from the buffer, memory element, etc. after the migration of the page of memory is complete. In the transition state 606, the IOMMU continues to prevent the IOMMU and / or IO devices from storing copies of information from page table entries for the page of memory in their local caches, as described above for the transition state 602.

[0082] In the migration state 606, all newly encountered memory accesses from IO devices are stalled, but existing / outstanding memory accesses are completed. In other words, all remaining memory accesses that were in progress before entering the migration state 606 are completed. All existing / outstanding memory accesses are completed, so that memory accesses of a page of memory do not access the page of memory during the migration (as stale / incorrect data may be accessed).

[0083] Preparation for migrating a page of memory is completed after existing / outstanding memory accesses are completed and therefore all remaining accesses to the page of memory are stalled in preparation for migrating the page of memory. Thus, the page migration engine migrates the page of memory within memory. For example, the page migration engine may move the page of memory from a first location / physical address within memory to a second location / physical address within memory (e.g., a location specified in a request to migrate the page of memory). In some embodiments, the movement within memory is from a first type of memory (e.g., memory of a slower access type) to a second type of memory (e.g., memory of a faster access type), or vice versa. Although migration state 606 is shown as a single migration state, in another example, the migration state may be divided into migration state 606A, in which existing / outstanding memory accesses of the second type are completed, and migration state 606B, in which the page of memory is migrated / moved within memory and cleanup operations (as described below) are performed in preparation for returning the page of memory to migration state 600.

[0084] After migrating the page of memory, the page migration engine updates (or causes another functional block or software entity to update) the page table entry to identify the physical address where the page of memory is stored (i.e., the physical address of the second location in memory). By updating the page table entry, the page migration engine updates the virtual address to physical address translation information for the page of memory so that virtual addresses used by software entities and devices within the electronic device can be correctly mapped to the physical address where the page of memory is stored. The page migration engine also sets any associated metadata in the page table entry (if necessary) based on the second location in memory.

[0085] Because the page of memory has been successfully migrated, the functional blocks, devices, and software entities return to the migrated state 600 (as indicated by the thick arrowed line between the migrated state 606 and 600). As part of returning to the migrated state 600, the page migration engine sets the migration state information in the page table entry for the page of memory to a bit sequence, value, etc. that represents or identifies the migrated state 600. For example, assuming the migration state information includes two bits, the migration state information may be set to 00 to represent or identify the migrated state 600. As described above, the migrated state 600 is a "non-migrated" migration state. Because the migration state information in the page table entry identifies the page of memory as being in the migrated state 600, the IOMMU allows accesses of the page of memory and the respective information in the page table entry from IO devices to proceed normally. That is, because no preparations have been made to migrate the page of memory and the page of memory has not been migrated, accesses of the page of memory and the information in the page table entry are not prevented, stalled, or otherwise restricted by the IOMMU.

[0086] Upon returning to transition state 600, the IOMMU releases the first and second type stalled memory accesses to pages of memory that were previously stalled between transition states 604 and 606. For example, in some embodiments, the stalled memory accesses are held by the IOMMU while the IOMMU polls / periodically reads the page table entries. When the IOMMU finds that the page table entry identifies the page of memory as being in transition state 600, the IOMMU begins retrieving the stalled memory accesses in first-in-first-out order from the buffer or memory element in which they were stored and executes each of the memory accesses.

[0087] In some embodiments, the IOMMU executes each stalled memory access before other newly encountered memory accesses for the page of memory (which may themselves be held and then released in the order in which they were received or in another order). In addition, the IOMMU resumes caching information from the page table entry in a local cache. In other words, the IOMMU may itself cache a copy of the information from the page table entry and provide a copy of the information from the page table entry to the requesting IO device. The page migration engine also returns a response to the requesting software entity indicating that the page of memory has been successfully migrated. This completes the migration of the page of memory.

[0088] The example of FIG. 6 assumes that the migration attempt is successful, and therefore, all operations to prepare the page for migration and then migrate the page are successful. However, if one of the operations fails or an undesirable or unexpected condition or error is encountered, the page migration may be terminated. When the migration is terminated, the functional blocks, devices, and software entities return from the current transition state (which may be any of transition states 602-606) to transition state 600. This is indicated by the corresponding thin arrowed lines between transition states 602-604 and transition state 600, and the thick arrowed line between transition state 606 and transition state 600. Upon terminating the migration of a page of memory, the software entity, page migration engine, or another functional block or device restores the migration state information in the page table entry for the page of memory to a bit sequence, value, etc., that represents or identifies the migration state 600. For example, assuming the migration state information includes two bits, the migration state information may be set to 00 to represent or identify the migration state 600. Upon returning to the migration state 600 due to a failure to migrate a page of memory, the IOMMU releases any stalled memory accesses for the page of memory, resumes caching copies of information from the page table entry in the local caches of the IOMMU and IO devices, and more generally removes the effect of preparing to migrate the page of memory.

[0089] In some embodiments, despite the restrictions on memory accesses of migrating pages of memory and the caching of information from their respective page table entries in the local cache, accesses to non-migrating pages of memory and their respective page table entries proceed normally. That is, because no provision is made to migrate non-migrating pages of memory and the non-migrating pages of memory are not migrated, accesses to non-migrating pages of memory and the information in their respective page table entries are not prevented, stalled, or otherwise restricted by the IOMMU. In other words, the IOMMU uses information from such page table entries normally and performs memory accesses of such pages of memory normally. In some embodiments, the migration state information for the non-migrating pages is set to indicate that the non-migrating pages are in the migrating state 600. However, certain memory accesses of non-migrating pages of memory may be held up for ordering reasons and / or other reasons based on the migration of the pages of memory, but generally may proceed as long as the non-migrating pages of memory and their respective page table entries remain correct in memory.

[0090] In some embodiments, functional blocks, devices, and software entities may transition between transition states in a different order. For example, in some embodiments, transition states may be skipped, as indicated by thin arrowed lines between transition states. For example, in some embodiments, a page of memory that is accessible only to the processor (and therefore not accessible to IO devices) may transition directly from transition state 600 to transition state 606. In these embodiments, the processor includes a page fault mechanism for handling missing pages of memory, and the software entities and / or page migration engine may simply mark the page of memory as missing in the respective page table entry and proceed with the migration of the page of memory. In some embodiments, the processor uses different page tables than the IOMMU, and therefore the page of memory is marked as "missing" during migration in the processor's page table, whereby the page of memory is processed by the processor using the processor's page fault mechanism. However, in some embodiments, the processor uses the same page tables as the IOMMU, although the indicators available in the processor and the IOMMU are different. In these embodiments, the processor's available indicator may be set such that a page of memory is processed by the processor using the processor's page fault mechanism, but the page of memory remains "available" for processing by the IOMMU (such as via stalling memory accesses) as described herein.

[0091] While the example shown in FIG. 6 illustrates only a single memory page being migrated, in some embodiments, preparation for migration of multiple memory pages and / or migration of multiple memory pages may occur in parallel. In other words, using the migration state information described above for each memory page, preparation for migration of two or more memory pages and / or migration of two or more memory pages may occur at the same or similar time, simultaneously, etc. Note that individual memory pages in this case are in different migration states, and thus, migration of a memory page may be dynamically initiated (e.g., as a software entity determines that the respective memory page is to be migrated) and completed in parallel with preparation for migration of multiple memory pages and / or migration of other memory pages. Thus, each memory page is individually identifiable via its page table entry as being in one of the migration states or a non-migration state, and operations for processing accesses of the memory page and / or respective page table entries are performed as described herein.

[0092] (The process that handles the migration of pages of memory) In described embodiments, software entities (e.g., hypervisor 318, operating system 200, etc.) and a page migration engine (e.g., page migration engine 114) perform operations to control memory access of a page of memory and associated page table entries while the page of memory is being prepared for migration and while the page of memory is being migrated within memory (e.g., memory 104). FIG. 7 is a flow diagram illustrating a process for migrating a page of memory, according to some embodiments. FIG. 7 is presented as a general example of operations performed by a requestor in some embodiments. However, in some embodiments, a requestor performs different operations and / or performs operations in a different order.

[0093] 7, the process begins when, while performing operations within the memory, software entities, and page migration engine to prepare a page of memory accessible to an IO device for migration, they set migration state information in a page table entry for the page of memory based on the operations being performed (step 700). Generally, for this operation, when the software entities and page migration engine perform their respective operations to prepare a page of memory (e.g., a 4 KiB page of memory) for migration, the software entities and page migration engine update the migration information in the page table entry for the page of memory to indicate the current / as-current migration state. As described above, in migration states 602-606, the software entities and / or page migration engine perform operations to prepare the page of memory for migration, and then, in migration state 606 (which, as described above, may be divided into migration state 606A, in which existing / outstanding memory accesses of the second type are completed, and migration state 606B, in which the page of memory is migrated / moved within memory and cleanup operations are performed), the page migration engine performs operations to migrate the page of memory. Thus, setting the migration state information in a page table entry for a page of memory based on the operation being performed involves setting the migration state to identify the migration state of the page of memory. For example, after receiving a request to migrate a page of memory, while (or before) performing initial operations to prepare the page of memory for migration, a software entity may set the migration state information to migration state 602, such as by setting a bit sequence or value indicative of migration state 602 to migration state.

[0094] In some embodiments, the particular operations performed by the software entities and IO devices depend on the current migration state of the page of memory. For example, in some embodiments, among the operations performed by the software entities are operations to invalidate (via corresponding commands to the IOMMU) any existing copies of information from page table entries in caches in at least one IO device. In some embodiments, the software entities perform this operation in the migration state 602. As another example, in some embodiments, among the operations performed by the page migration engine are operations to invalidate any existing copies of information from page table entries in caches in the IOMMU. In some embodiments, the page migration engine performs this operation in the migration state 604. As yet another example, in some embodiments, among the operations performed by the page migration engine are operations to complete any memory accesses to the page of memory that are not stalled by the IOMMU before migrating the page of memory. In some embodiments, the page migration engine performs these operations in the migration states 602-606. The particular sequence / order in which these operations are performed by the software entities and the page migration engine is described above with respect to FIG. 6.

[0095] The IOMMU controls the use of information from a page table entry based on the migration state information in the page table entry (step 702). To do this, the IOMMU (or rather, the IOMMU table walker) obtains the migration state information and checks the current value of the migration state information when it performs a table walk. If the migration state information indicates that a page of memory is being prepared for migration and / or that a page of memory has been migrated, the IOMMU restricts the use of information from the page table. For example, in migration states 602-606, the IOMMU may prevent caching a copy of information from the page table entry in its own cache or in an IO device. In contrast, if the migration state information, such as in migration state 600, indicates that the page has not been migrated, the IOMMU may use information from the page table normally. Thus, in a non-migration state, the IOMMU may cache a copy of information from the page table entry itself and may provide an IO device with a copy of information from the page table entry (subject to any other existing access restrictions).

[0096] The IOMMU also controls execution of memory accesses to the page of memory based on the migration state information in the page table entry (step 704). For this operation, the IOMMU obtains the migration state information from the page table entry and checks the current value of the migration state information, as described above. If the migration state information indicates that the page of memory is being prepared for migration and / or that the page of memory is being migrated, the IOMMU may restrict memory accesses to the page of memory. For example, in migration states 604-606, the IOMMU may stall designated newly encountered memory accesses to the page of memory, but existing memory accesses are allowed to proceed to completion before the page of memory is migrated. In contrast, if the migration state information indicates that the page is in another migration state, such as migration states 600-602, the IOMMU may allow all memory accesses to the page of memory to proceed normally. Thus, in these migration states, the IOMMU executes memory accesses to the page of memory in a typical manner, subject to any other existing access restrictions.

[0097] While FIG. 7 presents an example of setting and using state information when a page of memory is being prepared for migration, in some embodiments, the migration state information generally resides in a page table entry and is used to "control" access to the page of memory and the information in its respective page table entry at other times (i.e., other migration states). For example, for a page of memory where the preparations described in FIG. 7 are complete and the page of memory is actually being migrated (i.e., in the process of being moved from one location in memory to another), the migration state information is used by the IOMMU to control access to the page of memory and the information in its respective page table entry. In some embodiments, the migration of the page of memory is performed in migration state 606 with the above-described control over access to the page of memory and the information in its respective page table entry. As another example, for a page of memory that has not been migrated and therefore not been prepared for migration, the migration state information is used by the IOMMU to control access to the page of memory and the information in its respective page table entry. In some embodiments, operations on non-migrating pages of memory are performed in the migrating state 600 with the above-described control (or lack thereof) over access of the pages of memory and the information within their respective page table entries.

[0098] In some embodiments, at least one electronic device (such as, for example, electronic device 100) uses code and / or data stored on a non-transitory computer-readable storage medium to perform some or all of the operations described herein. More specifically, at least one electronic device reads the code and / or data from the computer-readable storage medium and executes the code and / or uses the data when performing the described operations. The computer-readable storage medium may be any device, medium, or combination thereof that stores code and / or data used by the electronic device. For example, the computer-readable storage medium may include, but is not limited to, volatile and / or non-volatile memory, including flash memory, random access memory (e.g., eDRAM, RAM, SRAM, DRAM, DDR4 SDRAM, etc.), non-volatile RAM (e.g., phase-change memory, ferroelectric random access memory, spin-transfer random access memory, magnetoresistive random access memory, etc.), read-only memory (ROM), and / or magnetic or optical storage media (e.g., disk drives, magnetic tapes, CDs, DVDs, etc.).

[0099] In some embodiments, one or more hardware modules perform the operations described herein. For example, hardware modules may include, but are not limited to, one or more central processing units (CPUs) / CPU cores, graphics processing units (GPUs) / GPU cores, application-specific integrated circuit (ASIC) chips, field-programmable gate arrays (FPGAs), compressors or encoders, computational units, embedded processors, accelerated processing units (APUs), controllers, requesters, completers, network communication links, and / or other functional blocks. When circuitry (e.g., integrated circuit elements, discrete circuit elements, etc.) within such hardware modules is activated, the circuitry performs some or all of the operations. In some embodiments, a hardware module includes general-purpose circuitry, such as an execution pipeline, computational or processing unit, that performs operations upon execution of instructions (e.g., program code, firmware, etc.). In some embodiments, a hardware module includes application-specific or dedicated circuitry that performs operations, and in some cases, includes circuitry that performs some or all of the operations "in hardware" without executing instructions.

[0100] In some embodiments, data structures representing some or all of the functional blocks and circuit elements described herein (e.g., electronic device 100 or portions thereof) are stored in a non-transitory computer-readable storage medium, including a database or other data structure, that can be read by an electronic device and used directly or indirectly to fabricate hardware including the functional blocks and circuit elements. For example, the data structure can be a behavioral-level description of the hardware functionality in a high-level design language (HDL) such as Verilog or VHDL, or a register-transfer level (RTL) description. The description can be read by a synthesis tool that can synthesize the description to generate a netlist containing a list of transistors / circuit elements from a synthesis library that represents the functionality of the hardware including the functional blocks and circuit elements. The netlist can then be placed and routed to generate a data set describing the geometric shapes to be applied to a mask. The mask can then be used in various semiconductor processing steps to manufacture a semiconductor circuit or circuits (e.g., an integrated circuit) corresponding to the functional blocks and circuit elements. Alternatively, the database on the computer-accessible storage medium may be a netlist (with or without a synthesis library) or a data set, or Graphic Data System (GDS) II data, as desired.

[0101] In this description, variables or unspecified values ​​(i.e., general descriptions of values ​​without specific examples of values) are represented by letters such as N, M, and X. As used herein, despite the possible use of similar letters in different places in this description, the variables and unspecified values ​​in each instance are not necessarily the same; i.e., there may be variables and values ​​intended for some or all of the general variables and unspecified values. In other words, examples of specific values ​​of N, and any other letters used to represent variables and unspecified values ​​in this description, are not necessarily related to each other.

[0102] As used herein, the phrase "et al." or "e.g., etc." is intended to present one and / or instance, i.e., the equivalent of "at least one of" the elements in the list with which the "et al." is associated. For example, in a statement that "the electronic device performs a first operation, a second operation, etc.", the electronic device performs at least one of the first operation, the second operation, and the other operations. Additionally, the elements in the list associated with "e.g., etc." are merely examples from a set of examples, and at least some of the examples may not appear in some embodiments.

[0103] The foregoing descriptions of the embodiments have been presented only for purposes of illustration and description. They are not intended to be exhaustive or to limit the embodiments to the precise forms disclosed. Accordingly, many modifications and variations will be apparent to those skilled in the art. Moreover, the above disclosure is not intended to limit the embodiments. The scope of the embodiments is defined by the appended claims.

Claims

1. 1. An electronic device comprising: Memory and an input / output memory management unit (IOMMU); a processor that executes the software entities; a page transition engine; the software entities and the page migration engine are configured to perform operations to prepare a page of memory accessible by at least one IO device for migration within the memory, and the software entities and the page migration engine are configured to set migration state information in a page table entry for the page of memory based on the operations being performed, the migration state information indicating a migration state selected from at least three migration states; the IOMMU is configured to use the migration state information in the page table entry to control one or more operations of the IOMMU based on the migration state. Electronic devices.

2. and wherein the migration state information in the page table entry is used to control the one or more operations of the IOMMU. The IOMMU is using information from said page table entry; a memory access of the page of memory; Controlling at least one of The electronic device of claim 1 .

3. when setting migration state information in the page table entry for the page of memory, The software entity and the page transition engine configured by the software entity and the page transition engine to set the transition state information to a value; When the value is read by the IOMMU, not storing a copy of information from said page table entry in a cache within said IOMMU; not providing a copy of information from the page table entry to the at least one IO device to be stored in a cache within the at least one IO device; causing the IOMMU to control use of information from the page table entry by The electronic device of claim 2.

4. When performing said operations to prepare to migrate said page of memory, The software entity and the page transition engine invalidating, by the software entity, any existing copies of information from the page table entry in caches in the at least one IO device; invalidating, by the page migration engine, any existing copies of information from the page table entry in a cache in the IOMMU; configured to: The electronic device of claim 3.

5. if not providing a copy of information from the page table entry to the at least one IO device; The IOMMU is configured to not provide a copy of information from the page table entry to the at least one IO device in response to an address translation service (ATS) request from the at least one IO device. The electronic device of claim 3.

6. when setting migration state information in the page table entry for the page of memory, The page transition engine configured to set the migration state information to a first value that, when read by the IOMMU, causes the IOMMU to control performance of memory accesses to the page of memory by stalling newly encountered memory accesses of a first type to the page of memory but allowing existing memory accesses of the first type and a second type to the page of memory and newly encountered memory accesses of the second type to proceed; The electronic device of claim 2.

7. when setting migration state information in the page table entry for the page of memory, The page transition engine configured to set the migration state information to a second value that, when read by the IOMMU, causes the IOMMU to control performance of memory accesses to the page of memory by stalling newly encountered memory accesses of both the first type and the second type to the page of memory, but allowing existing memory accesses of the first type and the second type to complete. The electronic device of claim 6.

8. performing an operation to prepare to migrate a page of said memory; The page transition engine configured to ensure that any memory accesses of the first type and the second type to the page of memory that are not stalled are completed before migrating the page of memory. The electronic device of claim 7.

9. the page migration engine is configured to perform operations to migrate pages of the memory; The operation is moving a page of said memory from a first location to a second location within said memory; After the movement is completed, updating information in the page table entry to identify the page of memory as being stored at the second location within the memory; setting the migration state information to a value that, when read by the IOMMU, causes the IOMMU to resume performing memory accesses of the page of memory normally, using information from the page table entry normally; The electronic device of claim 2.

10. the memory includes two or more different types of memory, each type of memory having different memory characteristics; moving the page of memory from the first location in memory to the second location in memory includes moving the page of memory from a first one of the types of memory to a second one of the types of memory. The electronic device of claim 9.

11. the software entity is configured to set migration state information in other page table entries for other pages of memory that have not been migrated to a value that, when read by the IOMMU, causes the IOMMU to use information from the page table entries as normal and to perform memory accesses of the pages of memory as normal; The electronic device of claim 2.

12. the software entity is either an operating system or a hypervisor; The electronic device of claim 1 .

13. the at least one IO device coupled to or included in the electronic device; The electronic device of claim 1 .

14. 1. A method for migrating pages of memory in a memory in an electronic device, comprising: performing operations to prepare to migrate a page of memory accessible by at least one IO device in the memory, the operations including setting migration state information in a page table entry for the page of memory based on the operations being performed, the migration state information indicating a migration state selected from at least three migration states; and using the migration state information in the page table entry to control one or more operations of an IOMMU in the electronic device based on the migration state. method.

15. Controlling the one or more operations of the IOMMU using the migration state information in the page table entry includes: using information from said page table entry; a memory access of the page of memory; controlling at least one of 15. The method of claim 14.

16. Setting migration state information in the page table entry for the page of memory includes: setting the transition state information to a value; When the value is read by the IOMMU, not storing a copy of information from said page table entry in a cache within said IOMMU; not providing a copy of information from the page table entry to the at least one IO device to be stored in a cache within the at least one IO device; causing the IOMMU to control use of information from the page table entry by 16. The method of claim 15.

17. Preparing to migrate the page of memory includes: invalidating any existing copies of information from the page table entry in a cache in the at least one IO device; invalidating any existing copies of information from the page table entry in a cache in the IOMMU.

17. The method of claim 16.

18. Not providing a copy of information from the page table entry to the at least one IO device and not providing a copy of information from the page table entry to the at least one IO device in response to an address translation services (ATS) request from the at least one IO device.

17. The method of claim 16.

19. Setting migration state information in the page table entry for the page of memory includes: setting the migration state information to a first value that, when read by the IOMMU, causes the IOMMU to control performance of memory accesses to the page of memory by stalling newly encountered memory accesses of a first type to the page of memory but allowing existing memory accesses of the first type and a second type to the page of memory and newly encountered memory accesses of the second type to proceed; 16. The method of claim 15.

20. Setting migration state information in the page table entry for the page of memory includes: setting the migration state information to a second value that, when read by the IOMMU, causes the IOMMU to control performance of memory accesses to the page of memory by stalling newly encountered memory accesses of both the first type and the second type to the page of memory, but allowing existing memory accesses of the first type and the second type to complete.

20. The method of claim 19.

21. Preparing to migrate the page of memory includes: ensuring that any memory accesses of the first type and the second type to the page of memory that are not stalled are completed before migrating the page of memory.

21. The method of claim 20.

22. performing an operation to migrate a page of the memory; The operation is moving a page of said memory from a first location to a second location within said memory; After the movement is completed, updating information in the page table entry to identify the page of memory as being stored at the second location within the memory; setting the migration state information to a value that, when read by the IOMMU, causes the IOMMU to resume performing memory accesses of the page of memory normally, using information from the page table entry normally; 16. The method of claim 15.

23. the memory includes two or more different types of memory, each type of memory having different memory characteristics; moving the page of memory from the first location in memory to the second location in memory includes moving the page of memory from a first one of the types of memory to a second one of the types of memory.

23. The method of claim 22.

24. setting migration state information in other page table entries for pages of other memory that have not been migrated to a value that, when read by said IOMMU, causes said IOMMU to use information from said page table entries as normal and to perform memory accesses of said pages of memory as normal; 16. The method of claim 15.

Images