System and method for disabling physical address-based translation lookaside buffers

Abstract

This invention provides a method and system for disabling a subset of entries in a Translation Lookaside Buffer (TLB). [Solution] The method receives a request from a guest application for the allocation of protected memory, allocates a physical address space to the guest operating system that is started to run the guest application, removes the mapping from the second stage mapping associated with the host operating system running on the computing system to the physical address space, identifies a subset of entries in the TLB based on the physical address and from the TLB associated with the host operating system, the TLB stores the mapping between the virtual address space and the physical address space, and further invalidates the subset of entries in the TLB.

Description

Technical Field

[0001] Cross - Reference to Related Applications This application claims priority based on U.S. Provisional Application No. 63 / 706,296, filed on October 11, 2024, the entire disclosure of which is incorporated herein by reference.

[0002] This specification relates to computing systems, and more particularly, to systems and methods for memory management in computing systems using physical - address - based translation lookaside buffer invalidation.

Background Art

[0003] Many computing systems provide a secure environment for hosting applications. For example, a protected kernel-based virtual machine (pKVM) can allocate memory to a guest application by booting a guest operating system on which the guest application can run. The memory is allocated to the guest operating system, then to the guest application, and is protected from the host operating system. Some computer architectures, such as the ARM64 architecture, define a Memory Management Unit (MMU) that receives memory allocation requests from guest applications, allocates a virtual address space to the guest application, and maps the virtual address space to the physical address space of physical memory. The MMU maintains address translation between the virtual address space allocated to the guest application and the corresponding physical address space. In some cases, MMU operation may be divided into two independent stages, both of which may be used to implement address translation and access control to different parts of memory. The first-stage MMU operation translates the guest application's virtual address space to the intermediate physical address (IPA) space, and the second-stage MMU translates the IPA space to the physical address space. The MMU may store these mappings in memory. The virtual address space is the range of addresses allocated to the guest application. The IPA is an intermediate memory space that can be analogous to the physical address space, and in some cases, can be the same size as the physical address space. The IPA allows the MMU to implement secure memory allocation by enabling an additional mapping stage between virtual memory and physical memory. The MMU can control the mapping from the IPA to the PA to restrict which entities can access the guest application's physical address space. [Overview of the project]

[0004] Computing system architectures that often employ features such as protected kernel-based virtual machines (pKVM) utilize a hypervisor to manage a two-stage memory mapping process for isolation and virtualization. The MMU uses Stage 1 mapping to translate virtual addresses (VAs) to intermediate physical addresses (IPAs), and then uses Stage 2 mapping to translate IPAs to host physical addresses (PAs). To reduce address translation latency, the MMU caches the resulting VA-to-PA mappings in a Translation Lookaside Buffer (TLB), mitigating the need to perform two-stage lookups in subsequent memory accesses.

[0005] When a new application requests protected memory, the hypervisor creates a virtual machine and, to secure that memory, disables the IPA-to-PA mapping in the Stage 2 table that previously allowed the host operating system access to that physical memory. This change to the Stage 2 table requires the hypervisor to update the TLB. However, because the TLB entries cache the complex VA-to-PA conversion but do not store intermediate IPA information, the hypervisor cannot precisely determine which TLB entries are affected by the Stage 2 change. As a result, the hypervisor is forced to perform a complete TLB invalidation or flush.

[0006] Even a Stage 2 change that targets only a limited number of elements necessitates a complete TLB flush, which presents significant performance problems. This action invalidates TLB entries unaffected by the change, resulting in a side effect of increased latency for other applications running on the host system. Furthermore, the problem is complicated by the demand paging mechanism. For example, if protected memory access is permitted per page (e.g., 4KB at a time), frequent updates to Stage 2 mappings (up to 256 events per 1MB area) will force a complete TLB invalidation, which in turn costs an equivalent number of times.

[0007] The techniques discussed herein mitigate the impact of changes to Stage 2 mappings by invalidating only the entries in the TLB that are affected by the changes to the Stage 2 mappings. In particular, the techniques discussed herein provide a mechanism for invalidating TLB entries based on PAs. When a hypervisor updates a Stage 2 mapping, it may store the old PA values ​​involved in the conversion change. The hypervisor may then use the old PAs to identify entries in the TLB that have the old PAs in the VA-to-PA mapping. Unlike the conventional approach where the entire TLB is invalidated, the hypervisor invalidates only the entries that have PAs that match the old PAs. This PA-based, targeted entry invalidation preserves entries in the TLB that are not affected by the Stage 2 mapping update. As a result, the performance of other applications that depend on the preserved entries remains unaffected.

[0008] Certain examples of the subject matter described herein can be implemented to achieve one or more of the following advantages: By disabling TLB entries based on physical addresses, the need to disable the entire TLB can be reduced. In some cases, a guest application may be started and terminated several times during device operation. For example, a guest application may be an imaging application that requests secure memory allocation isolated from the host operating system. Such an application may be started several times by the user. In other cases, the MMU may implement demand paging, which may result in multiple page faults and corresponding TLB invalidations. Therefore, disabling the TLB each time a guest application is started and terminated, or each time a page fault occurs, can have a serious impact on the MMU's performance. By disabling only the entries in the TLB affected by the guest application, other TLB entries independent of memory allocations to the guest application can be preserved. Therefore, the performance benefits provided by those TLB entries can be preserved.

[0009] In one aspect, the disclosure relates to a method for managing memory within a computing system. The method includes receiving a request from a guest application for the allocation of protected memory; in response to the request, allocating a physical address space to a guest operating system that is started to run the guest application; removing a mapping from a second stage mapping associated with a host operating system running on the computing system to the physical address space; and identifying a subset of entries in a Translation Lookaside Buffer (TLB) associated with a memory management unit of the computing system, based on the physical address space, where each entry in the TLB stores a mapping between a virtual address and a physical address; and the method further includes invalidating the subset of entries in the TLB.

[0010] Embodiments may include one or more of the following features: The method may include identifying a subset of entries in a TLB, which includes identifying an entry in a TLB that has a physical address that matches the physical address space allocated to a guest operating system. The method may include invalidating a subset of entries in a TLB, which includes setting or resetting a validity flag associated with the subset of entries. The method may include receiving a request from a host application to access data by a virtual address, determining that the virtual address does not exist in a TLB, generating a first mapping that maps the virtual address to an intermediate physical address, generating a second mapping that maps the intermediate physical address to a physical address, and storing in a TLB the virtual address from the first mapping and the physical address from the second mapping as entries that map the virtual address to a physical address. The request from the host application is the first request, and the method may include receiving a second request from a host application to access data by a virtual address, determining the corresponding physical address from entries in a TLB that map the virtual address to a physical address, and providing the host application with the data from the physical address. A TLB is stored in associative memory, and the method may include providing a physical address in the physical address space to the associative memory and receiving identification information for a subset of entries in the TLB from the associative memory. A TLB is stored in associative memory, and the method may include providing a physical address in the physical address space to the associative memory and receiving a virtual address from the associative memory corresponding to an entry in the TLB containing a physical address in the physical address space. The method may include sending an instruction from the hypervisor to the memory management unit of the computing system to remove the mapping from a second stage mapping to the physical address space. The hypervisor is a protected kernel-based virtual machine.A guest operating system is a way of running within a guest virtual machine managed by a hypervisor.

[0011] A common embodiment is a system comprising a translation lookaside buffer (TLB) containing a mapping from a virtual address space to a physical address space for a host operating system, and a memory management unit (MMU) configured to perform operations, the operations comprising (1) a first set of operations for translating virtual addresses to intermediate physical addresses, and (2) a second set of operations for translating intermediate physical addresses to physical addresses, the system further comprising at least one processor and at least one memory for storing instructions for performing operations when executed by at least one processor, the operations comprising receiving a request from a guest application for the allocation of protected memory and responding to the request The answer includes a system comprising: allocating a physical address space to a guest operating system that is started to run a guest application; removing the mapping from a second-stage mapping associated with a host operating system running on the computing system to the physical address space; and identifying a subset of entries in a Translation Lookaside Buffer (TLB) associated with the memory management unit of the computing system, based on the physical address space, where each entry in the TLB stores a mapping between a virtual address and a physical address; and further, the operation includes invalidating a subset of entries in the TLB.

[0012] Embodiments may include one or more of the following features: Identifying a subset of entries in a TLB is a system that includes identifying entries in a TLB that have a physical address space matching the physical address space allocated to a guest operating system. Disabling a subset of entries in a TLB is a system that includes setting or resetting a validity flag associated with a subset of entries. An operation may include receiving a request from an application to access data at a virtual address, determining that the virtual address does not exist in the TLB, generating a first mapping that maps the virtual address to an intermediate physical address, generating a second mapping that maps the intermediate physical address to a physical address, and storing the virtual address from the first mapping and the physical address from the second mapping in the TLB as entries that map the virtual address to a physical address. The request from the application is the first request, and the operation may include receiving a second request from an application to access data at a virtual address, determining the corresponding physical address from entries in the TLB that map the virtual address to a physical address, and providing the data from the physical address to the guest application. A system that includes associative memory for storing a TLB, where the associative memory is configured to receive a physical address in the physical address space, search for an entry in the TLB that has a physical address matching the physical address in the physical address space, and provide identification information for a subset of entries in the TLB. The system may include associative memory for storing a TLB, where the associative memory is configured to receive a physical address in the physical address space, search for an entry in the TLB that has a physical address matching the physical address in the physical address space, and provide virtual addresses for a subset of entries in the TLB. The operation may include sending an instruction from the hypervisor to the memory management unit of the computing system to remove the mapping from the second stage mapping to the physical address space. The system is a protected kernel-based virtual machine.A guest operating system is a system that runs within a guest virtual machine managed by a hypervisor.

[0013] Similar reference numbers and names in various drawings refer to the same elements. [Brief explanation of the drawing]

[0014] [Figure 1A] This shows an exemplary electronic device, including a system-on-a-chip ("SoC") and memory devices. [Figure 1B] A block diagram of an exemplary computing system is shown. [Figure 2A] This shows a part of the memory management system of a computing system. [Figure 2B] Figure 2A shows a memory management system with new applications requesting protected memory. [Figure 3] An example of a Translation Lookaside Buffer (TLB) is shown. [Figure 4] This diagram shows a schematic representation of a portion of the translation lookaside buffer implemented on associative memory. [Figure 5] A flowchart illustrating an exemplary process is shown. [Modes for carrying out the invention]

[0015] A computing system may include a host system that runs a host operating system. The host system may include a hypervisor, which is a layer of software, firmware, and / or hardware that enables the creation and management of virtual machines. The hypervisor abstracts underlying physical computing resources such as the central processing unit (CPU), memory, storage, and networking, and can pool them to allow multiple guest operating systems to run simultaneously on the host system. The hypervisor can control the MMU and two-stage mapping, which includes mapping from VA to IPA and from IPA to PA.

[0016] The MMU may maintain a TLB to cache mappings from virtual addresses (VAs) to virtual addresses (PAs). For example, when an application running on the host or guest operating system requests memory access, the MMU translates the VA provided by the application into the corresponding IPA based on the Stage 1 mapping table. The MMU can then determine the PA corresponding to the IPA based on the Stage 2 mapping table. Once the VA-to-PA mapping is determined, the MMU can store the mapping in the TLB. Therefore, if the application later requests memory access at the same virtual address, the MMU can determine the corresponding PA by searching for the virtual address in the TLB. Having the VA-to-PA mapping in the TLB reduces the need for the MMU to perform a two-stage mapping to determine the PA. Thus, the TLB can function as a cache for address mappings, reducing the latency of address translation.

[0017] Some architectures, such as Protected Kernel-Based Virtual Machines (pKVM), provide protected memory to the guest operating system. Applications launched on the host system may request protected memory. In response, the hypervisor creates a virtual machine with a guest operating system on which the application can run. To protect the guest operating system's memory, the hypervisor removes the host operating system's access to the physical memory allocated to the guest operating system. To remove host operating system access, the hypervisor removes or disables the IPA-to-PA mapping for the host operating system. Without the IPA-to-PA mapping, the host operating system cannot access the physical memory allocated to the guest operating system.

[0018] A TLB may contain VA-to-PA mappings associated with the host operating system. PAs within these mappings may refer to the physical address space that was accessible to the host operating system before the hypervisor removed the host's IPA-to-PA mappings. Consequently, if an IPA-to-physical address mapping in the Stage 2 mapping table is removed or updated, the corresponding VA-to-PA mapping in the TLB may need to be invalidated. This requirement arises because the TLB does not store IPA information, preventing the hypervisor from accurately determining which cached VA-to-PA entries in the TLB are affected by the IPA-to-PA mapping change. As a direct consequence, the hypervisor is forced to perform a complete TLB invalidation or flush. This action invalidates entries in the TLB that were not actually affected by the changes in the Stage 2 mapping table. This incidental invalidation may increase the latency of responses to memory access requests associated with virtual addresses appearing in the unnecessarily flushed TLB entries.

[0019] A hypervisor may have to disable the TLB during the startup of all applications that request protected memory. This action can disrupt other applications running on the host system where the associated TLB entry is disabled each time an application requests protected memory. As a result, the overall performance of the host system may degrade.

[0020] The hypervisor may have to perform TLB invalidation due to demand paging. The process of granting the guest operating system exclusive access to physical memory is not usually performed all at once. For example, if the guest operating system requests 1MB of protected physical memory space but only accesses a few memory pages, only the accessed memory pages will be marked as protected on demand. In response to a write operation to a new memory page, the new memory page is marked as protected by removing the host operating system's access to the new memory page. Removing access involves removing or invalidating the address mapping from IPA to PA in the Stage 2 mapping table. As mentioned above, this action results in the hypervisor invalidating or flushing the entire TLB. TLB invalidation in this case can occur frequently. For example, in the case of a request for 1MB of protected physical memory, only 4KB pages will initially be marked as protected. This demand paging operation can result in up to 256 Stage 2 mapping table update events. Graphics applications can have high memory requirements (e.g., 100MB), in which case demand paging can result in a much larger number of table update events (e.g., 25,000 with a 4KB page size). Each of these update events requires costly TLB invalidation, leading to performance issues.

[0021] Examples of systems and methods that can support invalidation of the PA base of TLB entries are discussed herein in connection with FIGS. 1A-5.

[0022] FIG. 1A shows an exemplary electronic device 100 that includes a system on chip 140 (“SoC140”) and a memory device 170. SoC140 includes a central processing unit 104 (“CPU104”), a memory controller 105, a memory 106, a resource manager 108, and an IP / circuit block 110. In other examples, SoC140 can include fewer or more components. For example, SoC140 may not include a CPU or an IP / circuit block. In some embodiments, the electronic device 100 can include multiple SoC140s, and the description of SoC140 can be equally applicable to each of the multiple SoCs and / or processors that can be included in the electronic device 100.

[0023] The CPU 104 can be a general-purpose CPU (e.g., a single-core or multi-core CPU). The CPU 104 generates one or more indicators, such as an app startup indicator or a function call triggered in response to the execution or startup of an application on a user device. For example, the application can be a camera application that uses an imaging sensor to generate image data, or a gaming application that requires significant memory and graphics processing resources to render the graphical content of a game. The CPU 104 also generates one or more application values, such as pixel values or frame rates. The application values may be associated with a function call, may describe an event occurring during the execution of the application, or both. The memory 106 is system memory, shared memory, or both. In the example of FIG. 1A, the memory 106 is depicted outside the circuit block 110. However, the memory 106 may include portions of memory that are i) specific to the circuit block 110, ii) outside the circuit block 110, or iii) both. The memory 106 can be a random-access memory of the SoC 140, such as static random-access memory (SRAM), dynamic random-access memory (DRAM), synchronous DRAM (SDRAM), or double data rate (DDR) SDRAM.

[0024] In some embodiments, the memory 106 is configured as a shared scratchpad memory that supports parallel access to its memory resources by two or more processors of the circuit block 110. The memory 106 may also include various other types of memory, such as high-bandwidth memory (HBM), narrow-bandwidth memory (e.g., for storing 8-bit values), wide memory (e.g., for storing 16-bit or 32-bit values), etc.

[0025] The resource manager 108 is implemented in hardware and software. Embodiments of the resource manager 108 may also be implemented as firmware for an ML processor, memory controller 105, or CPU 104, or as firmware for a device in the SoC 140. The resource manager 108 includes control logic that is implemented in hardware, software, or both. For example, the resource manager 108 may include resources such as flip-flops, registers, and buffers implemented in hardware, and control logic (e.g., programmed code) implemented in software. In some embodiments, the resource manager 108 is a decoding / encoding resource manager that generates control signals for performing decompression and compression operations of the system 100.

[0026] Circuit block 110 generally includes individual IP devices such as processors, processor cores, or special-purpose processing devices. For example, circuit block 110 may include an image signal processor (ISP) 112, a host processing unit (HPU) 114, a digital signal processor (DSP) 116, and a graphics processing unit (GPU) 118. Circuit block 110 is alternatively referred to as IP block 110, and an IP block may include one or more proprietary hardware elements. For example, each of the ISP 112, HPU 114, DSP 116, and GPU 118 may be proprietary IP blocks (or IP devices) of a particular entity or device manufacturer.

[0027] The HPU114 can be a special-purpose processor such as an ML hardware accelerator, a neural processor unit, a neural network (or ML) processor, or other application-specific processor. In some embodiments, the HPU114 is a neural network tensor processor (e.g., a tensor processing unit (TPU)) having an integrated circuit architecture optimized for power-efficient execution of ML computations using tensor constructs such as multidimensional matrices / tensors.

[0028] The circuit block 110 may also include an image conversion engine 120 and an image processing engine 126. The image conversion engine 120 performs the conversion of an input image to an output image, which is discussed in more detail in this application. The image conversion engine 120 may generate multiple output images based on multiple conversions of a common set of input images. Examples of such operations may include image frame interpolation, two-dimensional (2-D) to three-dimensional (3-D) conversion, depth-based blur effects, and the like. The image processing engine 126 may perform additional image processing tasks not performed by the image conversion engine 120. Additional image processing tasks may include, for example, color adjustment, image upscaling / downscaling, filtering, and the like.

[0029] In some examples, the image conversion engine 120 may be part of the image processing engine 126. That is, the image processing engine 126 may perform the functions of the image conversion engine 120 discussed herein and may include components. In some examples, the output image generated by the image conversion engine 120 may be provided to the image processing engine 126 for further processing. In some examples, like the image processing engine 126, the image conversion engine 120 may also communicate with one or more processors, the ISP 112, HPU 114, DSP 116, GPU 118, and other components of the SoC 140.

[0030] One or more embodiments of the resource manager 108 may be implemented as a software routine (or module) of the CPU 104, which uses one or more hardware resources of the CPU 104, such as registers and buffers. The CPU 104 may be configured as an instruction and vector data processing engine that processes data obtained from the memory device 170 and / or from the system memory of the SoC 102, such as memory 106. In some embodiments, each processor of the SoC 140, for example, ISP 112, DSP 116, HPU 114, and GPU 118, includes multiple cores.

[0031] The CPU 104 and / or resource manager 108 may generate control signals to control and / or manage the operation of one or more other components of the electronic device 100, such as the image processing engine 126 and the image conversion engine 120. The control signals are routed through the electronic device 100 using an exemplary bus 122 of the SoC 140 ("SoC bus 122"). The control signals may include commands, requests, data, instructions, or a combination thereof.

[0032] In some embodiments, the resource manager 108 collaborates with the CPU 104 and the memory controller 105 to dynamically control and manage one or more process-in-memory (PiM) operations, compute-in-memory (CiM) operations, or both. The operations involve accessing and processing data stored locally in the memory device 170. PiM and CiM operations are executed locally in the memory device 170 based on control signaling generated in the SoC 140. Control signals are received in the memory device 170 and processed locally using the PiM / CiM compute elements of the memory device 170 to trigger or initiate PiM / CiM operations. The operations may be executed supporting heterogeneous computations involving two or more processing units of the IP block 110, the CPU 104, or both. In some examples, the memory device 170 may include exemplary image processing engines (e.g., image processing engine 126 and / or image transformation engine 120, etc.) for executing PiM / CiM operations in the memory device 170. In other words, the image processing engine may be used to process images or other media stored in the memory device 170, or received in the memory device 170 via the memory controller 105, disk memory 160, or a combination thereof. In some cases, the data may be encrypted or otherwise packaged for transmission.

[0033] The SoC 140 collaborates with the memory device 170 to perform computations using data (e.g., encoded data) retrieved from the memory bank of the memory device 170. The computations may be for operations or workloads involving one or more processors in the IP block 110. Furthermore, the computations may be for heterogeneous operations across multiple processors in the IP block 110, multiple IP blocks 110, or both. In some embodiments, the heterogeneous operations include a host device such as an HPU 114 collaborating to perform an exemplary ML workload, and the memory device 170. In at least one example, the memory device 170 may be external to the SoC 140, while in other examples, the memory device 170 may be internal to the SoC 140.

[0034] In the example in Figure 1A, SoC140 is an integrated circuit for an exemplary user / client device 130, a consumer electronic device, or a mobile device, each of which may include items such as a smartphone 130a, a tablet 130b, a laptop 130c, a smartwatch, or a wearable device 130d. Device 130 may also include other items such as an e-notebook, a netbook, a smart speaker, or a mobile computer. In some embodiments, SoC140 and memory device 170 are integrated circuits for a desktop computer, a network server, or an associated cloud-based asset.

[0035] The image processing engine 126 and the image conversion engine 120 are shown as being located in the same location as the processing resources of the IP block 110. However, in other examples, the image processing engine 126 and the image conversion engine 120 may be located elsewhere on the SoC 140. The image processing engine 126 and the image conversion engine 120 may be implemented as an integrated circuit or a set of separate hardware modules connected to the SoC processor 140 and the memory device 170. For example, the image processing engine 126 and / or the image conversion engine 120 may be coupled to the memory device 170 via one or more memory channels, communication buses, or circuit interconnections in the electronic device 100 or client device 130.

[0036] As will be discussed in more detail below, the memory controller 105 can control the memory operation of applications and operating systems running on the SoC 140.

[0037] Figure 1B shows a block diagram of an exemplary computing system. In some embodiments, the computing system shown in Figure 1B may be a representation of the electronic device 100 shown in Figure 1A relating to memory management. The computing system includes a central processing unit (CPU) 180, a memory management unit (MMU) 182, physical memory 184, system memory management units (SMMUs) (SMMU1 186 and SMMU2 188), a graphics processing unit (GPU) 190, a digital signal processing unit (DPU) 192, and an image signal processor (ISP) 194, and may include additional processing units and memory units. The processing units have an MMU or SMMU that interfaces between the processing unit and the physical memory 184. In some examples, the MMU 192 and SMMU may implement the memory controller 105 of the SoC 140 discussed in relation to Figure 1A.

[0038] The MMU182 (and SMMU) manages memory access by virtualizing the memory space provided to applications running on the processing unit, and can isolate memory allocated to one application from other applications. For example, a hypervisor (not shown) may manage the MMU182 to maintain address translation. Specifically, the MMU182 may maintain translation tables from virtual addresses (VA) to intermediate physical addresses (IPA) and from IPA to physical addresses (PA). As described above, the hypervisor may protect the address space allocated to an application by deleting or invalidating IPA to PA entries that were previously associated with the host operating system (or any other guest operating system or application).

[0039] In some examples, a hypervisor may include a protected kernel-based virtual machine (pKVM) hypervisor. Such a hypervisor restricts the host system's ability to access protected physical memory allocated to virtual machines on which other applications run. Protected virtual machines may request the hypervisor to provide protection for the memory allocated to them from the host system itself. The hypervisor may manage the MMU (MMU182 and / or SMMU) so that the host system has unrestricted access to its own memory space but not access to the memory space of the protected virtual machines. In one approach, the hypervisor may maintain a two-stage MMU, where the first stage handles the VA to IPA conversion and the second stage manages the IPA to PA conversion.

[0040] When a new application is launched on the host system, the new application may request secure memory space from the host system. In response, the hypervisor may create a protected virtual machine for the new application. Once the protected virtual machine is created, the hypervisor gains exclusive access to the physical memory pages that the host system has allocated for the protected virtual machine. Furthermore, the hypervisor updates the IPA-to-PA table for the host so that the physical memory pages are not visible to the host system. In addition, the hypervisor may revoke the host system's read / write privileges to these physical memory pages. In some examples, the hypervisor may also configure an I / O Memory Management Unit (IOMMU) to block direct memory access (DMA) to the protected virtual machine's memory from host system-controlled peripherals.

[0041] As described above, in some examples, the techniques discussed herein restrict TLB invalidation to only the entries affected by the Stage 2 mapping update. Figures 2A and 2B show examples of hypervisor and TLB behavior without PA-based invalidation and with PA-based invalidation.

[0042] Figure 2A shows a portion of the memory management system of computing system 200. Computing system 200 may be implemented based on the SoC 140 described above in relation to Figure 1A. Figure 2A shows a hypervisor 202 that supports a host operating system 204 and a first guest operating system 206. These operating systems run on their respective virtual machines, which are not shown in the figure for simplicity. Stage 2 mapping tables are also shown. For example, the host system's stage 2 mapping table 208 ("Host OS Stage 2 Table 208") and the guest OS's stage 2 mapping table 210 ("Guest OS 1 Stage 2 Table 210") may each include IPA to PA conversions. Figure 2A also shows a TLB 212 that caches VA to PA mappings and can be used for fast lookups by the MMU during memory operations. In the example shown in Figure 2A, each IPA to PA entry in the host OS Stage 2 Table 208 has a corresponding VA to PA mapping entry in the TLB 212. Similarly, each entry from IPA to PA in guest OS1 stage2 table210 has a corresponding mapping entry from VA to PA in TLB212. Note that the mapping shown in the figure is merely an example.

[0043] Figure 2B shows the memory management system shown in Figure 2A, but with a request from a new application for protected memory. The new application is launched on a second guest operating system 214. The memory allocated to the second guest operating system 214 results in the deletion or invalidation of three IPA-to-PA mappings (the bottom three) in the host OS stage 2 table 208. While the example shown in Figure 2B focuses on the invalidation of IPA-to-PA mappings due to the launch of a new guest OS, other events such as demand paging (described above) can also result in the invalidation of IPA-to-PA mappings. In the conventional approach, the deletion or invalidation of entries in the stage 2 table would have resulted in the hypervisor 202 invalidating all entries in the TLB 212. This invalidation includes the VA-to-PA mapping entry corresponding to the guest OS-1 stage 2 table 210. In contrast, in the techniques discussed herein, the hypervisor 202 does not invalidate or flush the entire TLB 212. Instead, hypervisor 202 searches TLB212 for the three PAs that were removed from the host OS's Stage 2 table. Then, hypervisor 202 invalidates only the entries corresponding to the three PAs. Thus, hypervisor 202 retains the VA-to-PA entries in TLB212 that were unaffected by the removal of the IPA-to-PA entries in the host OS's Stage 2 table 208. As a result, the performance of the first guest operating system 206 is unaffected.

[0044] As described above, the hypervisor 202 searches for a specific PA value stored in the TLB 212 in order to invalidate the entry. In some embodiments, the TLB may include attribute values ​​in addition to VA and PA. One example of such a TLB is discussed in relation to Figure 3.

[0045] Figure 3 shows an exemplary Translation Lookaside Buffer (TLB). The TLB contains n entries, each entry may contain a virtual address (VA), a corresponding physical address (PA), a virtual machine identifier (VMID), an address space identifier (ASID), and one or more attributes (ATTRx / y / z). Each entry may also contain a validity flag (VLD) that can indicate whether the entry is valid or invalid. Each entry in the TLB stores the translation from VA to PA, as well as the associated values ​​for the VMID, ASID, and attributes. While conventional computing architectures provide the ability to invalidate one or more entries in the TLB based on VA or VMID, the techniques discussed herein enable the invalidation of one or more entries in the TLB based on PA (by setting or resetting the value of the corresponding validity flag VLD). That is, a hypervisor may provide instructions to invalidate one or more entries in the TLB based on PA. For example, a hypervisor may provide an instruction "TLBI VAE1,x0" that can invalidate an entry in the TLB having PA "x0". The instruction can be executed by the host system. In some cases, the SMMU may process a set of commands in a queue maintained by software. An exemplary command for disabling a TLB based on a PA might include "CMDQ_TLBI_x0_PA", where x0 may represent the physical address value of one or more entries in the TLB. These examples can enable the disabling of entries in a TLB based on a PA. Consequently, if the MMU or SMMU changes the IPA-to-PA mapping for the host operating system, the software may utilize these instructions to initiate the disabling of only the entries in the TLB affected by the change in the IPA-to-PA mapping.

[0046] As described above, pKVM (also called the “hypervisor”) can provide guest applications with the ability to request protected memory from the host operating system. This process, in conventional approaches, can result in the invalidation of all TLB entries. The techniques discussed herein utilize PA-based TLB invalidation commands to invalidate entries in the TLB. Specifically, consider a scenario in which a guest application requests protected memory of the XMB from pKVM for its virtual memory (VM1). The host operating system (e.g., Linux® OS) can allocate the XMB from its free memory to the guest operating system on which the guest application may run. The host kernel associated with the host operating system can update the first stage mapping of the MMU (and / or SMMU), which maps virtual addresses (VA1) to the intermediate physical address space (IPA1).

[0047] Because the guest application requested protected memory, pKVM may modify the second stage mapping of the MMU associated with the host operating system so that IPA1 does not point to the physical address PA1 that should be assigned to the guest operating system. For example, pKVM may update the second stage mapping so that IPA1 maps to an invalid physical address (e.g., x0). This may be followed by TLB invalidation of the entry containing PA1. pKVM may also update all second stage mappings of the SMMU associated with the host operating system so that IPA1 maps to a physical address not assigned to the guest operating system. For example, pKVM may update the mapping so that IPA1 maps to an invalid physical address (e.g., x0). In this case as well, pKVM may follow up by TLB invalidating all entries in the TLB of the SMMU containing the PA1 physical address. Note that, unlike the conventional approach in which pKVM would invalidate all entries in the TLB, the approach described herein invalidates only the entries affected by the physical address assigned to the guest operating system.

[0048] Next, pKVM may update the second stage mapping table of the MMU for the guest operating system so that IPA1 is mapped to the assigned physical address PA1. Similarly, the second stage mapping table of the SMMU for the guest operating system is updated so that IPA1 is mapped to the assigned physical address PA1.

[0049] The process described above modifies the second-stage mapping table associated with the host operating system to remove any mappings from IPA to physical addresses assigned to the guest operating system, thereby protecting the memory assigned to the guest operating system from access by the host operating system. In doing so, pKVM disables only the entries in the TLB that are affected by the physical addresses assigned to the guest operating system. pKVM does not disable all entries in the TLB. As a result, the adverse performance impact that would occur if all TLB entries were disabled is reduced.

[0050] In some examples, the TLB can be implemented in hardware on the host system. In some such examples, the TLB can be implemented using associative memory (CAM). Figure 4 discusses an exemplary embodiment of the TLB on CAM.

[0051] Figure 4 shows a schematic diagram of a portion of the translation lookaside buffer implemented on the associative memory 400. The CAM architecture includes an array of memory cells, each memory cell having its own comparison logic. Unlike standard RAM, which uses addresses to retrieve data, the CAM receives a data word and performs a parallel comparison on all stored data. If a match is found, the CAM signals where the data resides. The CAM 400 may include multiple memory cells 402. Each row of the memory cell 402 may store data that can be retrieved. For example, each row of the memory cell 401 may store the physical address in the entry from VA to PA of the TLB. The number of rows of memory cells 402 shown in Figure 4 is just an example. In some embodiments, the CAM 400 may include tens, hundreds, or thousands of rows of memory cells 402. The CAM 400 also includes match lines 404 that indicate data matches with the memory cells 402 in their corresponding rows. Each match line 404 is associated with one row of the memory cell 402. When data stored in a row of memory cells matches the search data, a match line 404 for that row is activated. The match line 404 is provided to an encoder 408, which can generate a virtual address based on which match line 404 was activated. In some examples, the encoder may provide a virtual address associated with each row of memory cells 402 that matches the searched physical address. The virtual addresses may be provided to the hypervisor, which may invalidate all entries that have those virtual addresses.

[0052] In some cases, the encoder may provide an index or number associated with the row of memory cell 402 that matches the searched physical address. For example, if the four rows in CAM400 are numbered from 0 to 3, starting from the bottom row, and the match line 404 associated with row numbers 1 and 2 is active, the encoder may provide the numbers 1 and 2 to the hypervisor. The hypervisor may then invalidate the entries in row numbers 1 and 2.

[0053] It should be noted that the CAM400 shown in Figure 4 is merely an example. Actual embodiments of CAM for TLB may include additional functionality, such as searching for multiple data types. For example, CAM may be configured so that two or more search words within the TLB (e.g., VA, VMID, PA, etc.) can be searched simultaneously to determine a match. The CAM matching hardware may be duplicated for each additional search word.

[0054] Figure 4 shows an exemplary hardware embodiment of a TLB, but a hypervisor, which is typically implemented in software, may issue instructions to one or more processors in the underlying host system to perform TLB-related operations. For example, one or more processors may have an instruction set that includes instructions for TLB operations. For example, the ARM architecture has an instruction set that provides several TLB-related operations, such as TLBI for invalidating one or more entries in the TLB. The instruction-level architecture may include instructions that, when executed, cause the invalidation of entries in the TLB that match a PA. As an example, when one or more processors execute such instructions, they may communicate with a CAM (e.g., CAM400 shown in Figure 4), provide a PA in a lookup register, and receive information from the CAM about a row or TLB entry that matches the PA. Upon receiving identification information of a row that needs to be invalidated, the processors may invalidate the row in several ways. In one approach, the processors may control the read / write drivers of the CAM to store values ​​that the system has assigned to the invalid row entry in the row. In another approach, the CAM400 may include additional memory cells that may represent flags associated with each row. The processor may control the CAM to flag the corresponding row or entry with a value indicating that it is invalid.

[0055] The actions taken by the hypervisor to disable the TLB based on the PA are discussed below in relation to Figure 5.

[0056] Figure 5 shows a flowchart of an exemplary process 500. In particular, process 500 may relate to the PA-based TLB invalidation discussed herein. Process 500 may be executed by a hypervisor running on a host system. Referring to Figure 1A, the hypervisor may run on the CPU 104 and control the MMU included in the memory controller 105. The TLB may be stored in the memory device 170 or in a memory device within the SoC 140.

[0057] Process 500 includes receiving a request from the guest application for the allocation of protected memory (502). At least one example of this process step is discussed herein. For example, referring to Figure 2B, the guest application may request the hypervisor 202 to allocate secure memory for the application. The secure memory requested by the application may be safe from the host operating system 204 and from other guest operating systems running on the host system.

[0058] Process 500 includes (504) allocating a physical address space to a guest operating system that is launched to run the guest application in response to a request. Referring again to Figures 2A and 2B, the hypervisor 202 may launch a guest operating system (e.g., guest OS-1 206 and guest OS-2 214) in response to a request from the application for secure memory. In some cases, the hypervisor may create a new protected virtual machine and run the guest operating system on the new protected virtual machine. The application can then run on the guest operating system.

[0059] Process 500 includes removing the mapping from the second stage mapping associated with the host operating system running on the computing system to the physical address space (506). Referring again to Figures 2A and 2B, the hypervisor 202 may, in response to receiving a request from the application for secure memory, isolate the physical memory allocated to the application from the host operating system. For example, the hypervisor 202 may remove any entry in the stage 2 mapping table 208 that includes the physical address allocated to the new guest operating system, which is associated with the host operating system 204.

[0060] Process 500 includes identifying a subset of entries in the Translation Lookaside Buffer (TLB) associated with the memory management unit of the computing system, based on the physical address space, where each entry in the TLB stores a mapping between a virtual address and a physical address (508). Referring again to Figure 2B, the hypervisor may identify entries in TLB 212 based on the physical address space. Referring also to Figures 3 and 4, the hypervisor may look up TLB entries based on physical addresses to identify a subset of entries.

[0061] Process 500 includes invalidating a subset of entries in the TLB (510). Referring to Figure 2B, the hypervisor 202 may invalidate a subset of entries in the TLB 212 identified based on their physical addresses. In some cases, the hypervisor 202 may invalidate an entry by setting an invalidation flag associated with the entry. In some cases, the hypervisor 202 may store a value(s) in the entry that indicates its invalidity.

[0062] The components and processes discussed herein may be implemented on computing systems. In particular, computing systems including computing devices and / or mobile computing devices may be used to implement the technologies described herein. For example, one or more processes, electronic design tools, and data may be implemented on or stored on computing devices or mobile computing devices.

[0063] Computing devices are intended to represent various forms of digital computers, including laptops, desktops, workstations, personal digital assistants, servers, blade servers, mainframes, and other appropriate computers. Mobile computing devices are intended to represent various forms of mobile devices, including personal digital assistants, cellular phones, smartphones, mobile embedded wireless systems, wireless diagnostic computing devices, and other similar computing devices. The components, their connections and relationships, and their functions shown herein are for illustrative purposes only and are not intended to be limiting.

[0064] The computing device includes a processor, memory, storage devices, a high-speed interface connecting to the memory and multiple high-speed expansion ports, and a low-speed interface connecting to the low-speed expansion ports and storage devices. Each of the processor, memory, storage devices, high-speed interfaces, high-speed expansion ports, and low-speed interfaces is interconnected using various buses and may be mounted on a common motherboard or in other ways as needed. The processor can process instructions for execution within the computing device, including instructions for displaying graphical information of a GUI on an external input / output device such as a display coupled to the high-speed interface, which is stored in memory or storage devices. In other embodiments, multiple processors and / or multiple buses may be used as needed, along with multiple memories and multiple types of memory. Furthermore, multiple computing devices may be connected, with each device providing a portion of the operation (e.g., as a server bank, a group of blade servers, or a multiprocessor system). In some embodiments, the processor is a single-threaded processor. In some embodiments, the processor is a multi-threaded processor. In some embodiments, the processor is a quantum computer.

[0065] Memory stores information within a computing device. In some embodiments, memory is a volatile memory unit. In some embodiments, memory is a non-volatile memory unit. Memory can also be other forms of computer-readable media, such as magnetic disks or optical disks.

[0066] Storage devices can provide large-capacity storage to computing devices. In some embodiments, the storage device may be a computer-readable medium such as a floppy disk device, a hard disk device, an optical disk device, or a tape device, flash memory or other similar solid-state memory device, or an array of devices including a storage area network or other configuration. Instructions may be stored in an information carrier. When an instruction is executed by one or more processing devices (e.g., a processor), it performs one or more methods such as those described above. Instructions may also be stored in one or more storage devices such as a computer-readable medium or a machine-readable medium (e.g., memory, storage devices, or memory on a processor). A high-speed interface manages bandwidth-intensive operations for computing devices, while a low-speed interface manages less bandwidth-intensive operations. Such function assignments are merely examples. In some embodiments, the high-speed interface is coupled to memory, a display (e.g., via a graphics processor or accelerator), and a high-speed expansion port that can accept various expansion cards (not shown). In embodiments, the low-speed interface is coupled to storage devices and a low-speed expansion port. The low-speed expansion port may include various communication ports (e.g., USB, Bluetooth®, Ethernet®, Wireless Ethernet) and may be coupled to one or more input / output devices such as a keyboard, pointing device, scanner, or network device such as a switch or router, for example, via a network adapter.

[0067] Computing devices can be implemented in many different forms, as shown in the diagram. For example, they may be implemented as a standard server, or multiple times in a group of such servers. Furthermore, they may be implemented in a personal computer, such as a laptop computer. They may also be implemented as part of a rack server system. Alternatively, components of a computing device may be combined with other components of a mobile device, such as a mobile computing device. Each of such devices may contain one or more computing devices and mobile computing devices, and the entire system may consist of multiple computing devices communicating with each other.

[0068] A mobile computing device includes, among other components, a processor, memory, input / output devices such as a display, a communication interface, and transceivers. The mobile computing device may also provide storage devices such as microdrives or other devices to offer additional storage. Each of the processor, memory, display, communication interface, and transceivers is interconnected using various buses, and some of the components may be mounted on a common motherboard or in other ways as needed.

[0069] The processor can execute instructions within a mobile computing device, including instructions stored in memory. The processor may be implemented as a chipset of chips containing multiple separate analog and digital processors. The processor may provide applications run by the mobile computing device, and wireless communication by the mobile computing device, for the cooperation of other components of the mobile computing device, such as controlling the user interface.

[0070] The processor may communicate with the user via a control interface and a display interface coupled to the display. The display may be, for example, a TFT (Thin Film Transistor Liquid Crystal) display or an OLED (Organic Light Emitting Diode) display, or other suitable display technology. The display interface may include appropriate circuitry for driving the display to present graphic information and other information to the user. The control interface may receive commands from the user and translate the commands for transmission to the processor. Furthermore, an external interface may provide communication with the processor to enable short-range communication between the mobile computing device and other devices. The external interface may provide wired communication in some embodiments, wireless communication in other embodiments, and multiple interfaces may be used.

[0071] Memory stores information within a mobile computing device. Memory can be implemented as one or more computer-readable media, volatile memory units, or non-volatile memory units. Extended memory can also be provided to a mobile computing device and connected to the mobile computing device via an extended interface, which may include, for example, a SIMM (Single In-Line Memory Module) card interface. Extended memory may provide additional storage space to the mobile computing device, or it may also store applications or other information in the mobile computing device. Specifically, extended memory may include instructions that perform or supplement the processing described herein, and may also include secure information. For example, extended memory may be provided as a security module for a mobile computing device and may be programmed with instructions that allow secure use of the mobile computing device. Furthermore, secure applications may be provided via a SIMM card, along with additional information such as placing identification information on the SIMM card in a hack-proof manner.

[0072] The memory may include, for example, flash memory and / or NVRAM memory (non-volatile random access memory), as described below. In some embodiments, instructions are stored on an information carrier so that when an instruction is executed by one or more processing devices (e.g., a processor), it performs one or more methods such as those described above. Instructions may also be stored in one or more storage devices, such as one or more computer-readable or machine-readable media (e.g., memory, extended memory, or memory on a processor). In some embodiments, instructions may be received as signals propagated, for example, via a transceiver or an external interface.

[0073] Mobile computing devices may communicate wirelessly via a communication interface, which may, in some cases, include digital signal processing circuits. The communication interface may provide communication under various modes or protocols, including, among others, GSM® voice calling (Global System for Mobile Communications), SMS (Short Message Service), EMS (Extended Message Service), or MMS messaging (Multimedia Messaging Service), CDMA (Code Division Multiple Access), TDMA (Time Division Multiple Access), PDC (Personal Digital Cellular), WCDMA® (Wideband Code Division Multiple Access), CDMA2000, or GPRS (General Packet Radio Service), LTE, 4G / 5G / 6G cellular, etc. Such communication may be carried out, for example, via a transceiver using radio frequencies. Furthermore, short-range communication may be carried out using Bluetooth, Wi-Fi, or other such transceivers (not shown). Additionally, a GPS (Global Positioning System) receiver module may provide the mobile computing device with additional radio data related to navigation and location, which may be used as needed by applications running on the mobile computing device.

[0074] Mobile computing devices may also perform voice communications using audio codecs that can receive speech information from a user and convert it into usable digital information. Audio codecs may similarly produce audible sounds for the user, for example, through a speaker in the mobile computing device's handset. Such sounds may include sounds from voice telephone calls, recorded sounds (e.g., voice messages, music files, etc.), or sounds generated by applications running on the mobile computing device.

[0075] Mobile computing devices can be implemented in many different forms, as shown in the diagram. For example, they may be implemented as cellular phones. They may also be implemented as part of a smartphone, a personal digital assistant, or other similar mobile device.

[0076] The subject matter and functional embodiments described herein may be implemented in digital electronic circuits, in tangibly embodied computer software or firmware, in computer hardware including the structures disclosed herein and their structural equivalents, or in one or more combinations thereof. Embodiments of the subject matter described herein may be implemented as one or more modules of computer program instructions, i.e., as one or more computer programs encoded in a tangible non-temporary storage medium for execution by a data processing device or for controlling the operation of a data processing device. The computer storage medium may be a machine-readable storage device, a machine-readable storage board, a random or serial access memory device, or one or more combinations thereof. Alternatively or additionally, program instructions may be encoded in artificially generated propagating signals, such as machine-generated electrical signals, optical signals, or electromagnetic signals, which are generated to encode information to be transmitted to a suitable receiving device for execution by a data processing device.

[0077] The term "data processing device" refers to data processing hardware and encompasses all kinds of devices, machines, and equipment for processing data, including, for example, programmable processors, computers, or multiple processors or multiple computers. A device may also be, or even more than, a special-purpose logic circuit, such as an FPGA (Field-Programmable Gate Array) or ASIC (Application-Specific Integrated Circuit). Optionally, in addition to hardware, a device may include code that creates an execution environment for computer programs, such as processor firmware, protocol stacks, database management systems, operating systems, or one or more combinations thereof.

[0078] Computer programs, which may also be called or described as programs, software, software applications, apps, modules, software modules, scripts, or code, can be written in any form of programming language, including compiled languages ​​or interpreted languages, or declarative languages ​​or procedural languages, and can be deployed in any form, including as standalone programs or as modules, components, subroutines, or other units suitable for use in a computing environment. A program may, but is not required to, correspond to a file in a file system. A program may be stored in a single file dedicated to the program in question, in a part of a file that holds one or more scripts stored in other programs or data, such as a markup language document, or in multiple collaborative files, such as a file that holds one or more modules, subprograms, or parts of code. A computer program may be deployed to run on one computer, or it may be located in one place or distributed across multiple locations and interconnected by a data communication network to run on multiple computers.

[0079] Processes and logical flows can also be executed by special-purpose logic circuits, such as FPGAs or ASICs, or by a combination of special-purpose logic circuits and one or more programmed computers. A computer suitable for executing computer programs may be based on a general-purpose or dedicated microprocessor, or both, or any other type of central processing unit. Generally, the central processing unit receives instructions and data from read-only memory, random-access memory, or both. The basic components of a computer are the central processing unit for executing instructions and one or more memory devices for storing instructions and data. The central processing unit and memory may be complemented by or incorporated into dedicated logic circuits. Typically, a computer also includes one or more mass storage devices for storing data, such as magnetic disks, magneto-optical disks, or optical disks, or is operablely coupled to them to receive data from them, transfer data to them, or both. However, a computer is not required to have such devices. Furthermore, computers can be incorporated into other devices, such as mobile phones, personal digital assistants (PDAs), mobile audio or video players, game consoles, Global Positioning System (GPS) receivers, or portable storage devices (such as Universal Serial Bus (USB) flash drives) (these are just a few examples).

[0080] Computer-readable media suitable for storing computer program instructions and data include all forms of non-volatile memory, media, and memory devices, including, for example, semiconductor memory devices such as EPROMs, EEPROMs, and flash memory devices; magnetic disks such as internal hard disks or removable disks; magneto-optical disks; and CD-ROMs and DVD-ROM disks. While this specification includes many specific embodiments, these should be interpreted not as limitations on the scope of any invention or claimed, but rather as descriptions of features that may be specific to particular embodiments of a particular invention. Certain features described in this specification in the context of individual embodiments may also be realized in combination in a single embodiment. Conversely, various features described in the context of a single embodiment may also be realized individually or in any suitable subcombination in multiple embodiments. Furthermore, features may be described above as functioning in a particular combination, and even if initially claimed as such, one or more features from the claimed combination may be removed from the combination, and the claimed combination may cover subcombinations or variations of subcombinations.

[0081] Similarly, while operations are shown in the drawings and described in a specific order in the claims, this should not be understood as requiring that such operations be performed in a specific or sequential order shown, or that all shown operations be performed, in order to obtain the desired results. In certain situations, multitasking and parallel processing may be advantageous. Furthermore, the separation of various system modules and components in the embodiments described above should not be understood as requiring such separation in all embodiments, and it should be understood that the program components and systems described can generally be integrated into a single software product or packaged into multiple software products.

[0082] Specific embodiments of the subject matter have been described. Other embodiments are within the scope of the following claims. For example, the actions described in the claims may be performed in a different order, and this may still yield the desired results. As an example, the process shown in the accompanying diagram does not necessarily require to be performed in the specific order or sequence shown to achieve the desired results. In some cases, multitasking and parallel processing may be advantageous.

Claims

1. A method for managing memory in a computing system, wherein the method is Receiving requests from guest applications for protected memory allocation, In response to the aforementioned request, a physical address space is allocated to the guest operating system that is started to run the guest application, Removing the mapping from the second stage mapping associated with the host operating system running on the computing system to the physical address space, The method further includes identifying a subset of entries in a Translation Lookaside Buffer (TLB) associated with the memory management unit of the computing system, based on the physical address space, wherein each entry in the TLB stores a mapping between a virtual address and a physical address, and the method further includes A method comprising disabling a subset of the entries in the TLB.

2. The method according to claim 1, wherein identifying a subset of the entries in the TLB includes identifying entries in the TLB having physical addresses that match the physical address space allocated to the guest operating system.

3. The method according to claim 1, wherein disabling a subset of entries in the TLB includes setting or resetting a validity flag associated with the subset of entries.

4. Receiving requests from host applications to access data using virtual addresses, Determining that the aforementioned virtual address does not exist in the TLB, To generate a first mapping that maps the aforementioned virtual address to an intermediate physical address, To generate a second mapping that maps the aforementioned intermediate physical address to a physical address, The method according to claim 1, further comprising storing the virtual address from the first mapping and the physical address from the second mapping in the TLB as entries for mapping the virtual address to the physical address.

5. The request from the host application is a first request, and the method is Receiving a second request from the host application to access data at the virtual address, The process involves determining the corresponding physical address from the entries in the TLB that map the virtual address to the physical address, The method according to claim 4, further comprising providing data from the physical address to the host application.

6. The TLB is stored in associative memory, and the method is The associative memory is provided with physical addresses within the physical address space, The method according to claim 4, comprising receiving identification information of a subset of entries in the TLB from the associative memory.

7. The TLB is stored in associative memory, and the method is The associative memory is provided with physical addresses within the physical address space, The method according to claim 4, comprising receiving a virtual address from the associative memory that corresponds to an entry in the TLB that includes a physical address in the physical address space.

8. The method according to claim 1, comprising sending an instruction from the hypervisor to the memory management unit of the computing system to remove the mapping from the second stage mapping to the physical address space.

9. The method according to claim 8, wherein the hypervisor is a protected kernel-based virtual machine.

10. The method according to claim 1, wherein the guest operating system runs within a guest virtual machine managed by a hypervisor.

11. A computing system, A Translation Lookaside Buffer (TLB) containing a mapping from the virtual address space to the physical address space for the host operating system, The computing system further comprises a memory management unit (MMU) configured to perform operations, the operations comprising (1) a first set of operations to translate virtual addresses to intermediate physical addresses, and (2) a second set of operations to translate intermediate physical addresses to physical addresses, the computing system further comprises At least one processor, The system comprises, when executed by the at least one processor, at least one memory that stores operation instructions for executing an operation, and the operation is, Receiving requests from guest applications for protected memory allocation, In response to the aforementioned request, a physical address space is allocated to the guest operating system that is started to run the guest application, Removing the mapping from the second stage mapping associated with the host operating system running on the computing system to the physical address space, Based on the physical address space and from a translation lookaside buffer (TLB) associated with the memory management unit of the computing system, the operation includes identifying a subset of entries in the TLB, where each entry in the TLB stores a mapping between a virtual address and a physical address, and further includes: A computing system comprising disabling a subset of the entries in the TLB.

12. The system according to claim 11, wherein identifying a subset of the entries in the TLB includes identifying entries in the TLB that have a physical address space that matches the physical address space allocated to the guest operating system.

13. The system according to claim 11, wherein disabling a subset of entries in the TLB includes setting or resetting a validity flag associated with the subset of entries.

14. The aforementioned operation is, Receiving requests from host applications to access data using virtual addresses, Determining that the aforementioned virtual address does not exist in the TLB, To generate a first mapping that maps the aforementioned virtual address to an intermediate physical address, To generate a second mapping that maps the aforementioned intermediate physical address to a physical address, The system according to claim 11, further comprising storing the virtual address from the first mapping and the physical address from the second mapping in the TLB as entries for mapping the virtual address to the physical address.

15. The request from the host application is a first request, and the operation is, Receiving a second request from the host application to access data at the virtual address, The process involves determining the corresponding physical address from the entries in the TLB that map the virtual address to the physical address, The system according to claim 14, further comprising providing data from the physical address to the guest application.

16. The TLB is stored in an associative memory, and the associative memory is The physical address in the aforementioned physical address space is received, Search for an entry in the TLB that has a physical address matching the physical address in the physical address space, The system according to claim 11, configured to provide identification information for a subset of entries in the TLB.

17. The TLB is stored in an associative memory, and the associative memory is The physical address in the aforementioned physical address space is received, Search for an entry in the TLB that has a physical address matching the physical address in the physical address space, The system according to claim 11, configured to provide virtual addresses for a subset of the entries in the TLB.

18. The aforementioned operation is, The system according to claim 11, further comprising sending an instruction from the hypervisor to the memory management unit of the computing system to remove the mapping from the second stage mapping to the physical address space.

19. The system according to claim 18, wherein the hypervisor is a protected kernel-based virtual machine.

20. The system according to claim 11, wherein the guest operating system runs within a guest virtual machine managed by a hypervisor.

Images