Method for obtaining physical address in super-user mode and corresponding processor

Abstract

The application provides a method for obtaining a physical address in a superuser mode and a corresponding processor supporting the method. The scheme writes a virtual address to be converted into a register available to the superuser mode, reads the virtual address from the register in the machine mode in response to detecting a state change of the register, obtains a physical address corresponding to the virtual address by querying a page table, and writes the physical address into the register, so as to obtain the corresponding physical address in the superuser mode by reading the register. The scheme enables the RISC-V architecture superuser mode to quickly complete the conversion of the virtual address to the physical address, improves the address conversion efficiency, and reduces the complexity of software programming.

Description

Technical Field

[0001] This application relates to memory access management in processors, and more particularly to methods for obtaining physical addresses in different operating modes of a processor and corresponding processors that support such methods. Background Technology

[0002] The statements in this section are merely to provide background information related to the technical solutions of this application to aid understanding, and do not necessarily constitute prior art for the technical solutions of this application.

[0003] RISC-V architecture-based processors typically have three operating modes: User mode (U mode), Supervisor mode (S mode), and Machine mode (M mode). M mode has the highest privilege level, followed by S mode, and U mode has the lowest. Hardware threads running in M ​​mode have full access to low-level functions necessary for system startup and configuration, such as memory and I / O. S mode provides a page-based virtual memory system, dividing memory into fixed-size pages for address translation and memory content protection. S mode is designed to support operating systems such as Linux and Windows, and trusted execution environment software stacks such as OP-TEE. U mode is suitable for running specific applications.

[0004] Software typically runs in both normal user mode and superuser mode using virtual addresses, while using physical addresses in machine mode. However, for software stacks with high security requirements, such as OP-TEE, it's sometimes necessary to translate virtual addresses into physical addresses in superuser mode. For example, the OP-TEE software stack sometimes uses physical addresses to perform security checks; sometimes it needs to remap virtual addresses to physical addresses to prevent data movement between user and kernel modes; and sometimes the kernel needs to map the address space of one process to the address space of another to share data between different processes. Currently, the OP-TEE software stack relies on software table lookups, often requiring multiple lookups and address translations to obtain the physical address, resulting in overall low efficiency.

[0005] It should be noted that the above content is only used to help understand the technical solution of this application and should not be used as a basis for evaluating the prior art of this application. Summary of the Invention

[0006] To address the aforementioned issues, this application provides a solution for quickly and efficiently obtaining physical addresses in superuser mode.

[0007] According to a first aspect of the embodiments of this application, a method for obtaining a physical address in superuser mode is provided, comprising: writing a virtual address to be converted into a register available to superuser mode in superuser mode; in response to detecting a state change of the register, reading the virtual address from the register in machine mode, obtaining the physical address corresponding to the virtual address by querying a page table, and writing it into the register; and obtaining the physical address corresponding to the virtual address by reading the register in superuser mode. The register may further include a status flag bit for indicating whether it currently stores a virtual address or a physical address.

[0008] In this embodiment, by providing a register shared by superuser mode and machine mode, and by placing all page table lookup operations in machine mode, the physical address corresponding to the virtual address can be quickly obtained in superuser mode. This overcomes the performance limitations of pure software page table lookup in superuser mode, not only improving the efficiency of address translation but also reducing the complexity of software programming.

[0009] In some embodiments, the method may further include: storing the physical address corresponding to the virtual address obtained by querying a page table and the virtual address in a first fast address translation table in machine mode. Thus, when reading the virtual address from the register in machine mode in response to a detected change in the register's state, the physical address corresponding to the virtual address to be translated is first searched in the first fast address translation table; if not found, the physical address corresponding to the virtual address is obtained by querying the page table.

[0010] In the above embodiments, a first fast address translation table is introduced to store the previous address translation history. If the translation of the corresponding virtual address has been performed before, the physical address corresponding to the virtual address can be quickly located in this table. This avoids the subsequent process of traversing multiple levels of page tables, thereby further improving the speed and efficiency of address translation.

[0011] In some embodiments, the method may further include: storing the physical address corresponding to the virtual address, obtained by reading the register, and the virtual address in a second fast address translation table in superuser mode. Thus, in superuser mode, in response to a request to translate a virtual address into a physical address, the method searches the second fast address translation table for the physical address corresponding to the virtual address to be translated. If not found, the virtual address to be translated is written as a parameter into the register, and the physical address corresponding to the virtual address is obtained by reading the register.

[0012] In the above embodiments, a second fast address translation table is introduced in the super user mode to store the previous address translation history. If the translation of the corresponding virtual address has been performed before, the physical address corresponding to the virtual address can be quickly located in the super user mode through this table. This avoids the subsequent process of reading and writing registers and traversing multiple levels of page tables, thereby further improving the speed and efficiency of address translation.

[0013] According to a second aspect of the embodiments of this application, a processor is provided, having at least a machine mode and a superuser mode, and including at least an address translation module operating in machine mode and a register available in superuser mode, wherein the register is used to store virtual addresses and physical addresses; and wherein the address translation module is configured to: in response to detecting a state change of the register, read the virtual address from the register, obtain the physical address corresponding to the virtual address by querying a page table, and write it into the register. The register may further include a status flag bit for indicating whether it currently stores a virtual address or a physical address.

[0014] In some embodiments, the address translation module may also be configured to: store the physical address corresponding to the virtual address obtained by querying the page table and the virtual address in a first fast address translation table; and after reading the virtual address from the register in response to detecting a change in the state of the register, first search for the physical address corresponding to the virtual address to be translated in the first fast address translation table; if not found, obtain the physical address corresponding to the virtual address by querying the page table.

[0015] According to a third aspect of the present application, a computer-readable storage medium is provided having computer instructions stored thereon, which, when executed by a processor, implement the method described according to the first aspect of the present application.

[0016] In the existing superuser mode that only uses virtual addresses, the process of converting virtual addresses to physical addresses based on multi-level page tables requires remapping the physical addresses obtained from each level of page table lookup back to virtual addresses before proceeding to the next level. Therefore, frequent address mapping operations are necessary before reaching the leaf nodes of the page tables. Furthermore, the software needs to maintain additional direct mappings between physical and virtual addresses to easily map physical addresses retrieved from each level of page tables to their corresponding virtual addresses. Thus, this method of simply converting virtual addresses to physical addresses via software table lookups in the superuser mode is inefficient overall and increases software programming complexity.

[0017] In the embodiments of this application, by providing a register shared by superuser mode and machine mode, and by performing all page table traversal operations in machine mode, the virtual address to physical address translation can be completed quickly in superuser mode. This not only improves the efficiency of address translation but also reduces the complexity of software programming. Moreover, this embodiment only requires expanding one register, thus saving hardware resources.

[0018] Unlike the existing superuser mode that uses virtual addresses, threads running in machine mode use physical addresses. Therefore, unlike the software lookup operations mentioned above that require mapping the physical addresses obtained from each level of page table lookup back to virtual addresses, the results of each level of page table lookup can be used directly to continue the lookup at the next level. This avoids the frequent address mapping operations during pure software traversal of page tables, thus enabling a much faster conversion between virtual and physical addresses.

[0019] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0020] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application. It is obvious that the drawings described below are merely some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort. In the drawings:

[0021] Figure 1 This is a flowchart illustrating a method for quickly obtaining a physical address in superuser mode according to an embodiment of this application.

[0022] Figure 2 This is a schematic diagram of the module structure of a processor according to an embodiment of this application;

[0023] Figure 3 This is a schematic diagram illustrating the process of a processor performing address translation applicable to the method according to an embodiment of this application. Detailed Implementation

[0024] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description, in conjunction with the accompanying drawings and specific embodiments, further illustrates this application. It should be understood that the described embodiments are only a part of the embodiments of this application, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0025] Furthermore, the described features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. Numerous specific details are provided in the following description to give a thorough understanding of embodiments of this application. However, those skilled in the art will recognize that the technical solutions of this application can be practiced without one or more of the specific details, or other methods, components, apparatuses, steps, etc., can be employed. In other instances, well-known methods, apparatuses, implementations, or operations are not shown or described in detail to avoid obscuring various aspects of this application.

[0026] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0027] The flowcharts shown in the accompanying drawings are merely illustrative and do not necessarily include all content and operations / steps, nor do they necessarily have to be performed in the described order. For example, some operations / steps can be broken down, while others can be combined or partially combined; therefore, the actual execution order may change depending on the specific circumstances.

[0028] RISC-V architecture-based processors typically have three operating modes: User mode (U mode), Supervisor mode (S mode), and Machine mode (M mode). M mode has the highest privilege level, followed by S mode, and U mode has the lowest. Hardware threads running in M ​​mode have full access to low-level functions necessary for system startup and configuration, such as memory and I / O. S mode provides a page-based virtual memory system, dividing memory into fixed-size pages for address translation and memory content protection. U mode is suitable for running specific applications.

[0029] In RISC-V architecture-based processors, every processor thread must run in one of three modes: normal user mode, superuser mode, or machine mode. The reason for distinguishing these modes is to provide protection for different software stack components. If a thread attempts to perform an operation that is not permitted in the current mode, an exception will occur. Machine mode can intercept interrupts and exceptions from any S / U mode environment. Superuser mode supports the operation of operating systems such as Linux and Windows, and trusted execution environment software stacks such as OP-TEE.

[0030] S-mode provides a page-based virtual memory system that divides memory into fixed-size pages for address translation and memory content protection. The addresses used in both S-mode and U-mode are virtual addresses; to access physical memory, they must be translated into actual physical addresses. In the current RISC-V specification, this is achieved by traversing a multi-level page table stored in a tree structure, where leaf nodes indicate whether a page has been mapped to a physical page.

[0031] Page tables are used to store the mapping relationship between virtual addresses and physical addresses. The number of levels in the page table depends on the virtual address space supported by the system, memory access performance requirements, etc., and can include two-level, three-level, four-level, and so on. Taking a 32-bit virtual address and its corresponding three-level page table as an example: This three-level page table includes a page directory, page tables, and page table entries; the virtual address is divided into three parts: page directory index, page table index, and page offset. Bits 22 to 31 (the highest 10 bits) of the virtual address indicate the index in the page directory; bits 12 to 21 indicate the index in the page table; bits 0 to 11 (the lowest 12 bits) indicate the page offset. When it's necessary to translate such a virtual address into a physical address, the process begins at the root of the page directory, locating the physical page containing the page directory. Then, using bits 22 to 31 of the virtual address as an index, the corresponding page directory entry (PDE) is found. The PDE contains the physical address of the page table corresponding to this virtual address. With the physical address of the page table, bits 12 to 21 of the virtual address are used as an index to find the corresponding page table entry (PTE). This page table entry contains the physical address of the physical page corresponding to this virtual address. Finally, the lowest 12 bits of the virtual address, representing the page offset, are added to the physical address of the physical page to obtain the physical address corresponding to the virtual address, allowing the retrieval of the corresponding data or instruction. A four-level page table, consisting of the Page Global Directory (PGD), Page Upper Directory (PUD), Page Middle Directory (PMD), and Page Table Entry (PTE), follows a similar process, traversing each level from the root PGD. For ease of description, the following explanation uses a three-level page table as an example, but it should be understood that the embodiments described herein are applicable to various multi-level page table systems.

[0032] In a multi-level page table system, each level of page table can be regarded as a translation from "virtual address" to "physical address". However, the "virtual address" here is a subset of the bit fields of the virtual address to be translated. Except for the last level page table PTE, which directly points to the physical page, the "physical address" in other levels of page tables points to the starting address of the corresponding next level page table.

[0033] Software typically runs in both normal user mode and superuser mode using virtual addresses, while it uses physical addresses in machine mode. However, for software stacks with high security requirements, such as OP-TEE, Trusty, and SierraTEE, it is sometimes necessary to translate virtual addresses into physical addresses in superuser mode. For example, the OP-TEE software stack sometimes needs to use physical addresses to perform security checks during execution. Another example is in Trusted Execution Environments (TEEs). To meet higher efficiency requirements, device drivers are developed, integrated, and managed as secure applications running within the TEE. The memory for such drivers is dynamically allocated in S mode, resulting in virtual addresses, while the drivers require physical addresses. In this case, it is also necessary to translate virtual addresses into physical addresses in S mode.

[0034] The following example uses OP-TEE (an open-source version of the Trusted Execution Environment (TEE) operating system) to illustrate the process of converting virtual addresses to physical addresses in the existing S-mode. Currently, the OP-TEE software stack traverses level by level using software lookups until it reaches the leaf entries. As mentioned above, in multi-level page tables, each level converts from "virtual address" to "physical address." Except for the last level page table (PTE), which directly points to the physical page, other levels of page tables obtain "physical addresses" pointing to the starting address of the corresponding next-level page table. However, since OP-TEE runs in S-mode and can only use virtual addresses, the physical addresses obtained from each level of page table lookup operation need to be converted back to virtual addresses before continuing to the next level. Therefore, this software lookup method requires multiple lookups and address conversion operations before reaching the leaf node of the page table; moreover, it requires additional software maintenance of a direct mapping between physical and virtual addresses to easily convert the physical addresses retrieved from each level of page table to virtual addresses. Therefore, in this superuser mode, simply converting virtual addresses to physical addresses through software table lookups is inefficient overall.

[0035] Figure 1A flowchart illustrating a method for quickly obtaining a physical address in superuser mode according to an embodiment of this application is shown. The method mainly includes: Step S1: In superuser mode, writing the virtual address to be translated into a designated register available to superuser mode; Step S2: In machine mode, in response to detecting a state change in the designated register, reading the virtual address from the register, obtaining the physical address corresponding to the read virtual address according to the page table, and writing it into the designated register; Step S3: In superuser mode, obtaining the physical address corresponding to the virtual address to be translated by reading the designated register. In this embodiment, the page table lookup operation during address translation is devolved to machine mode, avoiding the limitation of pure software table lookup in superuser mode mentioned above, enabling fast translation from virtual address to physical address in superuser mode, and improving the efficiency of address translation.

[0036] More specifically, in step S1, the virtual address to be translated is written into a designated register available to superuser mode in superuser mode. In RISC-V architecture-based processors, corresponding available registers can be set for different modes; higher-privilege modes can access registers of lower-privilege modes. For example, all registers available to superuser mode can be accessed in machine mode, but superuser mode does not have permission to access registers in machine mode without permission. In this embodiment, a designated register available to superuser mode is set for virtual address and physical address translation. This designated register can be implemented using the standard Control and Status Register (CSR) of the RISC-V architecture processor. The standard RISC-V architecture has up to 4,096 CSRs, and additional CSRs can be added according to the specification. Therefore, a CSR register can be extended as a dedicated register for virtual address and physical address translation in superuser mode; this designated register is referred to below as the Address Translation Register (SVAT). When address translation is required in superuser mode, the virtual address to be translated can be written into the register as a parameter of an access register instruction. For example, the instruction to write a virtual address as parameter r0 to the SVAT register can be used: `csrw svat r0`, where `csrw` is the instruction to write to the register. Similarly, in superuser mode, the translated physical address can be obtained by reading the SVAT register. For example, the instruction to read the physical address stored in the SVAT register into parameter r1 can be used: `csrr r1 svat`, where `csrr` is the instruction to read from the register.

[0037] In one embodiment, the Address Translation Register (SVAT) may also include a status flag bit to indicate whether it currently stores a virtual address or a physical address. When the contents of the register change, the corresponding status flag bit also needs to be changed accordingly.

[0038] In another embodiment, two CSR registers can be used for the translation between virtual and physical addresses in superuser mode. One register (e.g., svat1) stores the virtual address to be translated, and the other register (e.g., svat2) stores the physical address corresponding to that virtual address. When address translation is needed in superuser mode, the virtual address to be translated can be written to register svat1; and the translated physical address can be obtained by reading register svat2. Although this approach is simpler in software design, it consumes more hardware resources than the approach described above which uses only one address translation register.

[0039] Continue to refer to Figure 1 In step S2, in response to detecting a change in the state of the address translation register (ATC), a virtual address is read from the ATC in machine mode, and the physical address corresponding to the read virtual address is obtained according to the page table and written to the ATC. In RISC-V architecture-based processors, machine mode is a high-privilege mode, where registers available to superuser mode can be accessed. In one embodiment, as the virtual address to be translated is written to the ATC in superuser mode, a change in the state of the ATC can be detected in machine mode by comparing whether the contents stored in the ATC have changed. For example, if the current content read from the ATC is different from the previously written content, the read content is used as the virtual address. In some embodiments where the ATC includes a status flag, a change in the state of the ATC can be identified by detecting the status flag. If the status flag of the ATC indicates that a virtual address is currently stored, the virtual address is read from the register.

[0040] After obtaining the virtual address to be translated from the address translation register, the starting address (i.e., root address) of the page table can be obtained by reading the page table base address register. Then, the physical address corresponding to the virtual address to be translated can be obtained by querying the page table. As mentioned above, in a multi-level page table, except for the last level which directly points to the physical page, querying each level of the page table yields a "physical address" pointing to the starting address of the corresponding next-level page table. However, unlike the superuser mode which only uses virtual addresses, threads running in machine mode use physical addresses. Therefore, it is not necessary to remap the physical address obtained from each level of page table lookup operation to a virtual address as mentioned above. Instead, the results of each level of page table lookup operation can be directly used to continue the next level of lookup. This avoids the frequent address mapping operations during pure software traversal of the page table.

[0041] After obtaining the physical address corresponding to the virtual address to be translated by querying the page table in machine mode, the obtained physical address can be written to the address translation register so that the physical address can also be obtained in superuser mode. In this way, in step S3, the physical address corresponding to the virtual address to be translated can be obtained by reading the specified address translation register in superuser mode, thereby quickly completing the conversion from virtual address to physical address.

[0042] As can be seen, in the embodiments of this application, by providing a register shared by superuser mode and machine mode, and by placing all operations of traversing and querying the page table in machine mode, the conversion from virtual address to physical address can be completed quickly in superuser mode, which not only improves the efficiency of address conversion, but also reduces the complexity of software programming.

[0043] It should be understood that the process described above in conjunction with step S2 can be executed by a specific functional module (e.g., an address translation module) running in machine mode. This address translation module can be implemented as a separately programmed hardware circuit or hardware component, or as a functional module integrated into hardware components such as the control unit or memory management unit of the central processing unit. This document does not impose any limitations on this; any software, hardware, or combination of software and hardware that can support the implementation of the functions, processes, or steps described in this application is applicable.

[0044] In another embodiment, after obtaining the physical address corresponding to the virtual address to be translated by querying the page table in machine mode, the correspondence between the physical address and the virtual address can be stored in a table independent of the multi-level page table. Thus, in step S2, after responding to a detected state change in the address translation register and reading the virtual address from it, the system can first check in this table whether the correspondence between the virtual address and the physical address has already been stored. If a translation of this virtual address has already been performed, the physical address corresponding to the virtual address can be quickly located in this table, thereby avoiding the process of traversing multiple levels of page tables.

[0045] As can be seen, the solution in this embodiment can further improve the speed and efficiency of address translation. Correspondingly, such a table, independent of the page table, can also be called a fast address translation table. If no physical address corresponding to the virtual address to be translated is found in the fast address translation table, the process of obtaining the physical address corresponding to the virtual address by querying the page table, as described above in conjunction with step S2, is executed normally.

[0046] Furthermore, it should be understood that the embodiments of this application not only provide a method for quickly obtaining physical addresses in superuser mode, but also support quick acquisition of physical addresses in ordinary user mode, thereby meeting the needs of some special applications. For example, in ordinary user mode, a request to convert a virtual address to a physical address can be passed to superuser mode through means such as system calls. In superuser mode, in response to the received request to convert a virtual address to a physical address, steps S1-S3 above are executed to obtain the physical address, and the obtained physical address is returned to ordinary user mode as a response to the request.

[0047] In another embodiment, after reading the physical address corresponding to the virtual address to be translated from the address translation register in step S3, the mapping between the physical address and the virtual address can also be stored in a table different from the page table and the fast address translation table mentioned above. Thus, when address translation is needed in superuser mode or in response to a request to translate a virtual address into a physical address, the mapping between the virtual address and the physical address can be checked in this table first. If a translation of this virtual address has already been performed, the physical address corresponding to the virtual address can be quickly located in this table, thereby avoiding the subsequent process of reading and writing the address translation register and traversing multiple levels of page tables.

[0048] As can be seen, the solution in this embodiment can further improve the speed and efficiency of address translation. Accordingly, the table maintained in this superuser mode in this embodiment can be called the second fast address translation table. If no physical address corresponding to the virtual address to be translated is found in the second fast address translation table, then steps S1-S3 above are executed normally to obtain the physical address.

[0049] Figure 3 A functional architecture diagram of a processor supporting fast physical address acquisition in superuser mode is provided in another embodiment of this application. The processor has at least two operating modes: superuser mode and machine mode. The processor includes at least an address translation register available in superuser mode and an address translation module operating in machine mode. Figure 3 As shown, operating systems such as Linux and Windows, and trusted execution environment software stacks such as OP-TEE, run as system software modules in the processor's superuser mode; the memory management unit runs in machine mode, which includes an address translation module; and the page table base address register stores the starting physical address of the page directory table. It should be understood that, although in Figure 3 The address translation module is described as a functional module within the memory management unit, but it can also be a separately programmable hardware circuit or component located outside the memory management unit, or it can be a functional module integrated into the processor's control unit. This document does not impose any restrictions on the specific implementation of the address translation module; any software, hardware, or combination of software and hardware that can support the implementation of the functions, processes, or steps described in this application is applicable.

[0050] As mentioned above, this address translation register can be accessed by system software modules running in superuser mode. It is used to store the virtual address to be translated and the translated physical address. The register may also include status bits to indicate whether it is currently storing a virtual address or a physical address. When a system software module needs to perform address translation in superuser mode, it can use the virtual address to be translated as a parameter of a register access instruction to write the virtual address into the register.

[0051] In this embodiment, the address translation module is configured to read the virtual address to be translated from the address translation register, obtain the physical address corresponding to the virtual address by querying the page table in the memory unit, and write it into the address translation register.

[0052] Figure 3 This illustrates an example process where the address translation module in the processor performs a translation from a virtual address to a physical address. For example... Figure 3As shown, after obtaining the virtual address to be translated from the address translation register, the address translation module obtains the starting physical address (i.e., root address) of the page directory table by reading the page table base address register, finds the physical page where the page directory is located, and then finds the corresponding page directory entry (PDE) based on the page directory index of the virtual address. This entry records the starting physical address of the page table corresponding to this virtual address. With the physical address of the page table, the module finds the corresponding page table entry (PTE) based on the page table index of the virtual address. This entry contains the starting physical address of the physical page corresponding to this virtual address. Finally, the page offset is added to the starting physical address of the physical page to obtain the physical address corresponding to the virtual address. It can be seen that the address translation module running in machine mode directly uses the physical address obtained from each level of page table lookup operation for the next level of lookup. This avoids the frequent address mapping operations during pure software traversal of the page table in superuser mode, thus improving the speed and efficiency of address translation.

[0053] In another embodiment, the processor may further include a cache corresponding to the address translation module, which stores a fast address translation table (QTP). The address translation module, after obtaining the physical address corresponding to the virtual address by querying the page table, stores the physical address and the corresponding virtual address in this QTP. Thus, when the address translation module reads the virtual address to be translated from the address translation register in response to a detected state change, it can first search for the physical address corresponding to the virtual address in the QTP. If a translation of this virtual address has already been performed, the physical address corresponding to the virtual address can be quickly located in the QTP, thereby avoiding the subsequent traversal of multiple page tables and further improving the speed and efficiency of address translation. Conversely, if no physical address corresponding to the virtual address to be translated is found in the QTP, the physical address corresponding to the virtual address is obtained by querying the page table.

[0054] It should be noted that although the embodiments of this application are described above using the RISC-V architecture processor working mode as an example, those skilled in the art should understand that the above embodiments are also applicable to ARM architecture processors.

[0055] In yet another embodiment of this application, a computer-readable storage medium is provided, on which a computer program is stored, which, when executed by a processor, implements the above-described combination. Figure 1 The method described herein. In this application, a computer-readable storage medium may be any tangible medium that contains or stores a program that may be used by or in conjunction with an instruction execution system, apparatus, or device.

[0056] It should be understood that the steps, processes, or methods mentioned in this document, as well as modules and their functions such as address translation modules, can achieve the same functionality, not only through purely computer-readable program code, but also by logically programming the corresponding functional modules, processes, or steps to make these modules function as logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers (PLCs), and embedded microcontrollers. Therefore, such modules or devices can be considered hardware components, and the sub-modules within them that implement various functions can also be considered internal structures of the hardware component. Alternatively, the devices used to implement various functions can be considered as both software modules implementing the relevant process or method steps and structures within a hardware component.

[0057] References to "various embodiments," "some embodiments," "one embodiment," or "embodiment," etc., in this specification refer to a specific feature, structure, or property described in connection with the said embodiment, included in at least one embodiment. Therefore, the appearance of the phrases "in various embodiments," "in some embodiments," "in one embodiment," or "in an embodiment," etc., throughout this specification does not necessarily refer to the same embodiment. Furthermore, specific features, structures, or properties can be combined in any suitable manner in one or more embodiments. Therefore, a specific feature, structure, or property shown or described in connection with one embodiment can be combined, in whole or in part, with features, structures, or properties of one or more other embodiments without limitation, provided that the combination is not illogical or inoperable.

[0058] The terms "comprising," "having," and similar expressions used in this specification are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to such processes, methods, products, or apparatus. "A" or "an" does not exclude multiple instances. Furthermore, the elements in the accompanying drawings are for illustrative purposes only and are not drawn to scale.

[0059] Although this application has been described through the above embodiments, this application is not limited to the embodiments described herein, and includes various changes and variations without departing from the scope of this application.

Claims

1. A method for obtaining a physical address in superuser mode, comprising: In superuser mode, the virtual address to be translated is written into a register available to superuser mode, wherein the register also includes a status flag bit to indicate whether it currently stores a virtual address or a physical address; In machine mode, the physical address corresponding to the virtual address obtained by querying the page table, as well as the virtual address, are stored in the first fast address translation table; In response to the detection of a state change in the register, when reading the virtual address from the register in machine mode, the physical address corresponding to the virtual address to be translated is first searched in the first fast address translation table. If not found, the physical address corresponding to the virtual address is obtained by querying the page table and written into the register. The state change refers to the change in the content stored in the register. In superuser mode, the physical address corresponding to the virtual address is obtained by reading the register.

2. The method according to any one of claims 1, further comprising: In superuser mode, the physical address corresponding to the virtual address obtained by reading the register, as well as the virtual address, are stored in the second fast address translation table.

3. The method according to claim 2, wherein: In superuser mode, in response to a request to translate a virtual address into a physical address, the physical address corresponding to the virtual address to be translated is searched in the second fast address translation table. If not found, the virtual address to be translated is written into the register as a parameter, and the physical address corresponding to the virtual address is obtained by reading the register.

4. A processor having at least a machine mode and a superuser mode, and including at least an address translation module operating in machine mode and a register available in superuser mode, wherein the register is used to store virtual addresses and physical addresses, and the register further includes a status flag bit for indicating whether it currently stores a virtual address or a physical address; and The address translation module is configured as follows: The physical address corresponding to the virtual address obtained by querying the page table, and the virtual address are stored in the first fast address translation table; In response to detecting a state change in the register, when reading the virtual address from the register, the system first searches for the physical address corresponding to the virtual address to be translated in the first fast address translation table; if not found, it retrieves the physical address corresponding to the virtual address by querying the page table and writes it into the register. The state change refers to the change in the content stored in the register.

5. A computer-readable storage medium having stored thereon computer instructions that, when executed by a processor, implement the method as described in any one of claims 1-3.

Images