Verification Method and Device for Page Fault Exception Caused by Modification of Processor Page Table

Abstract

The present application provides a verification method and device for a page fault exception caused by a processor page table modification, which relates to the technical field of processors. The method includes: obtaining a store instruction of the processor to be verified, where the store instruction is used to modify the page table of the processor to be verified; performing a write trace on the store instruction to determine the modification result of the page table; based on the store instruction, simulating the modification result of the page table to obtain a simulation result; comparing the modification result with the simulation result to obtain a verification result. This solves the bottleneck that in simulation verification, due to the lack of processor microarchitecture information in the simulator, the processor behavior cannot be directly verified relying on the simulator. It can track the synchronization situation of the processor's page table update and achieve synchronous verification of the processor through the simulator.

Description

Technical Field

[0001] This application relates to the technical field of processors, and in particular, to a method and device for verifying a page fault exception caused by a page table modification of a processor. Background Art

[0002] The processor introduces a page fault because the virtual memory introduced by the operating system kernel makes it impossible for the program to directly access the physical memory, and when accessing the virtual memory, it needs to be completed by the processor modifying the page table.

[0003] Simulators are all behavioral simulations and do not involve various queues. Therefore, the execution result of the store instruction of the simulator is immediately visible for the modification of the page table. However, some results of the processor to be verified are not visible for the modification of the page table.

[0004] Therefore, without using synchronization instructions, it will cause the simulation of the simulator and the emulation of the processor to be verified to be unable to align and analyze the behavior of the page fault exception caused by the page table modification of the processor, resulting in difficulties in result comparison. Summary of the Invention

[0005] This application aims to solve at least one of the technical problems in the related art to some extent.

[0006] To this end, the first object of this application is to propose a method for verifying a page fault exception caused by a page table modification of a processor to implement the verification of the processor behavior by the simulator.

[0007] The second object of this application is to propose a device for verifying a page fault exception caused by a page table modification of a processor.

[0008] The third object of this application is to propose an electronic device.

[0009] The fourth object of this application is to propose a computer-readable storage medium.

[0010] The fifth object of this application is to propose a computer program product.

[0011] To achieve the above object, an embodiment of the first aspect of this application proposes a method for verifying a page fault exception caused by a page table modification of a processor, including:

[0012] Obtain the store instruction of the processor to be verified, where the store instruction is used to modify the page table of the processor to be verified;

[0013] Perform a write trace on the store instruction to determine the modification result of the page table;

[0014] Based on the store instruction, simulate the modification result of the page table to obtain a simulation result;

[0015] Compare the modified result with the simulation result to obtain a verification result.

[0016] To achieve the above object, an embodiment of the second aspect of the present application provides a verification device for a page fault exception caused by a processor page table modification, including:

[0017] An acquisition module, configured to acquire a store instruction of a processor to be verified, where the store instruction is used to modify the page table of the processor to be verified;

[0018] A write trace module, configured to perform a write trace on the store instruction to determine the modification result of the page table;

[0019] A simulation module, configured to simulate the modification result of the page table based on the store instruction to obtain a simulation result;

[0020] A verification module, configured to compare the modified result with the simulation result to obtain a verification result.

[0021] To achieve the above object, an embodiment of the third aspect of the present application provides an electronic device, including: a processor, and a memory communicatively connected to the processor;

[0022] The memory stores computer execution instructions;

[0023] The processor executes the computer execution instructions stored in the memory to implement a verification method for a page fault exception caused by a processor page table modification proposed in the first aspect embodiment of the present application.

[0024] To achieve the above object, an embodiment of the fourth aspect of the present application provides a computer-readable storage medium, in which computer execution instructions are stored, and when the computer execution instructions are executed by a processor, they are used to implement a verification method for a page fault exception caused by a processor page table modification proposed in the first aspect embodiment of the present application.

[0025] To achieve the above object, an embodiment of the fifth aspect of the present application provides a computer program product, including a computer program, and when the computer program is executed by a processor, it implements a verification method for a page fault exception caused by a processor page table modification proposed in the first aspect embodiment of the present application.

[0026] The verification method and device for page fault exception caused by processor page table modification provided by this application obtain the store instruction of the processor to be verified, where the store instruction is used to modify the page table of the processor to be verified; perform write tracing on the store instruction to determine the modification result of the page table; simulate the modification result of the page table based on the store instruction to obtain a simulation result; compare the modification result with the simulation result to obtain a verification result. It solves the bottleneck that in simulation verification, due to the lack of processor microarchitecture information, the simulator cannot directly verify the processor behavior relying on the simulator, can track the synchronization situation of the processor's page table update, and realizes the synchronous verification of the processor through the simulator.

[0027] Additional aspects and advantages of this application will be given in part in the following description, become apparent in part from the following description, or be understood through the practice of this application. Brief Description of the Drawings

[0028] The above and / or additional aspects and advantages of this application will become apparent and easy to understand from the following description of the embodiments in conjunction with the drawings, where:

[0029] Figure 1 It is a schematic flowchart of a verification method for page fault exception caused by processor page table modification provided by an embodiment of this application;

[0030] Figure 2 It is a schematic flowchart of another verification method for page fault exception caused by processor page table modification provided by an embodiment of this application;

[0031] Figure 3 It is a schematic process diagram of a store instruction provided by an embodiment of this application;

[0032] Figure 4 It is a schematic diagram showing a dirty bit provided by an embodiment of this application;

[0033] Figure 5 It is a schematic diagram showing the setting of a dirty bit provided by an embodiment of this application;

[0034] Figure 6 It is a schematic diagram showing the clearing of a dirty bit provided by an embodiment of this application;

[0035] Figure 7 It is a schematic flowchart of another verification method for page fault exception caused by processor page table modification provided by an embodiment of this application;

[0036] Figure 8 It is a schematic structural diagram of a verification device for page fault exception caused by processor page table modification provided by an embodiment of this application. Detailed Embodiments

[0037] Embodiments of the present application will be described in detail below. Examples of the embodiments are shown in the accompanying drawings, where like or similar reference numerals denote like or similar elements or elements having like or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and are intended to explain the present application, and should not be construed as limiting the present application.

[0038] The verification method and apparatus for page fault exception caused by processor page table modification according to the embodiments of the present application will be described below with reference to the accompanying drawings.

[0039] Figure 1 It is a schematic flowchart of a verification method for page fault exception caused by processor page table modification provided by the embodiments of the present application.

[0040] The simulation verification includes the verification of running a specific application and random verification. In the simulation verification, the simulator gives the correct execution result. The processor to be verified simulates the generation of instruction submissions, and the simulator also executes the same instruction submissions. By comparing the execution result of the simulation verification of the processor to be verified with the execution result of the reference design given by the simulator, the correctness of the execution result of the processor to be verified is determined. The checker performs the comparison of the execution results. The execution results include data, status, etc.

[0041] Modern high-performance processor cores all adopt aggressive out-of-order execution techniques, including using a store queue, a store buffer technology for submitting store instructions, caching the submitted store instructions, allowing the store instructions to exit the out-of-order scheduling queue and the reorder buffer (ROB) as soon as possible, and waiting in the store buffer for writing to the cache (abbreviation for cache).

[0042] A page fault (also known as a page fault interrupt) is not actually a true program "exception", but rather an intentional exception that can be considered an exception triggered by hardware and corrected by software logic. The processor introduces a page fault because the virtual memory introduced by the operating system kernel makes it impossible for a program to directly access physical memory. Therefore, various situations need to be handled when accessing virtual memory, and this handling process requires a page fault to complete. The following situations may occur when accessing virtual memory: (1) The accessed address is not within the virtual address space; (2) The accessed address is within the virtual address space, but its permissions are insufficient, such as writing (W) in a region with read (R) + execute (X) permissions, or executing (X) in a region with read (R) + write (W) permissions; (3) The accessed address has not been allocated the corresponding physical memory and has no corresponding mapping; (4) The physical memory corresponding to the accessed address is no longer in memory; (5) The permissions of the mapped physical page are insufficient, etc. The handling of these situations is completed by the processor's modification of the page table.

[0043] The modification of the processor's page table is carried out through store instructions. To improve execution efficiency, the processor submits store instructions in the store queue and first stores the submitted store instructions in the store buffer of the submitted store instructions. At this time, they have not been written into the cache. When the submitted store instructions are in the store queue and the store buffer of the submitted store instructions, the store queue and the store buffer will store some data of the submitted store instructions, and these data are not visible for the modification of the page table. Only through synchronization instructions to ensure that the data in the store queue and the store buffer are written into the cache, the modification result of the store instruction on the page table will be visible. For example, RISC-V (Reduced Instruction Set Computing - Five, the fifth generation of reduced instruction set) uses the virtual memory barrier (Fence Virtual Memory) instruction sfence.vma (abbreviated as sfence) to synchronize page table updates.

[0044] Since the simulator conducts behavioral-level simulation and does not involve various queues, such as the Store Queue for store instructions and the Store Buffer for submitting store instructions to write to the buffer at the processor microarchitecture level, the execution result of the store instruction in the simulator is immediately visible for the modification of the page table. However, for a part of the Store results stored in the Store Queue and Store Buffer of the processor to be verified, the modification of these results to the page table is not visible. In fact, without using synchronization instructions, whether the modification of the page table by the processor affects the address mapping is a correct behavior. However, it will cause the simulation of the simulator and the emulation of the processor to be verified to be unable to align and analyze the behavior of page fault exceptions caused by the modification of the processor's page table, resulting in difficulties in result comparison.

[0045] To address this issue, the embodiments of the present application provide a verification method for page fault exceptions caused by the modification of the processor's page table to achieve the verification of the processor's behavior by the simulator, such as Figure 1 As shown, the verification method for page fault exceptions caused by the modification of the processor's page table includes the following steps:

[0046] Step 101: Obtain the store instruction of the processor to be verified, where the store instruction is used to modify the page table of the processor to be verified.

[0047] Optionally, the store instruction is a basic instruction in the computer instruction system, used to copy data from a certain storage location (such as a register) of the computer to a specified address in the memory; the processor to be verified emulates the running of an application program or a randomly generated instruction sequence.

[0048] In the embodiments of the present application, the processor to be verified emulates the running of the store instruction and modifies the page table through the store instruction.

[0049] Step 102: Conduct a write trace on the store instruction to determine the modification result of the page table.

[0050] Optionally, by using a write trace mechanism to track and synchronize the page table update situation of the processor to be verified, the modification result of the page table can be determined.

[0051] For example, by means of dirty page tracking, determine whether the store instruction is written into the cache to achieve the write trace of the store instruction.

[0052] Optionally, through the write trace, determine whether the page table of the processor to be verified is modified or the modification status, make the modification result of the page table visible, and obtain the modification result of the page table.

[0053] Step 103: Based on the store instruction, simulate the modification result of the page table to obtain a simulation result.

[0054] It can be understood that each processor has a corresponding simulator for generating comparison results. The simulator runs the same application program as the processor to be verified or a randomly generated instruction sequence. Generally, the simulator performs behavioral simulation in a high-level language such as C, without involving the specific microarchitecture of the processor, directly calculates the execution results of the instructions, and gives the correct results of the instruction execution for comparison with the emulator.

[0055] Optionally, execute the same instruction as the store instruction through the simulator, simulate the page table modification result of the store instruction on the processor to be verified, and obtain the simulation result.

[0056] It should be noted that the execution result of the store instruction implemented through the simulator is immediately visible for the modification of the page table, that is, the simulation result is immediately visible.

[0057] Step 104, compare the modification result with the simulation result to obtain the verification result.

[0058] Optionally, the modification result and the simulation result can be compared through an inspector to determine whether the modification result obtained by writing the trace is consistent with the simulation result of the simulator, and obtain the verification result.

[0059] Among them, the verification result can be normal or abnormal.

[0060] In this embodiment, by obtaining the store instruction of the processor to be verified, where the store instruction is used to modify the page table of the processor to be verified; performing a write trace on the store instruction to determine the modification result of the page table; based on the store instruction, simulating the modification result of the page table to obtain the simulation result; comparing the modification result with the simulation result to obtain the verification result. It solves the bottleneck that in simulation verification, due to the lack of processor microarchitecture information, the simulator cannot directly verify the processor behavior relying on the simulator, can track the synchronization situation of the processor's page table update, and realizes the synchronous verification of the processor through the simulator.

[0061] This embodiment provides another verification method for a page fault exception caused by a processor page table modification. Figure 2 It is a schematic flowchart of another verification method for a page fault exception caused by a processor page table modification provided by an embodiment of the present application.

[0062] As Figure 2 shown, the verification method for a page fault exception caused by the processor page table modification may include the following steps:

[0063] Step 201, obtain the store instruction of the processor to be verified, where the store instruction is used to modify the page table of the processor to be verified.

[0064] Optionally, the store instruction is a basic instruction in the computer instruction system, used to copy data from a certain storage location (such as a register) of the computer to a specified address in the memory.

[0065] In the embodiment of the present application, as Figure 3 shown, in the store pipeline, the committed store instructions are stored in the store instruction queue and / or the committed store instruction write buffer, and are not written into the cache memory. The modification of the page table by the data stored in the store instruction queue and the committed store instruction write buffer is not visible.

[0066] Optionally, the processor to be verified modifies the page table through the store instruction.

[0067] Step 202, execute a store instruction on the page table to determine the dirty bit corresponding to the page table; track the dirty bit to determine the modification result of the page table.

[0068] Optionally, when judging whether a page fault exception is legal, it is necessary to check whether the write to the page table has been synchronized by a synchronization instruction. The dirty bit can be used to track the state of the page table in the simulator, and the dirty bit is checked when the simulator reads the page table to determine the page table state.

[0069] As an example, the dirty bit tracking can be implemented by setting the dirty bit in the memory space of the simulator.

[0070] In the embodiment of the present application, the dirty bit corresponds to a first dirty bit value and a second dirty bit value, used to distinguish the state of the dirty bit.

[0071] As an example, the first dirty bit value is 1 and the second dirty bit value is 0.

[0072] As a possible implementation manner, during initialization, all the dirty bits are set to 0. The synchronization instruction clears all the dirty bit states, that is, all the dirty bits are set to 0.

[0073] Furthermore, the position of the dirty bit is determined in byte granularity.

[0074] Taking the memory size of 128MB as an example, setting the dirty bit in byte (Byte) granularity, the size required for the dirty bit is 16MB, which has a large storage pressure on the simulator.

[0075] In the embodiment of the present application, the tracking granularity of the dirty bit is reduced, and a coarse-grained method is adopted to set a dirty bit at every preset number of byte positions.

[0076] As an example, the preset number can be 8, that is, a dirty bit is set for every 8 bytes to track the state of the page table. 8 bytes is also the maximum granularity of the store instruction. The maximum granularity of the store instruction is generally StoreDoubleword.

[0077] As shown Figure 4 in the figure, a dirty bit is set every 8 bytes in the simulated memory. The value of the dirty bit is 0, which identifies the position in the page table where the modification will definitely take effect before the synchronization instruction. A dirty bit of 1 identifies the position in the page table that has been modified but not yet synchronized by the synchronization instruction, i.e., the dirty position.

[0078] In other embodiments, it can also be set to a precise granularity or other granularities. For example, the preset number of bytes can be 2 bytes, 4 bytes, 16 bytes, etc.

[0079] It should be noted that a check is performed before the simulator sets a page fault exception.

[0080] Optionally, the position written by the store instruction is set to the first dirty bit value; in the case of performing synchronization of the store instruction, the dirty bit position is set to the second dirty bit value.

[0081] Please refer to Figure 5 , when the simulator executes the store instruction, the dirty bit at the position written by the store instruction is set to 1, that is, the value of the dirty bit at the written position is set from the initialized 0 to 1.

[0082] Furthermore, in the case where the simulator executes the synchronization instruction, all dirty bits are refreshed and cleared, that is, the dirty bits are set to 0. Please refer to Figure 6 , all dirty bits are set to 0 to achieve the clearing of the dirty bits.

[0083] By using dirty bits in the simulator, the state of the page table can be traced. The value of the dirty bit can reflect the synchronization situation of the page table. Furthermore, when the simulator reads the page table, the dirty bits are checked, and the state of the page table is determined according to the value of the dirty bit.

[0084] Step 203: Based on the store instruction, simulate the modification result of the page table to obtain a simulation result.

[0085] For the description of step 203, reference can be made to the relevant description in the foregoing embodiments, and details are not repeated in this embodiment.

[0086] Step 204: Compare the modification result with the simulation result to obtain a verification result.

[0087] Optionally, the modification result and the simulation result can be compared through an inspector to determine whether the modification result obtained through write tracing is consistent with the simulation result of the simulator emulation, so as to obtain a verification result.

[0088] Among them, the verification result can be normal or abnormal.

[0089] As a possible implementation manner, it is also possible to simulate the process of implementing the modification result for the processor to be verified and perform a comparison verification.

[0090] Optionally, obtain the simulation result of the emulator for the store instruction executed by the processor to be verified; compare the simulation result with the simulation result through the checker to obtain the verification result.

[0091] Among them, the emulator can use simulation tools such as Verilator and VCS to simulate the code of the processor.

[0092] In this embodiment, by obtaining the store instruction of the processor to be verified, where the store instruction is used to modify the page table of the processor to be verified; execute the store instruction on the page table to determine the dirty bit corresponding to the page table; track the dirty bit to determine the modification result of the page table; based on the store instruction, simulate the modification result of the page table to obtain the simulation result; compare the modification result with the simulation result to obtain the verification result. It solves the bottleneck that in simulation verification, the simulator cannot directly verify the processor behavior due to the lack of processor microarchitecture information, can track the synchronization situation of the processor's page table update, and realizes the synchronous verification of the processor through the simulator.

[0093] This embodiment provides another verification method for the page fault exception caused by the modification of the processor page table. Figure 7 It is a schematic flowchart of another verification method for the page fault exception caused by the modification of the processor page table provided by the embodiments of the present application.

[0094] As Figure 7 shown, the verification method for the page fault exception caused by the modification of the processor page table may include the following steps:

[0095] Step 701, obtain the store instruction of the processor to be verified, where the store instruction is used to modify the page table of the processor to be verified.

[0096] For the description of step 701, reference may be made to the relevant description of the foregoing embodiment, which will not be elaborated in this embodiment.

[0097] Step 702, receive the microarchitecture state of the processor to be verified, where the microarchitecture state is used to instruct the simulator to perform state adjustment; based on the microarchitecture state, determine the modification result of the page table.

[0098] Optionally, when the processor to be verified executes the store instruction to write the cache and executes the synchronization instruction, it transfers the execution information (i.e., the microarchitecture state) to the simulator.

[0099] It should be noted that in the case where there is no synchronization instruction to synchronize the write page table entry, the latest value of the page table entry may exist in the store instruction queue or the store instruction write buffer for submission, and a page fault interrupt may be triggered during address translation.

[0100] Optionally, change the simulator state at the corresponding node according to the micro-structure state; execute the store instruction if the change in the simulator state is legal.

[0101] In the embodiments of the present application, the simulator state is updated according to the state of the processor to be verified and a reminder is given. The simulator forcibly changes the simulator state at the corresponding node according to the incoming micro-structure state. Further, the simulator checks whether the forced state change is legal, and executes the store instruction after it is legal.

[0102] Co-simulation is achieved through the synchronization of the micro-structure states of the processor to be verified and the simulator.

[0103] Step 703: Based on the store instruction, simulate the modification result of the page table to obtain a simulation result.

[0104] It can be understood that each processor has a corresponding simulator (Simulator) for generating comparison results, which runs the same application program or randomly generated instruction sequence as the processor to be verified. The simulator generally performs behavioral simulation in a high-level language such as C, does not involve the specific micro-architecture of the processor, directly calculates the execution result of the instruction, and gives the correct result of the instruction execution for comparison with the emulator.

[0105] Optionally, the simulator triggers a page fault interrupt according to the micro-structure state obtained by the processor to be verified when executing the store instruction, simulates the modification result of the page table, and obtains a simulation result.

[0106] It should be noted that the simulation result is immediately visible through the simulator.

[0107] Step 704: Compare the modification result with the simulation result to obtain a verification result.

[0108] Optionally, the checker can be used to compare the modification result with the simulation result to determine whether the modification result obtained through write tracing is consistent with the simulation result of the simulator, and obtain a verification result.

[0109] Among them, the verification result can be normal or abnormal.

[0110] As a possible implementation manner, it is also possible to simulate the process of the processor to be verified to implement the modification result for comparison and verification.

[0111] Optionally, obtain the simulation result of the emulator for the processor to be verified when executing the store instruction; compare the simulation result with the simulation result through the checker to obtain a verification result.

[0112] Among them, the emulator can use simulation tools such as Verilator and VCS to simulate the code of the processor.

[0113] The embodiments of the present application can also be applicable to other situations where the alignment comparison between the processor to be verified and the simulator cannot be performed. Co-simulation is achieved through the synchronization of the microstructural states of the processor to be verified and the simulator. The microstructural state of the processor is transmitted to the simulator to synchronize the simulator and the processor.

[0114] For example, the verification of the store instructions and peripheral interrupts of the processor for the peripheral space. Since the simulator cannot simulate the behaviors of all external devices, the simulator cannot know the correct results of the store instructions mapped to the address space of the external devices. In this case, it is also impossible to align and analyze the behaviors of the processor to be verified and the simulator.

[0115] As an example, the store instruction includes the target store instruction of the external device of the processor to be verified. When the store instruction is received, the microstructural state of the processor to be verified is received and synchronized; the execution result of the target store instruction is copied.

[0116] In the embodiments of the present application, the microstructural state of the processor to be verified is transmitted to the simulator for synchronization. The memory-mapped peripheral address space is marked by the processor. When the store instruction for the peripheral space is submitted, the simulator copies the execution result of the store instruction from the processor.

[0117] Further, in the case where the simulator and the processor to be verified need to synchronize for peripheral interrupts, the interrupt information of the external device sent by the processor to be verified is received; according to the interrupt information, the interrupt of the simulator is triggered.

[0118] For example, the simulator does not know when the processor will trigger a peripheral interrupt. To solve this problem, when the peripheral interrupt is triggered, the processor sends the interrupt information of the external device to be synchronized to the simulator. When the simulator receives the interrupt information, the same interrupt will also be triggered in the simulator.

[0119] By transmitting the microstructural state of the processor to the simulator, the simulator and the processor are synchronized. The microstructural state is transmitted from the processor to the simulator, and the simulator checks the state transmitted by the processor and adjusts its own state. The execution results of the processor and the simulator are compared to achieve the co-simulation of the processor and the simulator.

[0120] In this embodiment, by obtaining the store instruction of the processor to be verified, where the store instruction is used to modify the page table of the processor to be verified; receiving the microarchitecture state of the processor to be verified, the microarchitecture state is used to instruct the simulator to perform state adjustment; determining the modification result of the page table based on the microarchitecture state; simulating the modification result of the page table based on the store instruction to obtain a simulation result; comparing the modification result with the simulation result to obtain a verification result. This solves the bottleneck that in simulation verification, due to the lack of processor microarchitecture information in the simulator, it is impossible to directly verify the processor behavior relying on the simulator, and can track the synchronization situation of the processor's page table update, and realize the synchronous verification of the processor through the simulator.

[0121] To implement the above embodiment, the present application also proposes a verification device for a page fault exception caused by a processor page table modification.

[0122] Figure 8 It is a schematic structural diagram of a verification device for a page fault exception caused by a processor page table modification provided by an embodiment of the present application.

[0123] As Figure 8 shown, the verification device 800 for a page fault exception caused by a processor page table modification includes: an acquisition module 801, a write tracking module 802, a simulation module 803, and a verification module 804.

[0124] The acquisition module 801 is configured to obtain the store instruction of the processor to be verified, where the store instruction is used to modify the page table of the processor to be verified;

[0125] The write tracking module 802 is configured to perform write tracking on the store instruction to determine the modification result of the page table;

[0126] The simulation module 803 is configured to simulate the modification result of the page table based on the store instruction to obtain a simulation result;

[0127] The verification module 804 is configured to compare the modification result with the simulation result to obtain a verification result.

[0128] Further, in a possible implementation manner of the embodiment of the present application, the write tracking module 802 is configured to:

[0129] Execute the store instruction on the page table to determine the dirty bit corresponding to the page table;

[0130] Track the dirty bit to determine the modification result of the page table.

[0131] The dirty bit corresponds to a first dirty bit value and a second dirty bit value, and the position written by the store instruction is set to the first dirty bit value;

[0132] In the case of executing the store instruction synchronously, the dirty bit position is set to the second dirty bit value.

[0133] Determine the position of the dirty bit at the byte granularity.

[0134] Receive the microarchitecture state of the processor to be verified, where the microarchitecture state is used to indicate the simulator to adjust the state.

[0135] Determine the modification result of the page table based on the microarchitecture state.

[0136] Change the simulator state at the corresponding node according to the microarchitecture state.

[0137] Execute the store instruction when the change of the simulator state is legal.

[0138] Furthermore, in a possible implementation manner of the embodiment of the present application, the verification module 804 is used for:

[0139] Obtain the simulation result of the simulator executing the store instruction on the processor to be verified.

[0140] Compare the simulation result and the simulation result through the checker to obtain the verification result.

[0141] Furthermore, in a possible implementation manner of the embodiment of the present application, the store instruction is stored in the store instruction queue and / or the store instruction write buffer for submission.

[0142] It should be noted that the foregoing explanation of the embodiment of the verification method for the page fault exception caused by the modification of the processor page table also applies to the verification device for the page fault exception caused by the modification of the processor page table in this embodiment, and will not be elaborated here.

[0143] In this embodiment, by obtaining the store instruction of the processor to be verified, where the store instruction is used to modify the page table of the processor to be verified; performing write tracking on the store instruction to determine the modification result of the page table; simulating the modification result of the page table based on the store instruction to obtain the simulation result; and comparing the modification result and the simulation result to obtain the verification result. It solves the bottleneck that the simulator in the simulation verification cannot directly verify the processor behavior due to the lack of processor microarchitecture information, can track the synchronization situation of the processor's page table update, and realizes the synchronous verification of the processor through the simulator.

[0144] To implement the above embodiment, the present application also proposes an electronic device, including: a processor, and a memory communicatively connected to the processor; the memory stores computer execution instructions; the processor executes the computer execution instructions stored in the memory to implement the verification method for the page fault exception caused by the modification of the processor page table provided in the foregoing embodiment.

[0145] To implement the above embodiments, the present application also provides a computer-readable storage medium storing computer-executable instructions, which when executed by a processor are used to implement the method for verifying a page fault exception caused by a processor page table modification provided in the foregoing embodiments.

[0146] To implement the above embodiments, the present application also provides a computer program product including a computer program, which when executed by a processor implements the method for verifying a page fault exception caused by a processor page table modification provided in the foregoing embodiments.

[0147] The collection, storage, use, processing, transmission, provision, and disclosure of user personal information involved in the present application all comply with the provisions of relevant laws and regulations and do not violate public order and good customs.

[0148] It should be noted that personal information from users should be collected for legal and reasonable purposes and not shared or sold outside of these legal uses. In addition, such collection / sharing should be carried out after obtaining the informed consent of the user, including but not limited to notifying the user to read the user agreement / user notice and sign an agreement / authorization including authorizing relevant user information before the user uses the function. In addition, any necessary steps should be taken to safeguard and protect access to such personal information data and ensure that others with access to personal information data comply with their privacy policies and procedures.

[0149] The present application is expected to provide an implementation for users to selectively block the use or access of personal information data. That is, the present application is expected to provide hardware and / or software to prevent or block access to such personal information data. Once personal information data is no longer needed, the risk can be minimized by restricting data collection and deleting the data. In addition, when applicable, personal identifiers are removed from such personal information to protect the privacy of users.

[0150] In the description of the foregoing embodiments, the descriptions with reference to the terms "one embodiment", "some embodiments", "example", "specific example", or "some examples", etc. mean that the specific features, structures, materials, or characteristics described in connection with the embodiment or example are included in at least one embodiment or example of the present application. In this specification, the schematic descriptions of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials, or characteristics described can be combined in a suitable manner in any one or more embodiments or examples. In addition, without contradiction, those skilled in the art can combine and combine the different embodiments or examples described in this specification and the features of different embodiments or examples.

[0151] In addition, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the quantity of the indicated technical features. Thus, features defined with "first" and "second" may explicitly or implicitly include at least one such feature. In the description of the present application, the meaning of "a plurality of" is at least two, such as two, three, etc., unless otherwise specifically defined.

[0152] Any process or method description represented in a flowchart or otherwise described herein may be understood to represent a module, segment, or portion of code including one or more executable instructions for implementing a customized logic function or process. The scope of the preferred embodiments of the present application includes additional implementations where functions may be executed not in the order shown or discussed, including in a substantially simultaneous manner according to the functions involved or in a reverse order, which should be understood by those skilled in the art to which the embodiments of the present application pertain.

[0153] The logic and / or steps represented in a flowchart or otherwise described herein, for example, may be considered as a sequenced list of executable instructions for implementing a logical function, and may be specifically implemented in any computer-readable medium for use by or in connection with an instruction execution system, apparatus, or device, such as a computer-based system, a system including a processor, or other systems that can fetch and execute instructions from the instruction execution system, apparatus, or device. For the purposes of this specification, a "computer-readable medium" may be any device that can contain, store, communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. More specific examples (non-exhaustive list) of the computer-readable medium include the following: an electrical connection portion with one or more wirings (electronic device), a portable computer diskette (magnetic device), a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber device, and a portable compact disc read-only memory (CDROM). Additionally, the computer-readable medium may even be paper or other suitable medium on which the program can be printed, as the program can be obtained electronically, for example, by optically scanning the paper or other medium, followed by editing, interpretation, or otherwise processing as appropriate, and then storing it in a computer memory.

[0154] It should be understood that each part of the present application can be implemented by hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented by software or firmware stored in a memory and executed by a suitable instruction execution system. For example, if implemented by hardware, as in another embodiment, any one or a combination of the following techniques well known in the art can be used: discrete logic circuits with logic gate circuits for implementing logical functions on data signals, application specific integrated circuits with appropriate combinational logic gate circuits, programmable gate arrays (PGAs), field programmable gate arrays (FPGAs), etc.

[0155] Those of ordinary skill in the art can understand that all or part of the steps carried by the method of implementing the above embodiments can be completed by instructing relevant hardware through a program. The said program can be stored in a computer-readable storage medium. When the program is executed, it includes one or a combination of the steps of the method embodiments.

[0156] In addition, in each embodiment of the present application, each functional unit can be integrated into a processing module, or each unit can exist physically alone, or two or more units can be integrated into one module. The above integrated module can be implemented in the form of hardware or in the form of a software functional module. When the above integrated module is implemented in the form of a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium.

[0157] The above-mentioned storage medium can be a read-only memory, a magnetic disk, an optical disc, etc. Although the embodiments of the present application have been shown and described above, it can be understood that the above embodiments are exemplary and should not be construed as limiting the present application. Those of ordinary skill in the art can make changes, modifications, substitutions, and variations to the above embodiments within the scope of the present application.

Claims

1. A verification method for page fault exception caused by processor page table modification, the verification method implements the verification of the behavior of the processor to be verified by a simulator, characterized in that: The following steps are involved: Obtaining a store instruction of the processor to be verified, wherein the store instruction is used to modify a page table of the processor to be verified, and the store instruction is stored in a store instruction queue and / or a submitted store instruction write buffer; Perform write tracking on the store instruction to determine the modification result of the processor to be verified on the page table; Based on the store instruction, simulating the modification result of the page table by the processor to be verified to obtain a simulation result; Comparing the modification result with the simulation result to obtain a verification result; The writing tracking of the store instruction to determine the modification result of the processor to be verified on the page table includes: Executing the store instruction on the page table to determine a dirty bit corresponding to the page table; Tracking the dirty bit to determine the modification result of the processor to be verified on the page table; or, Receiving a microstructure state of the processor to be verified, wherein the microstructure state is used to instruct the simulator to adjust its state; Based on the microstructure state, a modification result of the processor to be verified on the page table is determined.

2. The method according to claim 1, characterized in that The dirty bit corresponds to a first dirty bit value and a second dirty bit value, and executing the store instruction on the page table to determine the dirty bit corresponding to the page table includes: Setting the location written by the store instruction to the first dirty bit value; When executing the store instruction synchronously, the dirty bit position is set to the second dirty bit value.

3. The method according to claim 1, characterized in that The method further comprises: The position of the dirty bit is determined with bytes as the granularity.

4. The method according to claim 1, characterized in that The method further comprises: A dirty bit is set at every preset number of byte positions.

5. The method according to claim 1, characterized in that The method further comprises: According to the microstructure state, changing the simulator state at the corresponding node; When the simulator state change is legal, the store instruction is executed.

6. The method according to claim 1, characterized in that The storage instruction includes a target storage instruction of an external device of the processor to be verified, and the method further includes: Receiving and synchronizing the micro-architecture state of the processor to be verified; Copy the execution result of the target storage instruction.

7. The method according to claim 6, characterized in that The method further comprises: Receiving interrupt information of the external device sent by the processor to be verified; According to the interrupt information, an interrupt of the simulator is triggered.

8. The method according to claim 1, characterized in that The step of comparing the modification result with the simulation result to obtain a verification result includes: Obtaining a simulation result of the simulator executing the store instruction on the processor to be verified; The simulation result and the emulation result are compared by a checker to obtain the verification result.

9. A verification device for page fault exception caused by processor page table modification, the device implements the verification of the behavior of the processor to be verified by the simulator, characterized in that: include: An acquisition module, used for acquiring a storage instruction of a processor to be verified, wherein the storage instruction is used to modify a page table of the processor to be verified, and the storage instruction is stored in a storage instruction queue and / or a storage instruction write buffer; A write tracking module, used for performing write tracking on the store instruction to determine the modification result of the page table by the processor to be verified; A simulation module, used for simulating the modification result of the page table by the processor to be verified based on the store instruction, to obtain a simulation result; A verification module, used for comparing the modification result with the simulation result to obtain a verification result; The write tracking module is specifically used for: Executing the store instruction on the page table to determine a dirty bit corresponding to the page table; Tracking the dirty bit to determine the modification result of the processor to be verified on the page table; or, Receiving a microstructure state of the processor to be verified, wherein the microstructure state is used to instruct the simulator to adjust its state; Based on the microstructure state, a modification result of the processor to be verified on the page table is determined.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer-executable instructions, which are used to implement the method according to any one of claims 1 to 8 when executed by a processor.

Images