Reserved safe address range

Abstract

The present disclosure relates to methods and apparatus for graphics processing. Aspects of the present disclosure relate to a method for accessing a secure memory range. In some examples, the method includes reserving a first memory address range within a 32-bit address range for non-secure memory. In some examples, the method includes reserving a second memory address range within a 64-bit address range and outside the 32-bit address range for secure memory. In some examples, the method includes receiving, by a 64-bit kernel, a first command from a 32-bit application to access the secure memory. In some examples, the method includes preparing, by the 64-bit kernel, a 64-bit memory access command based on the first command. In some examples, the method includes transmitting, by the 64-bit kernel, the 64-bit memory access command to a graphics processing unit (GPU).

Description

Background Technology

[0001] Cross-reference to related applications

[0002] This application claims the benefit and priority of Indian Patent Application No. 202141029184, filed on June 29, 2021, which has been assigned to the assignee of this application and is incorporated herein by reference as fully set forth below and for all applicable purposes. Technical Field

[0003] This disclosure generally relates to processing systems, and more specifically, to one or more techniques for graphics processing.

[0004] Description of related technologies

[0005] The graphics processing unit (GPU) can support the processing of both secure (e.g., digital rights management (DRM) protected) and insecure graphics data. For example, an application can store protected graphics data in a secure memory location and unprotected graphics data in an insecure memory location. Therefore, at boot time, the GPU can reserve: (i) a first virtual address range corresponding to the secure memory region, and (ii) a second virtual address range corresponding to the insecure memory region.

[0006] However, in traditional systems, a first virtual address range may correspond to a relatively small amount (e.g., 256 MB) of secure memory resources, while a second virtual address range corresponds to a relatively large amount (e.g., approximately 4 GB) of insecure memory resources, allowing both secure and insecure memory resources to be addressed using 32 bits. Furthermore, because the GPU reserves a fixed range of virtual addresses for both secure and insecure memory resources at boot time, it may be difficult to dynamically meet the needs of both secure and insecure applications during runtime. For example, if the GPU increases the virtual address range of secure memory resources during runtime, the same virtual address range for insecure memory resources will no longer be available, and applications may exhaust the insecure memory resources. Therefore, methods to improve the availability of secure and / or insecure memory resources would be beneficial. Summary of the Invention

[0007] The following is a simplified summary of one or more aspects to provide a basic understanding of these aspects. This invention is not a comprehensive overview of all anticipated aspects, nor is it intended to identify key elements of all aspects, nor to depict the scope of any or all aspects. Its sole purpose is to present some concepts of one or more aspects in a simplified form as a prelude to the more detailed description that follows.

[0008] In some aspects, a method for accessing a secure memory range is disclosed. In one example, the method includes reserving a first memory address range within a 32-bit address range for non-secure memory. In another example, the method includes reserving a second memory address range outside the 32-bit address range and within a 64-bit address range for secure memory. In yet another example, the method includes receiving a first command for accessing secure memory from a 32-bit application via a 64-bit kernel. In yet another example, the method includes preparing a 64-bit memory access command by the 64-bit kernel based on the first command. In yet another example, the method includes transmitting the 64-bit memory access command to a graphics processing unit (GPU) by the 64-bit kernel. In yet another example, the method includes accessing secure memory by the GPU based on the 64-bit memory access command.

[0009] In some aspects, a computing device configured to access a secure memory range is disclosed. In some examples, the computing device includes: a memory; and a processor communicatively coupled to the memory. In some examples, the processor is configured to reserve a first memory address range within a 32-bit address range for non-secure memory. In some examples, the processor is configured to reserve a second memory address range outside the 32-bit address range and within a 64-bit address range for secure memory. In some examples, the processor is configured to receive a first command from a 32-bit application for accessing secure memory via a 64-bit kernel. In some examples, the processor is configured to prepare a 64-bit memory access command based on the first command by the 64-bit kernel. In some examples, the processor is configured to transmit the 64-bit memory access command to a graphics processing unit (GPU) via the 64-bit kernel. In some examples, the processor is configured to allow the GPU to access secure memory based on the 64-bit memory access command.

[0010] In some aspects, a computing device for accessing a secure memory range is disclosed. In one example, the computing device includes components for reserving a first memory address range within a 32-bit address range for non-secure memory. In one example, the computing device includes components for reserving a second memory address range outside the 32-bit address range and within a 64-bit address range for secure memory. In one example, the computing device includes components for receiving a first command from a 32-bit application for accessing secure memory. In one example, the computing device includes components for preparing a 64-bit memory access command based on the first command. In one example, the computing device includes components for transmitting the 64-bit memory access command to a graphics processing unit (GPU). In one example, the computing device includes components for accessing secure memory based on the 64-bit memory access command.

[0011] In some aspects, a non-transitory computer-readable medium having instructions stored thereon is disclosed, which, when executed by a computing device, cause the computing device to perform operations for accessing a secure memory range. In one example, the operations include reserving a first memory address range within a 32-bit address range for non-secure memory. In one example, the operations include reserving a second memory address range outside the 32-bit address range and within a 64-bit address range for secure memory. In one example, the operations include receiving a first command from a 32-bit application for accessing secure memory by a 64-bit kernel. In one example, the operations include preparing a 64-bit memory access command by the 64-bit kernel based on the first command. In one example, the operations include transmitting the 64-bit memory access command to a graphics processing unit (GPU) by the 64-bit kernel. In one example, the operations include accessing secure memory by the GPU based on the 64-bit memory access command.

[0012] Details of one or more examples of this disclosure are set forth in the accompanying drawings and the following description. Other features, objects, and advantages of this disclosure will be apparent from the description, drawings, and claims. Attached Figure Description

[0013] Figure 1 This is a block diagram illustrating an example of a system for generating data based on certain aspects of this disclosure.

[0014] Figure 2 This is a block diagram illustrating an example graphics processing system according to certain aspects of this disclosure.

[0015] Figure 3 This is a block diagram illustrating example hardware and software aspects according to certain aspects of this disclosure.

[0016] Figure 4 This is a flowchart illustrating an example operation of allocating memory resources for secure graphical commands in accordance with certain aspects of this disclosure. Detailed Implementation

[0017] This disclosure provides techniques for increasing the virtual address range corresponding to a secure memory used for storing data (e.g., protected graphics).

[0018] In some aspects, a graphics processing unit (GPU) may include integrated circuit hardware for graphics processing. The GPU may include a software aspect, referred to herein as a "GPU driver," which may operate as part of a central processing unit (CPU). Upon boot, the GPU driver may reserve an exclusive range of possible 32-bit virtual addresses, where a first range corresponds to secure memory resources and a second range corresponds to non-secure memory resources. In one example, for a 32-bit application, the GPU driver may reserve a 4 gigabyte (GB) range of non-secure virtual addresses and a 256 megabyte (MB) range of secure virtual addresses excluded from the non-secure virtual addresses. However, by reserving such distinct ranges between secure and non-secure virtual addresses, it may be difficult to dynamically meet the needs of both secure and non-secure applications during runtime. For example, any increase in the secure virtual address range during runtime will necessarily result in a reduction in the supplementary range of non-secure virtual addresses. This impact on the non-secure virtual address range may lead to the loss of available virtual addresses for non-secure applications. Therefore, techniques for increasing the range of secure virtual addresses without compromising the amount of available non-secure virtual addresses can improve GPU functionality.

[0019] To increase the range of secure virtual addresses without compromising the availability of non-secure virtual addresses, the GPU driver can be configured to reserve 64-bit virtual addresses for a first range corresponding to secure memory resources and 32-bit virtual memory addresses for a second range corresponding to non-secure memory resources. The 64-bit virtual address range can be virtual addresses higher than and excluded from the 32-bit range. For example, non-secure memory resources can be addressed by a virtual address range from 0 to 2^32-1, and secure memory resources can be addressed by a virtual address range from 2^32 to X, where X is a value between 2^32+1 and 2^64-1. In other words, the GPU driver can increase the range of virtual addresses corresponding to secure memory resources by using 64-bit virtual addresses instead of 32-bit virtual addresses.

[0020] The following describes more fully various aspects of systems, apparatuses, computer program products, and methods for increasing the virtual address range corresponding to secure memory resources used for storing data. However, this disclosure may be embodied in many different forms and should not be construed as limited to any particular structure or function presented throughout this disclosure. Rather, these aspects are provided so that this disclosure will be thorough and complete, and will fully convey the scope of this disclosure to those skilled in the art. Based on the teachings herein, those skilled in the art will understand that the scope of this disclosure is intended to cover any aspect of the systems, apparatuses, computer program products, and methods disclosed herein, whether implemented independently of or in combination with other aspects of this disclosure. For example, any number of aspects set forth herein may be used to implement an apparatus or practice. Furthermore, the scope of this disclosure is intended to cover such apparatuses or methods that are practiced using structures, functions, or structures and functions that complement or are separate from the various aspects of this disclosure set forth herein. Any aspect disclosed herein may be embodied by one or more elements of the claims.

[0021] Although various aspects are described herein, numerous variations and substitutions of these aspects fall within the scope of this disclosure. While some potential benefits and advantages of the aspects of this disclosure have been mentioned, the scope of this disclosure is not intended to be limited to specific benefits, uses, or objectives. Rather, the aspects of this disclosure are intended to be broadly applicable to different graphics technologies, system configurations, etc., some of which are illustrated by way of example in the accompanying drawings and the description below. The detailed description and drawings are merely illustrative and not limiting of this disclosure, and the scope of this disclosure is defined by the appended claims and their equivalents.

[0022] Several aspects are presented with reference to various apparatuses and methods. These apparatuses and methods are described in the following specific embodiments and illustrated in the accompanying drawings by various blocks, components, circuits, processes, algorithms, etc. (collectively referred to as "elements"). These elements can be implemented using electronic hardware, computer software, or any combination thereof. Whether these elements are implemented as hardware or software depends on the specific application and the design constraints imposed on the system as a whole.

[0023] For example, an element, or any part of an element, or any combination of elements, can be implemented as a “processing system” including one or more processors (which may also be referred to as processing units). Examples of processors include microprocessors, microcontrollers, graphics processing units (GPUs), general-purpose GPUs, central processing units (CPUs), application processors, digital signal processors (DSPs), reduced instruction set computing (RISC) processors, system-on-a-chip (SoCs), baseband processors, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), programmable logic devices (PLDs), state machines, gated logic, discrete hardware circuits, and other suitable hardware configured to perform the various functions described in this disclosure. One or more processors in a processing system can execute software. Software can be interpreted broadly as instructions, instruction sets, code, code segments, program code, programs, subroutines, software components, applications, software applications, software packages, routines, subroutines, objects, executable files, threads of execution, procedures, functions, etc., whether referring to software, firmware, middleware, microcode, hardware description languages, or other names. The term “application” can refer to software. As described herein, one or more technologies can refer to an application, i.e., software, configured to perform one or more functions. In such examples, the application may be stored on memory (e.g., on-chip memory of the processor, system memory, or any other memory). The hardware described herein (such as a processor) may be configured to execute the application. For example, the application may be described as including code that, when executed by the hardware, causes the hardware to perform one or more techniques described herein. As an example, the hardware may access and execute code accessed from memory to perform one or more techniques described herein. In some examples, components are identified in this disclosure. In such examples, a component may be hardware, software, or a combination thereof. Each component may be a separate component or a subcomponent of a single component.

[0024] Accordingly, in one or more examples described herein, the described functionality can be implemented in hardware, software, or any combination thereof. If implemented in software, the functionality can be stored or encoded as one or more instructions or code on a computer-readable medium. Computer-readable media include computer storage media. Storage media can be any available medium accessible to a computer. By way of example, and not limitation, such computer-readable media can include random access memory (RAM), read-only memory (ROM), electrically erasable programmable ROM (EEPROM), optical disc storage, magnetic disk storage, other magnetic storage devices, combinations of computer-readable media of the types described above, or any other medium that can be used to store computer-executable code in the form of computer-accessible instructions or data structures.

[0025] As used herein, instances of the term "content" can refer to "graphic content," "image," or vice versa. This is true regardless of whether these terms are used as adjectives, nouns, or other parts of speech. In some examples, as used herein, the term "graphic content" can refer to content produced by one or more processes in the graphics processing pipeline. In some examples, as used herein, the term "graphic content" can refer to content produced by a processing unit configured to perform graphics processing. In some examples, as used herein, the term "graphic content" can refer to content produced by a graphics processing unit.

[0026] In some examples, as used herein, the term "display content" can refer to content generated by a processing unit configured to perform display processing. Graphical content can be processed to become display content. For example, a graphics processing unit can output graphical content (such as frames) to a buffer (which may be referred to as a frame buffer). A DPU can read graphical content (such as one or more frames) from the buffer and perform one or more display processing techniques on it to generate display content. For example, a DPU can be configured to perform compositing on one or more rendered layers to generate frames. As another example, a DPU can be configured to composite, blend, or otherwise combine two or more layers into a single frame. A DPU can be configured to perform scaling on frames, such as zooming in or out. In some examples, a frame can refer to a layer. In other examples, a frame can refer to two or more layers that have been blended together to form the frame, i.e., the frame comprises two or more layers, and the frame comprising two or more layers can be subsequently blended.

[0027] Figure 1 This is a block diagram illustrating an example content generation system 100 configured to implement one or more technologies of the present disclosure. The content generation system 100 includes a computing device 104. The computing device 104 may include one or more components or circuitry for performing the various functions described herein. In some examples, one or more components of the computing device 104 may be components of a system-on-a-chip (SOC) or an integrated circuit (IC). The computing device 104 may include one or more components configured to perform one or more technologies of the present disclosure. In the example shown, device 104 may include a GPU 120, a CPU 122, and system memory 124. In some aspects, device 104 may include a plurality of optional components, such as a communication interface 126, a transceiver 132, a receiver 128, a transmitter 130, a DPU 127, and one or more displays 131.

[0028] A reference to display 131 may refer to one or more displays 131. For example, display 131 may include a single display or multiple displays. Display 131 may include a first display and a second display. The first display may be a left-eye display, while the second display may be a right-eye display. In some examples, the first and second displays may receive different frames for rendering on them. In other examples, the first and second displays may receive the same frames for rendering on them. In further examples, the results of graphics processing may not be displayed on the device; for example, the first and second displays may not receive any frames for rendering on them. Instead, the frames or graphics processing results may be transferred to another device. In some respects, this may be referred to as split rendering.

[0029] GPU 120 may include internal memory 121. GPU 120 may be configured to perform graphics processing, for example, in graphics processing pipeline 107. CPU 122 may include internal memory 123. In some examples, device 104 may include a display processor (such as DPU 127) to perform one or more display processing techniques on one or more frames generated by GPU 120 before being rendered by one or more displays 131. DPU 127 may be configured to perform display processing. For example, DPU 127 may be configured to perform one or more display processing techniques on one or more frames generated by GPU 120. The one or more displays 131 may be configured to display or otherwise render the frames processed by DPU 127. In some examples, one or more displays 131 may include one or more of the following: liquid crystal display (LCD), plasma display, organic light-emitting diode (OLED) display, projection display device, augmented reality display device, virtual reality display device, head-mounted display, or any other type of display device.

[0030] External memory (e.g., system memory 124) of GPU 120 and CPU 122 can be accessed by GPU 120 and CPU 122. For example, GPU 120 and CPU 122 can be configured to read from and / or write to external memory (such as system memory 124). GPU 120 and CPU 122 can be communicatively coupled to system memory 124 via a bus. In some examples, GPU 120 and CPU 122 can be communicatively coupled to each other via a bus or different connections.

[0031] CPU 122 can be configured to receive graphical content from any source, such as system memory 124 and / or communication interface 126. System memory 124 can be configured to store received encoded or decoded graphical content. CPU 122 can be configured to receive encoded or decoded graphical content from system memory 124 and / or communication interface 126, for example, in the form of encoded pixel data. CPU 122 can be configured to encode or decode any graphical content.

[0032] Internal memory 121 or system memory 124 may include one or more volatile or non-volatile memories or storage devices. In some examples, internal memory 121 or system memory 124 may include RAM, SRAM, DRAM, erasable programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), flash memory, magnetic data media or optical storage media or any other type of memory.

[0033] According to some examples, internal memory 121 or system memory 124 may be a non-transitory storage medium. The term "non-transitory" may indicate that the storage medium is not implemented in a carrier or propagating signal. However, the term "non-transitory" should not be construed as meaning that internal memory 121 or system memory 124 is not removable or that its contents are static. As an example, system memory 124 may be removed from device 104 and moved to another device. As another example, system memory 124 may not be removable from device 104.

[0034] GPU 120 may be a general-purpose GPU or any other processing unit configured to perform graphics processing. In some examples, GPU 120 may be integrated into the motherboard of device 104. In some examples, GPU 120 may reside on a graphics card mounted in a port on the motherboard of device 104, or may be otherwise incorporated into a peripheral device configured to interoperate with device 104. GPU 120 may include one or more processors, such as one or more microprocessors, GPUs, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), arithmetic logic units (ALUs), digital signal processors (DSPs), discrete logic, software, hardware, firmware, other equivalent integrated or discrete logic circuits, or any combination thereof. If these techniques are partially implemented in software, GPU 120 may store instructions for software in a suitable, non-transitory computer-readable storage medium (e.g., internal memory 121), and may use one or more processors to execute the instructions in hardware to perform the techniques of this disclosure. Any of the foregoing (including hardware, software, combinations of hardware and software, etc.) may be considered as one or more processors.

[0035] CPU 122 can be any processing unit configured to send instructions to GPU 120 and perform general computational processing (e.g., non-graphics processing). In some examples, CPU 122 may be integrated into the motherboard of device 104. CPU 122 may include one or more processors, such as one or more microprocessors, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), arithmetic logic units (ALUs), digital signal processors (DSPs), video processors, discrete logic, software, hardware, firmware, other equivalent integrated or discrete logic circuits, or any combination thereof. If these techniques are partially implemented in software, CPU 122 may store instructions for software in a suitable, non-transitory computer-readable storage medium (e.g., internal memory 123), and may use one or more processors to execute the instructions in hardware to perform the techniques of this disclosure. Any of the foregoing (including hardware, software, combinations of hardware and software, etc.) can be considered as one or more processors.

[0036] In some aspects, the content generation system 100 may include an optional communication interface 126. The communication interface 126 may include a receiver 128 and a transmitter 130. The receiver 128 may be configured to perform any of the receiving functions described herein with respect to device 104. Additionally, the receiver 128 may be configured to receive information from another device, such as eye or head position information, rendering commands, or location information. The transmitter 130 may be configured to perform any of the transmission functions described herein with respect to device 104. For example, the transmitter 130 may be configured to transmit information to another device, which may include a request for content. The receiver 128 and the transmitter 130 may be combined to form a transceiver 132. In such an example, the transceiver 132 may be configured to perform any of the receiving and / or transmission functions described herein with respect to device 104.

[0037] As described herein, a device such as device 104 can refer to any device, apparatus, or system configured to perform one or more of the techniques described herein. For example, a device can be a server, base station, user equipment, client device, station, access point, computer (e.g., personal computer, desktop computer, laptop computer, tablet computer, computer workstation, or mainframe computer), end product, apparatus, telephone, smartphone, server, video game platform or console, handheld device (e.g., portable video game device or personal digital assistant (PDA)), wearable computing device (e.g., smartwatch, augmented reality device, or virtual reality device), non-wearable device, display or display device, television, set-top box, intermediate network device, digital media player, video streaming device, content streaming device, in-vehicle computer, any mobile device, any device configured to generate graphical content, or any device configured to perform one or more of the techniques described herein. The processes described herein may be described as being performed by a specific hardware component (e.g., GPU), but in further embodiments, they may be performed using other hardware components (e.g., CPU) consistent with the disclosed embodiments.

[0038] GPUs can process various types of data or data packets within the GPU pipeline. For example, in some aspects, a GPU can process two types of data or data packets, such as context register packets and draw call data. Context register packets can be a set of global state information, such as information about global registers, shaders, or constant data, which can adjust how the graphics context will be processed. For example, a context register packet may include information about the color format. In some aspects of a context register packet, there may be bits indicating which workload belongs to the context register. Furthermore, multiple functions or programs can run simultaneously and / or in parallel. For example, a function or program may describe an operation, such as a color mode or color format. Therefore, context registers can define various states of the GPU.

[0039] Context states can be used to determine how individual processing units (e.g., vertex extractor (VFD), vertex shader (VS), shader processor, or geometry processor) operate and / or in which mode a processing unit operates. To do this, the GPU can use context registers and programming data. In some aspects, the GPU can generate workloads in the pipeline based on the mode or state defined by the context registers, such as vertex or pixel workloads. Certain processing units (e.g., VFDs) can use these states to determine certain functions, such as how to aggregate vertices. Because these modes or states can change, the GPU may need to modify the corresponding context. Additionally, the workload corresponding to a mode or state can follow the changed mode or state.

[0040] Figure 2 This is a schematic diagram illustrating an example image processing system 200. System 200 typically includes a user-mode domain 212 and a kernel-mode domain 214. One or more applications 202 (e.g., in...) Figure 1 The application and / or process executing in CPU 122 can execute in user-mode domain 212. In some examples, graphics device driver 216 (e.g., Figure 1 The GPU driver of GPU 120 may be implemented in either or both of user-mode domain 212 and kernel-mode domain 214. The graphics processing system may be part of a 64-bit kernel or runtime environment, such as part of an operating system running on CPU 122 of system 100.

[0041] On the user-mode side, system 200 includes a user-mode driver (UMD) 204 configured to receive graphics workloads from one or more applications 202, including graphics commands such as memory writes, memory-mapped input / output (MMIO) writes, memory reads, or any other graphics commands. The one or more applications 202 may include one or more 32-bit and / or 64-bit applications 202. The one or more applications 202 may be any application that generates memory commands (e.g., read, write, delete, etc.). In response to a memory command, UMD 204 can determine whether the command is for secure memory or insecure memory. For example, if the memory command is for secure memory, UMD 204 can determine a 64-bit virtual memory address from a range of 64-bit virtual memory addresses beyond the possible 32-bit virtual memory address range (e.g., greater than 2^32-1) corresponding to secure memory resources. Conversely, if the command is for insecure memory, UMD 204 can determine a 32-bit virtual memory address from a range of 32-bit virtual memory addresses corresponding to insecure memory resources. UMD 204 can then provide the kernel-mode driver (KMD) 206 with a command (e.g., command buffer location) and the determined virtual memory address, as well as an indication of whether the command is safe (e.g., a security token).

[0042] Kernel-mode domain 214 may include KMD 206 and GPU 208. KMD 206 may be configured to receive memory commands, virtual memory addresses, and an indication of whether the command is safe. In some examples, KMD 206 may verify any received command designated as safe. KMD 206 may then provide GPU 208 with the command, virtual memory address, and an indication of whether the command is safe. For example, KMD 206 may output the command to a batch buffer specifying the safety status (safe or unsafe) of the corresponding batch buffer. GPU 208 may receive batch buffer commands from KMD 206 and execute the command (e.g., read / write) using physical memory resources corresponding to the virtual memory address (e.g., by using page tables that map virtual memory addresses to physical memory addresses).

[0043] Figure 3 This is a block diagram illustrating example hardware and software aspects 300 configured to use the techniques of this disclosure. Example hardware and software aspects 300 may be included as... Figure 1 The computing device 104 is an aspect of this. In the example shown, example hardware and software aspect 300 may include GPU 302 (e.g., Figure 1 GPU 120), CPU 304 (for example, Figure 1 CPU 122), memory management unit 306 and system memory 308 (e.g., CPU 122), memory management unit 306 and system memory 308 Figure 1 System memory 124).

[0044] CPU 304 may include multiple device drivers, which in Figure 3 The example is shown as "GPU driver 310" and "MMU driver 312". Each of GPU driver 310 and MMU driver 312 may include Figure 2 One or more components of the user-mode domain 212 and kernel-mode domain 214 shown. That is, aspects of the GPU driver 310 and the MMU driver 312 can operate as one or more of the UMD 204 and / or KMD 206. The device driver can be stored as a software program and executed by the CPU 304 to provide a communication interface between one or more hardware devices and the operating system. For example, an application 202 or other process executing on the CPU 304 can issue graphics commands to the GPU 302 via the GPU driver 310, or memory commands to the memory management unit (MMU) 306 via the MMU driver 312.

[0045] After booting, GPU driver 310 may retain: (i) a non-secure virtual memory address range 316 corresponding to non-secure memory resource 322, and (ii) a secure virtual memory address range 318 corresponding to secure memory resource 320. Non-secure memory resource 322 and secure memory resource 320 may be resources of system memory 308. The first virtual memory address range may include 32-bit virtual addresses, while the second memory address range may include 64-bit virtual addresses. It should be noted that the second virtual memory address range is outside the addresses of the first range (e.g., no virtual address belongs to either the first or second range). Non-secure memory resource 322 and secure memory resource 320 may be configured to store data associated with memory commands (e.g., graphics information). GPU driver 310 may store non-secure virtual memory address range 316 and secure virtual memory address range 318 in internal memory accessible by GPU 302 (e.g., Figure 1 In the internal memory (121 / 123).

[0046] As understood in the art, a "virtual memory address" addresses a virtual memory resource that the operating system (e.g., using page tables as discussed herein) maps to a physical memory resource, so that an application does not directly reference a memory location by its physical address located on physical memory. Therefore, it should be noted that a virtual memory address is different from a physical memory address. As described in more detail below, the MMU 306 can perform the translation of virtual memory addresses to physical memory addresses.

[0047] GPU driver 310 may notify MMU driver 312 of the stored insecure virtual memory address range 316 and secure virtual memory address range 318. Using page table manager 314, MMU driver 312 may perform the mapping of virtual memory addresses to physical memory addresses. For example, page table manager 314 may generate an insecure page table 326 that provides a mapping between 32-bit virtual addresses for the first virtual memory address range and their corresponding physical memory addresses. Similarly, page table manager 314 may generate a secure page table 324 that provides a mapping between 64-bit virtual addresses for the second virtual memory address range and their corresponding physical memory addresses.

[0048] Page table manager 314 can store page tables in internal memory accessible by MMU 306 or in a location in system memory 308. In some examples, the physical memory address may include a memory address represented as a binary number associated with a location in system memory 308. For example, MMU 306 may receive memory commands corresponding to a specific virtual memory address. Using appropriate page tables, MMU 306 can determine the physical address and execute memory commands (e.g., read / write / delete / etc. data stored at that location).

[0049] Example procedure for increasing the virtual address range of secure memory.

[0050] Initially, application 202 can direct to user-mode drivers (e.g., Figure 2 The UMD 204 submits a secure memory command. The secure memory command can be a request from application 202 to access a location in secure memory 320. Because the memory command is secure, the UMD 204 can associate a virtual memory address from secure memory range 318 with the memory command. In this example, the application is a 32-bit application, and the virtual memory address is a 64-bit address. The UMD 204 can pass the memory command, the virtual memory location, and an indication of the security nature of the memory command to the kernel-mode driver (e.g., Figure 2 The kernel-mode driver (KMD 206) can then provide information to the GPU 302. That is, the UMD 204 and KMD 206 can prepare 64-bit memory access commands by associating secure memory commands with 64-bit virtual memory addresses.

[0051] Upon receiving a memory command, the KMD 206 and / or GPU driver 310 can set the memory mode 328 of the GPU 302. The memory mode 328 of the GPU 302 can include two modes: secure and insecure. For example, if the GPU 302 is placed in insecure mode, the GPU 302 will block any I / O (input / output, such as read, write, delete, etc.) access to secure memory 320 via the functions of the memory access controller 330, because the memory access controller 330 may only be able to perform I / O on insecure memory 322 in insecure mode.

[0052] Because GPU 302 may be unable to access either the non-secure or secure page tables, GPU 302 may rely on MMU 306 to translate virtual addresses into corresponding physical addresses. In the current example, MMU 306 may also request an indication that GPU 302 is in secure memory mode before MMU 306 can look up the physical memory address from secure page table 324. Therefore, when GPU 302 is in secure memory mode, memory access controller 330 may generate a stream ID. In some examples, the stream ID is a hardware signal indicating to MMU 306 that GPU 302 is in secure memory mode. For example, the stream ID may be a 1-bit status indicator of whether GPU 302 is in secure or non-secure memory mode.

[0053] In the current example, because the 64-bit virtual memory address received by GPU 302 is within the secure memory address range 318, memory access controller 330 can set a stream ID to indicate that GPU 302 is in secure memory mode 328. GPU 302 can then send the secure virtual memory address to MMU 306. Once MMU 306 determines that GPU 302 is in secure memory mode, MMU can use secure page table 324 to determine the secure physical memory address corresponding to the secure virtual memory address. MMU 306 can then access the secure memory location 320 associated with the determined physical memory address. MMU 306 and / or GPU 302 can then use the secure memory location 320 to execute commands.

[0054] Example procedures for increasing the secure memory virtual address range in multiple applications

[0055] In some aspects, multiple applications may run on CPU 304 and simultaneously issue secure graphics commands. In some aspects, page table manager 314 utilizes the same secure page table for each of the multiple applications, meaning that multiple applications share the same virtual address range. This may limit the amount of memory that can be addressed by multiple applications. In some aspects, page table manager 314 may generate separate secure page tables for each of the multiple applications. In one example, after receiving multiple secure memory commands from more than one application, UMD 204 or GPU driver 310 may prompt MMU driver 312 to generate separate secure page tables for the multiple applications. In the case of two 32-bit applications issuing secure memory commands, page table manager 314 may then generate a first secure page table for the first 32-bit application and a second page table for the second 32-bit application. Here, the first page table maps a range of 64-bit virtual memory addresses to physical addresses in secure memory 320. Similarly, the second secure page table maps the same range of 64-bit virtual memory addresses to physical addresses in secure memory 320. In some respects, even when the secure virtual address range is within the 32-bit addressing range, the use of separate secure page tables for each application (or group of applications) can be similarly employed to divide the 32-bit addressing range between secure and insecure memory.

[0056] However, the MMU 306 may not know which application is associated with which page table, or even which command corresponds to which application. Therefore, before receiving a security command with a virtual memory address from the GPU 302, it may be necessary to inform the MMU 306 which page table to use (e.g., the first security page table or the second security page table). To prepare the MMU 306 to use the correct security page table for the incoming security command, the GPU driver 310 can use one of two different methods.

[0057] In the first method, GPU driver 310 may receive a first secure memory command from a first application. Because multiple applications may issue secure memory commands, GPU driver 310 may transmit a request to MMU driver 312, requesting MMU driver 312 to change the address value of the base address at MMU 306. Here, the request may instruct MMU driver 312 to change the address value of the base address to a value corresponding to the location of a first secure page table associated with the first application. In some examples, the base address is a register value used by MMU 306 to determine the storage location of the secure page table.

[0058] MMU driver 312 can then change the address value of the base address to reflect the location of the first secure page table. In some examples, GPU driver 310 may provide the location of the first secure page table to MMU driver 312. However, if GPU driver 310 cannot access this information, then MMU driver 312 may determine the location of the first secure page table based on data provided by the GPU driver (e.g., an identifier of the first application, or any other suitable information).

[0059] MMU driver 312 can then notify GPU driver 310 that the base address value has been set to reflect the location of the first secure page table. In response to the notification, GPU driver 310 can then provide the first secure memory command to GPU 302. As discussed above, GPU 302 can then provide the first secure memory command to MMU 306, which will then use the first secure page table (which is dedicated to the first application from which the first secure graphics command originates) to map the virtual memory address of the first secure memory command to the corresponding physical memory address.

[0060] In the second method, GPU driver 310 may receive a first secure memory command from the first application. However, instead of notifying MMU driver 312, GPU driver 310 may transmit a request to GPU 302, requesting GPU 302 to change the address value of the base address at MMU 306. Here, the request may instruct GPU 302 to change the address value of the base address to a value corresponding to the location of the first secure page table associated with the first application.

[0061] GPU 302 can then change the base address value to reflect the location of the first secure page table. In this method, GPU driver 310 can send a request to GPU 302 along with the first secure memory command. Therefore, GPU 302 can set the base address and then provide the virtual memory address associated with the first secure memory command to MMU 306.

[0062] If GPU driver 310 receives a second secure memory command from a second application, then GPU driver may execute either the first method or the second method to ensure that the base address of MMU 306 is changed from the first secure page table to the second secure page table before issuing the second secure memory command to MMU 306. In some examples, GPU driver 310 may first verify that the first secure memory command has been completed before executing either the first method or the second method to update the base address.

[0063] Figure 4This is a flowchart illustrating an example operation 400 of allocating memory resources for secure graphics commands according to certain aspects of this disclosure. Operation 400 may be performed, for example, by a computing device (e.g., Figure 1 The operation 400 can be executed on one or more processors (e.g., computing device 104). Figure 1 and Figure 3 Software components that execute and run on the CPU 122 / 304, GPU 120 / 302 and MMU 306.

[0064] Operation 400 can be initiated at the first block 402 by reserving a first memory address range within a 32-bit address range for non-secure memory.

[0065] Operation 400 can continue at the second block 404 by reserving a second memory address range outside the 64-bit address range and the 32-bit address range for the secure memory.

[0066] Operation 400 can continue at the third block 406 by receiving the first command from the 32-bit application for accessing secure memory by the 64-bit kernel.

[0067] Operation 400 can continue at box 408 by the 64-bit kernel preparing a 64-bit memory access command based on the first command.

[0068] Operation 400 can continue at box 410 by transferring 64-bit memory access commands to the graphics processing unit (GPU) via the 64-bit kernel.

[0069] Operation 400 can continue at box 6, 412, by accessing secure memory via 64-bit memory access commands from the GPU.

[0070] In some aspects, operation 400 includes generating a first page table for a 32-bit application, wherein the first page table maps a first 64-bit virtual address in a 64-bit address range to a first physical address in secure memory; and generating a second page table for a second 32-bit application, wherein the second page table maps the first 64-bit virtual address to a second physical address in secure memory.

[0071] In some aspects, operation 400 includes, in response to receiving a first command, setting a base address value at the memory management unit (MMU) to a first address value corresponding to a location of the first page table by the GPU driver, wherein transmitting the 64-bit memory access command to the GPU further includes transmitting the 64-bit memory access command to the GPU after setting the base address value to the first address value.

[0072] In some aspects, operation 400 includes the MMU determining a first physical address corresponding to a first 64-bit virtual address based on a first page table, wherein accessing secure memory based on a 64-bit memory access command further includes accessing secure memory using the first physical address.

[0073] In some aspects, operation 400 includes receiving a second command from a second 32-bit application for accessing secure memory by a 64-bit kernel; in response to receiving the second command, setting a base address value at the MMU to a second address value corresponding to a location in the second page table by the GPU driver; preparing a second 64-bit memory access command by the 64-bit kernel based on the second command; and after setting the base address value to the second address value, transmitting the second 64-bit memory access command to the GPU by the 64-bit kernel.

[0074] In some aspects, operation 400 includes determining whether the execution of the first command has been completed in response to receiving the second command, wherein setting the base address value at the MMU to the second address value further includes setting the base address value at the MMU to the second address value after determining that the execution of the first command has been completed.

[0075] In some aspects, the first memory address range includes a first virtual address range corresponding to non-secure memory resources; and the second memory address range includes a second virtual address range corresponding to secure memory resources.

[0076] In some respects, preparing a 64-bit memory access command also includes associating a 64-bit virtual address with a first command by the 64-bit kernel, wherein the 64-bit memory access command includes a 64-bit virtual address and a first command.

[0077] In some respects, reserving the first memory address range and reserving the second memory address range are performed by the GPU driver.

[0078] Exemplary aspects

[0079] Examples of implementations are described in the following numbered clauses:

[0080] 1. A method for accessing a secure memory range, comprising: reserving a first memory address range within a 32-bit address range for non-secure memory; reserving a second memory address range within a 64-bit address range and outside the 32-bit address range for secure memory; receiving a first command from a 32-bit application for accessing the secure memory by a 64-bit kernel; preparing a 64-bit memory access command by the 64-bit kernel based on the first command; transmitting the 64-bit memory access command to a graphics processing unit (GPU) by the 64-bit kernel; and accessing the secure memory by the GPU based on the 64-bit memory access command.

[0081] 2. The method according to aspect 1, further comprising: generating a first page table for the 32-bit application, wherein the first page table maps a first 64-bit virtual address in the 64-bit address range to a first physical address in the secure memory; and generating a second page table for the second 32-bit application, wherein the second page table maps the first 64-bit virtual address to a second physical address in the secure memory.

[0082] 3. The method according to aspect 2 further includes: in response to receiving the first command, by

[0083] The GPU driver sets the base address value at the memory management unit (MMU) to a first address value corresponding to the location of the first page table, wherein transmitting the 64-bit memory access command to the GPU further includes transmitting the 64-bit memory access command to the GPU after setting the base address value to the first address value.

[0084] 4. The method according to aspect 3 further includes: the MMU determining the first physical address corresponding to the first 64-bit virtual address based on the first page table, wherein accessing the secure memory based on the 64-bit memory access command further includes accessing the secure memory using the first physical address.

[0085] 5. The method according to aspect 3, further comprising: receiving a second command from the second 32-bit application for accessing the secure memory by the 64-bit kernel; in response to receiving the second command, setting the base address value at the MMU to a second address value corresponding to the location of the second page table by the GPU driver; preparing a second 64-bit memory access command by the 64-bit kernel based on the second command; and

[0086] After the base address value is set to the second address value, the 64-bit kernel transmits the second 64-bit memory access command to the GPU.

[0087] 6. The method according to aspect 5 further includes: in response to receiving the second command, determining whether the execution of the first command has been completed, wherein setting the base address value at the MMU to the second address value further includes: after determining that the execution of the first command has been completed, setting the base address value at the MMU to the second address value.

[0088] 7. The method according to any one of aspects 1 to 6, wherein: the first memory address range includes a first virtual address range corresponding to a non-secure memory resource; and the second memory address range includes a second virtual address range corresponding to a secure memory resource.

[0089] 8. The method according to any one of aspects 1 to 7, wherein preparing the 64-bit memory access command further includes associating a 64-bit virtual address with the first command by the 64-bit kernel, wherein the 64-bit memory access command includes the 64-bit virtual address and the first command.

[0090] 9. The method according to any one of aspects 1 to 8, wherein the reservation of the first memory address range and the reservation of the second memory address range are performed by the GPU driver of the 64-bit kernel.

[0091] 10. A computing device configured to access a secure memory range, the computing device comprising: a memory; and one or more processors coupled to the memory, the one or more processors being configured to: reserve a first memory address range within a 32-bit address range for non-secure memory; reserve a second memory address range for secure memory in a 64-bit address range and outside the 32-bit address range; receive a first command from a 32-bit application for accessing the secure memory; prepare a 64-bit memory access command based on the first command; transmit the 64-bit memory access command to a graphics processing unit (GPU); and access the secure memory based on the 64-bit memory access command.

[0092] 11. The computing device according to aspect 10, wherein the one or more processors are further configured to: generate a first page table for the 32-bit application, wherein the first page table maps a first 64-bit virtual address in the 64-bit address range to a first physical address in the secure memory; and generate a second page table for a second 32-bit application, wherein the second page table maps the first 64-bit virtual address to a second physical address in the secure memory.

[0093] 12. The computing device according to aspect 11, wherein the one or more processors are further configured to set a base address value at a memory management unit (MMU) to a first address value corresponding to a location of the first page table in response to receiving the first command, wherein the one or more processors configured to transmit the 64-bit memory access command to the GPU are further configured to transmit the 64-bit memory access command to the GPU after setting the base address value to the first address value.

[0094] 13. The computing device according to aspect 12, wherein the one or more processors are further configured to determine the first physical address corresponding to the first 64-bit virtual address based on the first page table, wherein the one or more processors configured to access the secure memory based on the 64-bit memory access command are further configured to access the secure memory using the first physical address.

[0095] 14. The computing device according to aspect 12, wherein the one or more processors are further configured to: receive a second command from the second 32-bit application for accessing the secure memory; in response to the second command, set the base address value at the MMU to a second address value corresponding to a location of the second page table; prepare a second 64-bit memory access command based on the second command; and after setting the base address value to the second address value, transmit the second 64-bit memory access command to the GPU.

[0096] 15. The computing device according to aspect 14, wherein the one or more processors are further configured to determine whether the execution of the first command has been completed in response to receiving the second command, wherein the one or more processors configured to set the base address value at the MMU to the second address value are further configured to set the base address value at the MMU to the second address value after determining that the execution of the first command has been completed.

[0097] 16. The computing device according to any one of aspects 10 to 15, wherein: the first memory address range includes a first virtual address range corresponding to a non-secure memory resource; and the second memory address range includes a second virtual address range corresponding to a secure memory resource.

[0098] 17. The computing device according to any one of aspects 10 to 16, wherein preparing the 64-bit memory access command further includes associating a 64-bit virtual address with the first command, wherein the 64-bit memory access command includes the 64-bit virtual address and the first command.

[0099] 18. The computing device according to any one of aspects 10 to 17, wherein the reservation of the first memory address range and the reservation of the second memory address range are performed by the GPU driver of the 64-bit core.

[0100] 19. A computing device configured to access a secure memory range, the computing device comprising: means for reserving a first memory address range within a 32-bit address range for non-secure memory; means for reserving a second memory address range within a 64-bit address range and outside the 32-bit address range for secure memory; and means for receiving a first command from a 32-bit application for accessing the secure memory;

[0101] Components for preparing a 64-bit memory access command based on the first command; components for transmitting the 64-bit memory access command to a graphics processing unit (GPU);

[0102] And components for accessing secure memory based on the 64-bit memory access commands.

[0103] 20. The computing device according to aspect 19, further comprising: means for generating a first page table for the 32-bit application, wherein the first page table maps a first 64-bit virtual address in the 64-bit address range to a first physical address in the secure memory;

[0104] And components for generating a second page table for a second 32-bit application, wherein the second page table maps the first 64-bit virtual address to a second physical address in the secure memory.

[0105] 21. The computing device according to aspect 20, further comprising means for setting a base address value at a memory management unit (MMU) to a first address value corresponding to a location of the first page table in response to receiving the first command, wherein the means for transmitting the 64-bit memory access command to the GPU further comprises means for transmitting the 64-bit memory access command to the GPU after setting the base address value to the first address value.

[0106] 22. The computing device according to aspect 21, further comprising components for determining, based on the first page table, the first physical address corresponding to the first 64-bit virtual address, wherein

[0107] The part for accessing the secure memory based on the 64-bit memory access command

[0108] The device also includes components for accessing the secure memory using the first physical address.

[0109] 23. The computing device according to aspect 21, further comprising: means for receiving a second command from the second 32-bit application for accessing the secure memory; means for setting the base address value at the MMU to a second address value corresponding to a location of the second page table in response to receiving the second command; means for preparing a second 64-bit memory access command based on the second command; and means for transmitting the second 64-bit memory access command to the GPU after setting the base address value to the second address value.

[0110] 24. The computing device according to aspect 23 further includes components for determining whether the execution of the first command has been completed in response to receiving the second command, wherein the components for setting the base address value at the MMU to the second address value further include components for setting the base address value at the MMU to the second address value after determining that the execution of the first command has been completed.

[0111] 25. The computing device according to any one of aspects 19 to 24, wherein: the first memory address range includes a first virtual address range corresponding to a non-secure memory resource; and the second memory address range includes a second virtual address range corresponding to a secure memory resource.

[0112] 26. The computing device according to any one of aspects 19 to 25, wherein the component for preparing the 64-bit memory access command further includes a component for associating a 64-bit virtual address with the first command, wherein the 64-bit memory access command includes the 64-bit virtual address and the first command.

[0113] 27. The computing device according to any one of aspects 19 to 26, wherein the component for reserving the first memory address range and the component for reserving the second memory address range comprise a 64-bit core GPU driver.

[0114] 28. The computing device according to any one of aspects 19 to 27, wherein: the component for retention includes a 64-bit kernel; the component for receiving includes the 64-bit kernel; the component for preparation includes the 64-bit kernel; and the component for transmission includes the 64-bit kernel;

[0115] And the components used for access include the graphics processing unit (GPU).

[0116] 29. A non-transitory computer-readable medium having instructions stored thereon, the instructions, when executed by a computing device, causing the computing device to perform operations for accessing a secure memory range, the operations including: reserving a first memory address range within a 32-bit address range for non-secure memory; reserving a second memory address range within a 64-bit address range and outside the 32-bit address range for secure memory; receiving a first command from a 32-bit application for accessing the secure memory by a 64-bit kernel; preparing a 64-bit memory access command by the 64-bit kernel based on the first command; transmitting the 64-bit memory access command to a graphics processing unit (GPU) by the 64-bit kernel; and accessing the secure memory by the GPU based on the 64-bit memory access command.

[0117] 30. The non-transitory computer-readable medium according to aspect 29, wherein the operation further comprises: generating a first page table for the 32-bit application, wherein the first page table maps a first 64-bit virtual address in the 64-bit address range to a first physical address in the secure memory; and generating a second page table for a second 32-bit application, wherein the second page table maps the first 64-bit virtual address to a second physical address in the secure memory.

[0118] Additional considerations

[0119] According to this disclosure, the term "or" may be interpreted as "and / or" unless otherwise specified in the context. Additionally, while phrases such as "one or more" or "at least one" may be used for some features disclosed herein but not others, features not using such language may be interpreted as having such implied meaning unless otherwise specified in the context.

[0120] In one or more examples, the functionality described herein may be implemented in hardware, software, firmware, or any combination thereof. For example, although the term “processing unit” is used throughout this disclosure, such a processing unit may be implemented in hardware, software, firmware, or any combination thereof. If any functionality, processing unit, technique, or other module described herein is implemented in software, then the functionality, processing unit, technique, or other module described herein may be stored on or transmitted on a computer-readable medium as one or more instructions or code. A computer-readable medium may include computer data storage media and communication media, including any medium that facilitates the transfer of a computer program from one location to another. In this way, a computer-readable medium may generally correspond to (1) a non-transitory tangible computer-readable storage medium or (2) a communication medium such as a signal or carrier wave. A data storage medium may be any available medium that can be accessed by one or more computers or one or more processors to obtain instructions, code, and / or data structures for implementing the techniques described herein. By way of example, and not limitation, such a computer-readable medium may include RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage, or other magnetic storage devices. The disks and optical discs used in this document include: compact optical discs (CDs), laser optical discs, optical discs, digital versatile optical discs (DVDs), floppy disks, and Blu-ray discs. Disks typically reproduce data magnetically, while optical discs reproduce data optically using lasers. Combinations of the above should also be included within the scope of computer-readable media. Computer program products may include computer-readable media.

[0121] The code can be executed by one or more processors, such as one or more digital signal processors (DSPs), general-purpose microprocessors, application-specific integrated circuits (ASICs), arithmetic logic units (ALUs), field-programmable arrays (FPGAs), or other equivalent integrated or discrete logic circuits. Accordingly, the term "processor" as used herein can refer to any of the above-described structures or any other structure suitable for implementing the techniques described herein. Similarly, these techniques can be fully implemented in one or more circuit or logic elements.

[0122] The techniques disclosed herein can be implemented in a wide variety of devices or apparatuses, including wireless mobile phones, integrated circuits (ICs), or a set of ICs (e.g., chipsets). Various components, modules, or units are described in this disclosure to emphasize functional aspects of a device configured to perform the disclosed techniques, but they do not necessarily need to be implemented by different hardware units. Rather, as described above, various units can be combined in any hardware unit or provided by a collection of interoperable hardware units, including one or more processors as described above, along with suitable software and / or firmware.

[0123] Examples have been described. These and other examples are within the scope of the following claims.

Claims

1. A method for accessing a secure memory region, comprising: Reserve a first memory address range within a 32-bit address range for non-secure memory; Reserve a second memory address range outside the 64-bit address range and the 32-bit address range for secure memory; The 64-bit kernel receives the first command from the 32-bit application for accessing the secure memory; The 64-bit kernel prepares a 64-bit memory access command based on the first command. The 64-bit kernel transmits the 64-bit memory access commands to the graphics processing unit (GPU); as well as The GPU accesses the secure memory based on the 64-bit memory access command.

2. The method according to claim 1, further comprising: Generate a first page table for the 32-bit application, wherein the first page table maps a first 64-bit virtual address in the 64-bit address range to a first physical address in the secure memory; as well as A second page table is generated for a second 32-bit application, wherein the second page table maps the first 64-bit virtual address to a second physical address in the secure memory.

3. The method according to claim 2, further comprising: In response to receiving the first command, the GPU driver sets the base address value at the memory management unit (MMU) to a first address value corresponding to the location of the first page table, wherein transmitting the 64-bit memory access command to the GPU further includes transmitting the 64-bit memory access command to the GPU after setting the base address value to the first address value.

4. The method according to claim 3, further comprising: The MMU determines the first physical address corresponding to the first 64-bit virtual address based on the first page table, wherein accessing the secure memory based on the 64-bit memory access command further includes accessing the secure memory using the first physical address.

5. The method according to claim 3, further comprising: The 64-bit kernel receives a second command from the second 32-bit application for accessing the secure memory; In response to receiving the second command, the GPU driver sets the base address value at the MMU to a second address value corresponding to the location of the second page table; The 64-bit kernel prepares a second 64-bit memory access command based on the second command; as well as After the base address value is set to the second address value, the 64-bit kernel transmits the second 64-bit memory access command to the GPU.

6. The method according to claim 5, further comprising: In response to receiving the second command, determining whether the execution of the first command has been completed, wherein setting the base address value at the MMU to the second address value further includes: after determining that the execution of the first command has been completed, setting the base address value at the MMU to the second address value.

7. The method according to claim 1, wherein: The first memory address range includes a first virtual address range corresponding to non-secure memory resources; and The second memory address range includes a second virtual address range corresponding to secure memory resources.

8. The method of claim 1, wherein preparing the 64-bit memory access command further comprises associating a 64-bit virtual address with the first command by the 64-bit kernel, wherein the 64-bit memory access command includes the 64-bit virtual address and the first command.

9. The method of claim 1, wherein the reservation of the first memory address range and the reservation of the second memory address range are performed by the GPU driver of the 64-bit kernel.

10. A computing device configured to access a secure memory range, the computing device comprising: Memory; as well as One or more processors coupled to the memory, the one or more processors being configured to: Reserve a first memory address range within a 32-bit address range for non-secure memory; A second memory address range is reserved for secure memory, outside the 64-bit address range and the aforementioned 32-bit address range; Receive a first command from a 32-bit application for accessing the secure memory; Prepare a 64-bit memory access command based on the first command; The 64-bit memory access command is transmitted to the graphics processing unit (GPU); as well as Access the secure memory based on the 64-bit memory access command.

11. The computing device of claim 10, wherein the one or more processors are further configured to: Generate a first page table for the 32-bit application, wherein the first page table maps a first 64-bit virtual address within the 64-bit address range to a first physical address in the secure memory; and A second page table is generated for a second 32-bit application, wherein the second page table maps the first 64-bit virtual address to a second physical address in the secure memory.

12. The computing device of claim 11, wherein the one or more processors are further configured to set a base address value at a memory management unit (MMU) to a first address value corresponding to a location of the first page table in response to receiving the first command, wherein the one or more processors configured to transmit the 64-bit memory access command to the GPU are further configured to transmit the 64-bit memory access command to the GPU after setting the base address value to the first address value.

13. The computing device of claim 12, wherein the one or more processors are further configured to determine the first physical address corresponding to the first 64-bit virtual address based on the first page table, wherein the one or more processors configured to access the secure memory based on the 64-bit memory access command are further configured to use the first physical address to access the secure memory.

14. The computing device of claim 12, wherein the one or more processors are further configured to: Receive a second command from the second 32-bit application for accessing the secure memory; In response to the second command, the base address value at the MMU is set to a second address value corresponding to the location of the second page table; Prepare a second 64-bit memory access command based on the second command; as well as After setting the base address value to the second address value, the second 64-bit memory access command is transmitted to the GPU.

15. The computing device of claim 14, wherein the one or more processors are further configured to: determine whether the execution of the first command has been completed in response to receiving the second command, wherein the one or more processors configured to set the base address value at the MMU to the second address value are further configured to set the base address value at the MMU to the second address value after determining that the execution of the first command has been completed.

16. The computing device according to claim 10, wherein: The first memory address range includes a first virtual address range corresponding to non-secure memory resources; and The second memory address range includes a second virtual address range corresponding to secure memory resources.

17. The computing device of claim 10, wherein preparing the 64-bit memory access command further includes associating a 64-bit virtual address with the first command, wherein the 64-bit memory access command includes the 64-bit virtual address and the first command.

18. The computing device of claim 10, wherein reserving the first memory address range and reserving the second memory address range are performed by a GPU driver with eight 64-bit cores.

19. A computing device configured to access a secure memory range, the computing device comprising: A component used to reserve a first memory address range within a 32-bit address range for non-secure memory; A component for reserving a second memory address range outside the 64-bit address range and the 32-bit address range for secure memory; A component for receiving a first command from a 32-bit application for accessing the secure memory; A component for preparing a 64-bit memory access command based on the first command; A component used to transmit the 64-bit memory access commands to the graphics processing unit (GPU); as well as A component for accessing the secure memory based on the 64-bit memory access command.

20. The computing device of claim 19, further comprising: Components for generating a first page table for the 32-bit application, wherein the first page table maps a first 64-bit virtual address in the 64-bit address range to a first physical address in the secure memory; as well as The component is used to generate a second page table for a second 32-bit application, wherein the second page table maps the first 64-bit virtual address to a second physical address in the secure memory.

21. The computing device of claim 20, further comprising means for setting a base address value at a memory management unit (MMU) to a first address value corresponding to a location of the first page table in response to receiving the first command, wherein the means for transmitting the 64-bit memory access command to the GPU further comprises means for transmitting the 64-bit memory access command to the GPU after setting the base address value to the first address value.

22. The computing device of claim 21, further comprising means for determining the first physical address corresponding to the first 64-bit virtual address based on the first page table, wherein the means for accessing the secure memory based on the 64-bit memory access command further comprises means for accessing the secure memory using the first physical address.

23. The computing device of claim 21, further comprising: A component for receiving a second command from the second 32-bit application for accessing the secure memory; A component for setting the base address value at the MMU to a second address value corresponding to the location of the second page table in response to receiving the second command; Components for preparing a second 64-bit memory access command based on the second command; as well as A component for transmitting the second 64-bit memory access command to the GPU after the base address value is set to the second address value.

24. The computing device of claim 23, further comprising means for determining whether the execution of the first command has been completed in response to receiving the second command, wherein the means for setting the base address value at the MMU to the second address value further comprises means for setting the base address value at the MMU to the second address value after determining that the execution of the first command has been completed.

25. The computing device according to claim 19, wherein: The first memory address range includes a first virtual address range corresponding to non-secure memory resources; and The second memory address range includes a second virtual address range corresponding to secure memory resources.

26. The computing device of claim 19, wherein the component for preparing the 64-bit memory access command further comprises a component for associating a 64-bit virtual address with the first command, wherein the 64-bit memory access command includes the 64-bit virtual address and the first command.

27. The computing device of claim 19, wherein the component for reserving the first memory address range and the component for reserving the second memory address range comprise a 64-bit core GPU driver.

28. The computing device according to claim 19, wherein: The components reserved include a 64-bit kernel; The component used for receiving includes the 64-bit core; The components used for preparation include the 64-bit kernel; The components used for transmission include the 64-bit core; and The components available for access include the graphics processing unit (GPU).

29. A non-transitory computer-readable medium having instructions stored thereon, the instructions, when executed by a computing device, causing the computing device to perform operations for accessing a secure memory region, the operations including: Reserve a first memory address range within a 32-bit address range for non-secure memory; Reserve a second memory address range outside the 64-bit address range and the 32-bit address range for secure memory; The 64-bit kernel receives the first command from the 32-bit application for accessing the secure memory; The 64-bit kernel prepares a 64-bit memory access command based on the first command. The 64-bit kernel transmits the 64-bit memory access commands to the graphics processing unit (GPU); as well as The GPU accesses the secure memory based on the 64-bit memory access command.

30. The non-transitory computer-readable medium of claim 29, wherein the operation further comprises: Generate a first page table for the 32-bit application, wherein the first page table maps a first 64-bit virtual address in the 64-bit address range to a first physical address in the secure memory; as well as A second page table is generated for a second 32-bit application, wherein the second page table maps the first 64-bit virtual address to a second physical address in the secure memory.

Images