Memory preloading processing method and device and storage medium

Abstract

The invention provides a memory preloading processing method and device and a storage medium, and the method comprises the steps that a virtual machine manager collects a plurality of pieces of historical missing page exception information generated by a target application program in a client, and stores the historical missing page exception information according to a plurality of client virtual addresses contained in the historical missing page exception information; determining a target client virtual address to be accessed when the target application program is subjected to page missing exception next time; determining a target host machine virtual address corresponding to the target client virtual address according to the target client virtual address and a storage address of a target client system page table corresponding to the target application program; and controlling the host machine operating system to distribute a target host machine physical address corresponding to the target host machine virtual address, and loading data corresponding to the target host machine virtual address into the target host machine physical address. And the data corresponding to the target client virtual address which may cause the page missing abnormity in the future is loaded into the memory in advance, so that the access delay duration caused by the page missing abnormity is reduced.

Description

Technical Field

[0001] The present invention relates to the field of cloud computing technology, and in particular to a memory preloading processing method, device and storage medium. Background Art

[0002] In a non-virtualized scenario, an application accesses the memory (i.e., main memory, which is a physical storage medium) through a virtual address (VA). In response to a memory access request triggered by an application for a certain VA, the memory management unit (MMU) in the CPU completes the mapping of VA to PA based on a page table that stores the mapping relationship between virtual addresses and physical addresses (PA), and then uses the mapped PA to access the memory. In fact, different applications in an electronic device have their own page tables, but these applications share memory. For example, a memory actually has 4GB of physical address space, but each application can have 4GB of virtual address space. For each application, it believes that it can use the 4GB address space of the memory.

[0003] In actual applications, when an application issues an access request for a VA, and the CPU fails to successfully hit the corresponding PA based on the corresponding page table, it means that the data corresponding to the VA has probably not been loaded into the memory, that is, the PA corresponding to the VA has not been allocated, and a page fault will occur. After a page fault occurs, the corresponding data needs to be read from the disk into the memory, and then the MMU will establish a mapping relationship from VA to the corresponding PA. In this way, the application can execute the above access request normally based on the mapping relationship. Loading data and establishing a mapping relationship between addresses is relatively time-consuming, and the application needs to wait for a long time before it can continue to execute normally. Summary of the invention

[0004] The embodiment of the present invention provides a memory preloading processing method, device and storage medium, which are used to reduce the processing time of an application program when an exception due to a page fault occurs.

[0005] In a first aspect, an embodiment of the present invention provides a memory preloading processing method, which is applied to a virtual machine manager, and the method includes:

[0006] At the current prediction moment, a plurality of historical page fault exception information generated when a target application in a client accesses a memory is collected, wherein the plurality of historical page fault exception information includes a plurality of client virtual addresses corresponding to the target application;

[0007] Determine, based on the multiple client virtual addresses, a target client virtual address to be accessed when a page fault exception occurs next time in the target application program;

[0008] Determine a target host machine virtual address corresponding to the target client machine virtual address on the host machine side according to the target client machine virtual address and a storage address of a target client machine system page table corresponding to the target application program;

[0009] The host machine operating system is controlled to allocate a target host machine physical address corresponding to the target host machine virtual address, and data corresponding to the target host machine virtual address is loaded into the target host machine physical address.

[0010] In a second aspect, an embodiment of the present invention provides a memory preloading processing device, which is applied to a virtual machine manager, and the device includes:

[0011] A collection module, used for collecting, at a current prediction moment, a plurality of historical page fault exception information generated when a target application in a client accesses a memory, wherein the plurality of historical page fault exception information includes a plurality of client virtual addresses corresponding to the target application;

[0012] A prediction module, configured to determine, based on the multiple client virtual addresses, a target client virtual address to be accessed when a page fault exception occurs next time in the target application;

[0013] A loading module is used to determine a target host virtual address corresponding to the target client virtual address on the host side according to the target client virtual address and the storage address of the target client system page table corresponding to the target application; and to control the host operating system to allocate a target host physical address corresponding to the target host virtual address, and load data corresponding to the target host virtual address into the target host physical address.

[0014] In a third aspect, an embodiment of the present invention provides an electronic device, comprising: a memory, a processor, and a communication interface; wherein the memory stores executable code, and when the executable code is executed by the processor, the memory preloading processing method described in the first aspect is executed.

[0015] In a fourth aspect, an embodiment of the present invention provides a non-temporary machine-readable storage medium having executable code stored thereon. When the executable code is executed by a processor in an electronic device, at least the memory preloading processing method described in the first aspect can be implemented.

[0016] In a fifth aspect, an embodiment of the present invention provides a memory preloading processing system, including:

[0017] A host machine and a client machine virtualized on the host machine, wherein the host machine includes a virtual machine manager and a host machine operating system;

[0018] The virtual machine manager is used to execute the memory preloading processing method as described in the first aspect.

[0019] In the scheme provided by the embodiment of the present invention, for the target application in any client virtualized on the host machine, multiple historical page fault exception information generated when the target application accesses the memory can be collected at the current prediction moment, and each page fault exception information includes the client virtual address accessed when the exception occurs. Afterwards, based on the multiple client virtual addresses included in the multiple historical page fault exception information, the predicted target client virtual address to be accessed when the target application has a page fault exception next time is determined. Furthermore, based on the predicted target client virtual address and the storage address of the target client system page table corresponding to the target application, the target host virtual address corresponding to the target client virtual address on the host side is determined to control the host operating system to allocate the target host physical address corresponding to the target host virtual address, and load the data corresponding to the target host virtual address into the target host physical address, so as to load the data corresponding to the target client virtual address that may cause a page fault exception in the future into the memory in advance, so as to reduce the processing time of the target application when a page fault exception occurs. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0021] Figure 1 A schematic diagram of a virtualization scenario provided by an embodiment of the present invention;

[0022] Figure 2 A flowchart of a memory preloading processing method provided by an embodiment of the present invention;

[0023] Figure 3 A schematic diagram of an address conversion process provided by an embodiment of the present invention;

[0024] Figure 4 A flowchart of a memory preloading processing method provided by an embodiment of the present invention;

[0025] Figure 5 A flowchart of a memory preloading processing method provided by an embodiment of the present invention;

[0026] Figure 6 A flowchart of a memory preloading processing method provided by an embodiment of the present invention;

[0027] Figure 7 A schematic diagram of the structure of a memory preloading processing device provided by an embodiment of the present invention;

[0028] Figure 8 A schematic diagram of the structure of an electronic device provided in this embodiment. DETAILED DESCRIPTION

[0029] In order to make the purpose, technical solutions and advantages of the embodiments of the present invention clearer, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention. In addition, the step timing in the following method embodiments is only an example, not a strict limitation.

[0030] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in the embodiments of the present invention are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data need to comply with the relevant laws, regulations and standards of relevant countries and regions, and provide corresponding operation entrances for users to choose to authorize or refuse.

[0031] First, some concepts involved in the embodiments of the present invention are explained.

[0032] Virtualization: A resource management technology that abstracts and transforms various physical resources of a computer (such as CPU, memory, disk space, network adapters and other I / O devices) to present a configuration environment that can be divided and arbitrarily combined into one or more virtual computers. In this article, it mainly refers to the virtual machine virtualized in the physical machine (such as terminal equipment, server). Among them, the physical machine is called the host, the virtual machine is called the guest, the operating system in the host is represented as host os, and the operating system in the client is represented as guest os.

[0033] Virtual Machine Manager (VMM) is a functional component used to create and manage virtual machines, and is also commonly referred to as a hypervisor.

[0034] Virtual memory: A computer system memory management technology that makes the application think that it has continuous available memory space, but in fact, it is usually divided into multiple physical memory fragments, and some data is temporarily stored on external disk storage for data exchange when needed.

[0035] The Extended Page Table (EPT) is a hardware-assisted page table formed in memory virtualization technology.

[0036] Nested Page Table (NPT) is also a hardware-assisted page table formed in memory virtualization technology.

[0037] Guest Virtual Address (GVA).

[0038] Guest Physical Address (GPA).

[0039] Host Virtual Address (HVA).

[0040] Host Physical Address (HPA for short).

[0041] EPT / NPT page fault: When an application in the client accesses memory that is not allocated by the host, that is, when an HPA is not successfully hit through EPT / NPT, a page fault event will be generated to notify the host operating system to perform corresponding processing.

[0042] gcr3: refers to the cr3 register in the client, which stores the storage address of the client system page table corresponding to an application in the client.

[0043] Memory paging is a memory management mechanism proposed based on the use of MMU. It divides virtual addresses and physical addresses into pages and page frames according to fixed sizes (such as 4KB), and ensures that the sizes of pages and page frames are the same. This mechanism ensures efficient access to memory and enables the operating system to perform non-continuous memory allocation. For an application, when the application starts, some of the data required for its operation (such as code, instructions, etc.) can be loaded from storage devices such as disks into memory (that is, loaded into the allocated physical address, that is, physical page), and when the memory is insufficient, the data in the physical address that is not frequently used can be transferred to storage devices such as disks, and when the data is needed again in the future, the data can be swapped back from the disk to the memory.

[0044] In actual applications, when an application sends an access request to a VA, and the CPU fails to successfully hit the corresponding PA based on the corresponding page table, it means that the data corresponding to the VA is likely not yet loaded into the memory, that is, the PA corresponding to the VA has not yet been allocated. At this time, a page fault exception will occur. The operating system reads the data from the disk into the memory, and then lets the MMU establish a mapping relationship from the VA to the corresponding PA. In this way, the application can normally execute the above access request based on the mapping relationship. It can be seen that in the above situation, the application needs to wait for the required data to be loaded from the disk into the memory, and after the above mapping relationship is established, it can continue to execute normally, and the waiting time is long. In the virtualization scenario, similar page fault exception problems will also be encountered. For this reason, the embodiment of the present invention provides a memory preloading solution that can be applied to the virtualization scenario. In summary, during the operation of the application in the virtual machine, the virtual address (in the virtualization scenario, the virtual address refers to GVA) where a page fault exception may be found in the future is predicted in advance, so that the data corresponding to the virtual address is loaded from the disk to the physical memory in advance, so as to reduce the waiting time required for the application to read the data corresponding to the virtual address in the future.

[0045] Figure 1 A schematic diagram of a virtualization scenario provided by an embodiment of the present invention, such as Figure 1 As shown in FIG. 1 , taking a certain electronic device as an example, the electronic device can virtualize multiple virtual machines such as virtual machine 1, virtual machine 2, etc., as shown in the figure, and multiple applications can be run in each virtual machine, such as Figure 1 Applications a and b are running in virtual machine 1.

[0046] In practical applications, the electronic device may be a device such as a notebook computer, a PC, a server, etc.

[0047] like Figure 1As shown in , each virtual machine may include its own operating system: guest os, and the guest os in different virtual machines may be different or the same. The operating system of the electronic device itself is represented as host os, which may be different or the same as the guest os in each virtual machine.

[0048] As mentioned above, since the virtual machine is built based on the hardware resources of the physical machine (i.e. the electronic device mentioned above) through virtualization technology, in practical applications, the electronic device is usually called a host machine and the virtual machine is called a client machine. For the sake of uniform description, the description of client machine and host machine is uniformly adopted below.

[0049] like Figure 1 As shown in , in actual applications, a virtual machine manager (VMM shown in the figure) will run in the host machine to manage each client.

[0050] In fact, each client also contains at least one virtual CPU (generally represented as vCPU) and other virtual computing, storage and other resources. Multiple vCPUs in each client can share a physical CPU (generally represented as pCPU) in the host. Figure 1 Not shown in the figure.

[0051] In addition to the host OS and VMM, the host machine also includes Figure 1 The physical CPU, memory and other hardware resources shown in the figure.

[0052] For memory access, in the above virtualization scenarios, two types of page tables are generally used: client system page tables and hardware-assisted page tables (such as EPT, NPT and other page tables provided by some memory virtualization technologies). Among them, the client system page table is maintained locally on the client and can be maintained by the guest OS; the hardware-assisted page table is maintained by the VMM.

[0053] It should be noted that different clients will have their own client system page table and hardware-assisted page table, such as Figure 1 The client system page table (represented as guest page table a in the figure) and the hardware assisted page table (represented as EPTa in the figure) corresponding to application a are illustrated in the figure.

[0054] The client system page table stores the mapping relationship between GVA and GPA, which is used to complete the address conversion from GVA to GPA; the hardware-assisted page table stores the mapping relationship between GPA and HPA, which is used to complete the address conversion from GPA to HPA.

[0055] Taking the above-mentioned application a contained in client 1 as an example, when application a accesses memory, an access request containing GVAi is triggered, wherein GVAi refers to a certain client virtual address to be accessed. Based on the access request, GVAi is firstly converted through guest page table a to obtain the corresponding GPAi. The address conversion operation is completed on the client 1 side. Afterwards, the CPU converts GPAi into the corresponding HPAi based on EPTa. Afterwards, the corresponding data can be read and written from the HPAi in the memory. It should be noted that although EPTa is maintained by VMM, the address conversion is completed by hardware (i.e., CPU), that is, the mapping relationship between GPA and HPA stored in EPTa is updated by VMM.

[0056] Among them, the client 1 includes a gcr3 register, which stores the storage address of the guest page table a. In fact, the guest page table a may be an organizational structure of a multi-level page table, and the gcr3 register stores the storage address of the first-level page table. Since the client system page tables corresponding to different applications are different, the storage addresses are also different, so the addresses stored in the gcr3 registers corresponding to different applications are also different. In the process of converting GVAi to GPAi, the storage address of the guest page table a in the gcr3 register corresponding to application a is needed. The conversion process can refer to the existing related technology and will not be repeated here.

[0057] In the above memory access process, if the CPU does not find the corresponding HPAi when performing address translation on GPAi based on EPTa, an EPT page fault will be generated, and the CPU will enter the root mode and run the VMM. After that, the VMM needs to handle the page fault exception. In simple terms, it controls the host OS to load the data corresponding to GPAi (ie GVAi) from the disk to an idle physical address (ie HPAi) in the memory, so as to form a mapping relationship between GPAi and HPAi. Finally, the VMM updates the mapping relationship to EPTa. In this way, based on the newly added mapping relationship in EPTa, application a can complete the above memory access. However, this will make application a wait too long.

[0058] The process in which the VMM controls the host OS to load data into the memory will be specifically described in the following embodiments.

[0059] Based on the solution provided by the embodiment of the present invention, the above problems can be overcome. The solution provided by the embodiment of the present invention is described in detail below.

[0060] Figure 2A flowchart of a memory preloading processing method provided by an embodiment of the present invention, the method can be Figure 1 The VMM in the host machine shown in FIG. Figure 2 As shown, the method may include the following steps:

[0061] 201. At the current prediction moment, multiple historical page fault exception information generated when the target application in the client accesses the memory is collected, and the multiple historical page fault exception information includes multiple client virtual addresses corresponding to the target application.

[0062] 202. Determine, based on the multiple client virtual addresses, a target client virtual address to be accessed when a page fault exception occurs next time in the target application.

[0063] 203. Determine a target host machine virtual address corresponding to the target client machine virtual address on the host machine side according to the target client machine virtual address and the storage address of the target client machine system page table corresponding to the target application program.

[0064] 204. Control the host machine operating system to allocate a target host machine physical address corresponding to the target host machine virtual address, and load data corresponding to the target host machine virtual address into the target host machine physical address.

[0065] In summary, in this embodiment, the VMM obtains the predicted GVA to be accessed the next time a page fault exception occurs based on the GVA contained in multiple historical page fault exception information collected from the target application, and performs address conversion through the GVA and the storage address of the page table recorded in the gcr3 corresponding to the target application to obtain the HVA corresponding to the GVA, so that the host OS performs memory preloading processing based on the HVA, thereby completing the memory preloading processing in the virtualization scenario.

[0066] In this embodiment, the client in step 201 may be any one of multiple clients in the host machine, and the target application may be any one of multiple applications running in the client.

[0067] In fact, during the running of the application in the client, the VMM can periodically predict the GVA that the application in the client will access when it finds a page fault exception in the future.

[0068] In an optional embodiment, the above prediction process can be executed locally in the VMM. In another optional embodiment, the above prediction process can also be executed in a prediction module, and the prediction result is provided to the VMM. The prediction module is a functional module running in the user state, and the VMM runs in the kernel state. The interaction between the prediction module in the user state and the VMM in the kernel state can be realized by existing related methods, such as system call, etc. In practical applications, a prediction model (such as a certain neural network model structure) or a set prediction algorithm can be pre-trained to realize the above prediction function, but it is not limited to this.

[0069] In this embodiment, the above page fault exception information refers to the page fault exception generated during the conversion from GPA to HPA, such as EPT / NPT page fault, and is not the page fault exception generated during the conversion from GVA to GPA on the client side. The page fault exception generated on the client side can be handled by the guest OS.

[0070] Historical page fault exception information (EPT / NPT page fault) is actually the exception prompt information generated when the VMM fails to perform address conversion from GPA to HPA based on, for example, the EPT page table. It is used to describe the address access information of the application at this time, which may include information such as the currently accessed GVA, the corresponding GPA, and the storage address of the client system page table corresponding to the application that implements the conversion from GVA to GPA.

[0071] In actual applications, different applications in the client may have different access characteristics to their respective GVA spaces. For example, some applications may present a continuous access characteristic of GVA, while some applications may present a certain access characteristic of discontinuous GVA access. For example, by analyzing the access characteristics of the GVA accessed each time a page fault exception occurs within a period of time after the target application starts running, the GVA to be accessed when a page fault exception occurs next time can be predicted (i.e., the target client virtual address).

[0072] In actual applications, after the target application is started, it will continuously trigger access requests for different GVAs.

[0073] In this embodiment, the target application is the application a mentioned above, and the trigger is an access request for GVAi. During the execution of the access request, the guest OS first converts GVAi to GPAi based on the mapping relationship between GVA and GPA recorded in the guest page table a corresponding to the target application. After that, when the CPU performs address conversion of GPAi according to EPTa, if it is found that the HPA corresponding to GPAi has not been allocated, a page fault exception information will be generated. The page fault exception information includes GPAi, GVAi, and the storage address of the guest page table a recorded in the gcr3 corresponding to the application a (in fact, the storage address of the first-level page table in the case of multi-level page tables). After that, the VMM handles the page fault exception to load the data corresponding to GVAi, that is, GPAi, from the disk to the allocated HPAi, as described above.

[0074] In the above example, the VMM can collect the above page fault exception information. It is assumed that the above page fault exception information is the first page fault exception information generated after the application a is started. If the target GVA to be accessed next time a page fault exception occurs cannot be accurately determined based on the page fault exception information alone, then the subsequent page fault exception information generated by the application a can be continuously collected.

[0075] When the multiple page fault exception information that has been collected can meet the prediction requirements, the multiple page fault exception information that has been collected at this time is used as the multiple historical page fault exception information corresponding to the application a. Afterwards, when a prediction time T1 (called the current prediction time) is reached based on the set prediction cycle, the multiple GVAs included in the multiple historical page fault exception information are obtained to determine the target GVA to be accessed when the application a has a page fault exception next time based on the multiple GVAs, which is assumed to be GVAj.

[0076] After that, the VMM will load the data corresponding to GVAj into the allocated target host machine physical address (expressed as HPAj) in advance through the cooperation of the host OS in accordance with the process similar to the page fault exception handling mentioned above.

[0077] In fact, during the access process of the application a in the client to the memory, taking the above-mentioned access request of GVAj as an example, in detail, it includes the following address conversion processes: GVAj is converted to GPAj, GPAj is converted to HVAj, and HVAj is converted to HPAj. Among them, the conversion of GVAj to GPAj is completed on the client side based on the client system page table (guest page table a), and the conversion of HVAj to HPAj is completed on the host side based on the host system page table (assuming that for application a, the page table is represented as host page table a), and the conversion of GPAj to HVAj is completed by the VMM, that is, the mapping relationship between GPAj and HVAj is maintained in the VMM. For the convenience of description, the page table corresponding to application a that stores the mapping relationship is represented as VMM page table a. The above address conversion process is as follows Figure 3 as shown in .

[0078] In fact, since VMM can realize the conversion from GPAj to HVAj and host OS can complete the conversion from HVAj to HPAj, it is precisely because of these two address conversions implemented by software that EPTa executed in hardware can be finally constructed.

[0079] In this embodiment, after predicting the above GVAj, VMM needs to determine the HVAj (i.e., the target host machine virtual address) corresponding to the GVAj based on GVAj and the storage address of the guest page table a recorded in the above gcr3, and then control hostos to allocate the target host machine physical address (expressed as HPAj) corresponding to HVAj, and load the data corresponding to HVAj into HPAj. In other words, it is necessary to first convert GVAj to HVAj based on the storage address of the guest page table a recorded in gcr3.

[0080] The reason why GVAj needs to be converted to HVAj is that the data is actually loaded from the disk into the physical memory by the host OS, and the addresses used by the host OS are HVA and HPA. At this time, the application a running in the client is regarded as an ordinary application process in a non-virtualized scenario. The memory access of the application a actually uses the virtual address provided by the host OS, that is, HVA. For the HVAj that the application a currently wants to access, the host OS allocates the corresponding HPAj for it and loads the data corresponding to the HVAj from the disk into the HPAj.

[0081] And reference Figure 3, to convert GVAj to HVAj, you need to first convert GVAj to GPAj, and then convert GPAj to HVAj. Since the mapping relationship between GPA and HVA is maintained by the VMM, after the VMM obtains GPAj, it can determine the corresponding HVAj based on the mapping relationship.

[0082] The conversion of GVAj to GPAj is based on the storage address of the guest page table a recorded in gcr3.

[0083] In an optional embodiment, since the multiple historical page fault exception information corresponding to application a includes multiple GVAs and corresponding multiple GPAs, VMM can establish a mapping relationship preservation record corresponding to the storage address of guest page table a recorded in gcr3 (for ease of description, expressed as the page table base address) based on the multiple historical page fault exception information, wherein the mapping relationship preservation record includes the mapping relationship between the above multiple GVAs and GPAs. Based on this, for the above GVAj, it is possible to find out whether the GVAj is included in the mapping relationship preservation record. If it is included, the GPAj corresponding to GVAj is directly determined from the mapping relationship preservation record, and then the HVAj corresponding to GPAj is determined based on the mapping relationship between the locally stored GPA and HVA.

[0084] In actual applications, if application a previously generated a page fault exception (EPT / NPT pagefault) when accessing GVAj, then the historical page fault exception information will include the correspondence between GVAj and GPAj. Later, if the data of GVAj has not been used for a long time due to memory space shortage, the data corresponding to GVAj may be swapped out from the memory to the disk. If GVAj is accessed again, a page fault exception will occur again. In the solution provided by the above optional embodiment, in this example situation, if the predicted GVA is GVAj, a record can be saved based on the mapping relationship that stores the correspondence between GVAj and GPAj, and GPAj can be directly queried.

[0085] When GVAj is not found in the above mapping relationship storage record, the solution provided by the following optional embodiment may be adopted. It should be noted that the solution provided by the following optional embodiment may also be implemented independently, that is, it is not limited to being implemented only when GVAj is not found in the above mapping relationship storage record.

[0086] In this optional embodiment, the VMM can send the above page table base address to the guest OS to indicate that the application a is currently being processed, because different application programs have different corresponding page table base addresses. The guest OS reads the guest page table a based on the page table base address to determine the GPAj corresponding to GVAj according to the mapping relationship between GVA and GPA stored in the guest page table a, and provides GPAj to the VMM. Afterwards, the VMM determines the HVAj corresponding to GPAj based on the mapping relationship between GPA and HVA stored locally.

[0087] In combination with the above page table base address, the implementation method of completing the conversion from GVAj to HVAj is not limited to the two optional implementation methods exemplified above.

[0088] In summary, in the embodiment of the present invention, each time a page fault exception occurs in the target application in the client, the corresponding GVA and the page table base address stored in gcr3 are recorded. A series of collected GVAs are used as a basis to analyze the GVA to be accessed when the next page fault exception occurs through a certain prediction algorithm. Then, the predicted GVA and the page table base address stored in gcr3 are converted into HVA, and memory is preloaded in advance on the host side, thereby reducing the impact caused by the page fault exception of the target application on the client side.

[0089] To reduce the impact of page fault exceptions, you can do the following Figure 4 and Figure 5 The embodiments shown are to be understood.

[0090] Figure 4 A flowchart of a memory preloading processing method provided by an embodiment of the present invention, the method can be Figure 1 The VMM shown in the figure is executed, such as Figure 4 As shown, the method may include the following steps:

[0091] 401. At the current prediction moment, multiple historical page fault exception information generated when the target application in the client accesses the memory is collected, and the multiple historical page fault exception information includes multiple client virtual addresses corresponding to the target application.

[0092] 402. Determine, based on the predicted input information set including the plurality of client virtual addresses, a target client virtual address to be accessed when a page fault exception occurs next time in the target application.

[0093] 403. Determine a target host machine virtual address corresponding to the target client machine virtual address on the host machine side according to the target client machine virtual address and the storage address of the target client machine system page table corresponding to the target application program.

[0094] 404. Control the host machine operating system to allocate a target host machine physical address corresponding to the target host machine virtual address, and load data corresponding to the target host machine virtual address into the target host machine physical address.

[0095] 405. In response to page fault exception information triggered by the target application when accessing the target client virtual address, obtain the target host physical address assigned by the host operating system, determine the target client physical address corresponding to the target client virtual address, and update the mapping relationship between the target client physical address and the target host physical address into the hardware assisted page table corresponding to the target application.

[0096] 406. Update the target client virtual address into the prediction input information set.

[0097] Still taking the target application as application a and the target client virtual address as GVAj in the aforementioned embodiment as an example, after the host OS allocates the above HPAj and loads the corresponding data into HPAj based on HVAj, HPAj can be fed back to the VMM.

[0098] In this embodiment, optionally, after receiving the above HPAj, VMM does not immediately write the mapping relationship between GPAj and HPAj in EPTa, but only temporarily stores the mapping relationship between GPAj and HPAj locally, so as not to affect the defect exception normally generated when application a accesses GVAj. In other words, if application a accesses GVAj later, a page fault exception will be generated because the mapping relationship between GPAj and HPAj does not exist in EPTa. At this time, VMM queries the mapping relationship between GPAj and HPAj in the local storage record based on GVAj and GPAj contained in the page fault exception information, and then writes the mapping relationship between GPAj and HPAj into EPTa.

[0099] In addition, when the above-mentioned page fault exception occurs when accessing GVAj, GVAj may be updated to the prediction input information set, so as to be used for subsequent prediction of the GVA to be accessed when the page fault exception occurs in the application a.

[0100] In the solution provided by this embodiment, when a page fault exception occurs when accessing GVAj, since the corresponding data has been pre-loaded into the memory and the corresponding GPAj has been pre-determined, the VMM only needs to perform an EPTa update action, which takes a short time and will not significantly affect the access delay of application a. In this solution, since the page fault exception of application a is not really avoided, by collecting the page fault exception information normally generated by application a, the GVA to be accessed when a page fault exception occurs later can be predicted more accurately.

[0101] Figure 5 A flowchart of a memory preloading processing method provided by an embodiment of the present invention, the method can be Figure 1 The VMM shown in the figure is executed, such as Figure 5 As shown, the method may include the following steps:

[0102] 501. At the current prediction moment, multiple historical page fault exception information generated when the target application in the client accesses the memory is collected, and the multiple historical page fault exception information includes multiple client virtual addresses corresponding to the target application.

[0103] 502. Determine, based on the predicted input information set including the above-mentioned multiple client virtual addresses, a target client virtual address to be accessed when a page fault exception occurs next time in the target application.

[0104] 503. Determine a target host machine virtual address corresponding to the target client machine virtual address on the host machine side according to the target client machine virtual address and the storage address of the target client machine system page table corresponding to the target application program.

[0105] 504. Control the host machine operating system to allocate a target host machine physical address corresponding to the target host machine virtual address, and load data corresponding to the target host machine virtual address into the target host machine physical address.

[0106] 505. Obtain the target host machine physical address assigned by the host machine operating system, determine the target client machine physical address corresponding to the target client machine virtual address, and update the mapping relationship between the target client machine physical address and the target host machine physical address into the hardware-assisted page table corresponding to the target application, so that the target application will not trigger a page fault exception message when accessing the target client machine virtual address.

[0107] 506. In response to the output of the target client virtual address, the target client virtual address is updated into the prediction input information set, so as to be used for predicting the client virtual address to be accessed when a page fault exception occurs next time for the target application at the next prediction moment.

[0108] In this embodiment, taking the target application as application a and the target client virtual address as GVAj in the aforementioned embodiment as an example, after the host os allocates the above HPAj and loads the corresponding data into HPAj based on HVAj, HPAj can be fed back to the VMM.

[0109] In this embodiment, after obtaining HPAj, VMM can directly update the mapping relationship between GPAj and HPAj into EPTa, so that if application a really accesses GVAj later, no page fault exception will be generated and the access can be successfully completed.

[0110] Based on this, when predicting the GVA to be accessed when the next page fault exception occurs in application a at the next prediction moment, the prediction input information set used will include GVAj predicted output at the previous prediction moment, even if application a may not actually access GVAj.

[0111] In summary, Figure 4 and Figure 5 The solution provided by the illustrated embodiment mainly considers the balance between the access waiting delay caused by the page fault exception and the prediction accuracy.

[0112] Figure 6 A flowchart of a memory preloading processing method provided by an embodiment of the present invention, the method can be Figure 1 The VMM shown in the figure is executed, such as Figure 6 As shown, the method may include the following steps:

[0113] 601. At the current prediction moment, collect a set of historical page fault exception information corresponding to the client, where the set of historical page fault exception information is generated by multiple applications running in the client, wherein each page fault exception information contains a storage address of a client system page table corresponding to the corresponding application.

[0114] 602. Determine multiple page fault exception information corresponding to the storage address of the target client system page table from the historical page fault exception information set as multiple historical page fault exception information corresponding to the target application. The target client system page table corresponds to the target application.

[0115] The target application is any one of multiple applications.

[0116] 603. Determine a target client virtual address to be accessed when a page fault exception occurs next time in the target application according to multiple client virtual addresses included in multiple historical page fault exception information corresponding to the target application.

[0117] 604. Determine a target host machine virtual address corresponding to the target client machine virtual address on the host machine side according to the target client machine virtual address and the storage address of the target client machine system page table corresponding to the target application program.

[0118] 605. Control the host machine operating system to allocate a target host machine physical address corresponding to the target host machine virtual address, and load data corresponding to the target host machine virtual address into the target host machine physical address.

[0119] The above embodiment introduces the memory preloading process of the VMM for the memory access process of the target application. In actual applications, a client often runs multiple applications, and the target application is one of the multiple applications. Memory preloading processing needs to be performed for these multiple applications.

[0120] In fact, after each application is started and runs, if the above-mentioned page fault exception occurs, the corresponding page fault exception information of the VMM will be triggered, and the startup time of the application may be different, and the frequency of page fault exceptions may also be different. Therefore, after the client is started and runs, the VMM starts to collect the page fault exception information generated by the client, that is, the page fault exception information generated by all the started applications in the client, and constitutes a page fault exception information collection.

[0121] Since the guest page table corresponding to each application is different, the storage address of the guest page table contained in the page fault exception information triggered by different applications (contained in the corresponding gcr3) is different. Therefore, the VMM can use the storage address of the guest page table as the basis for distinguishing the page fault exception information triggered by different applications, and merge the page fault exception information corresponding to the storage address of the same guest page table. For example, the storage address of the guest page table corresponding to the target application is called the storage address of the target guest page table, and the page fault exception information corresponding to the storage address of the target guest page table is merged together as multiple historical page fault exception information corresponding to the target application.

[0122] In actual applications, a threshold value for the number of page fault exception information can be set in the VMM. Taking the target application as an example, if it is found that the number of page fault exception information corresponding to the storage address of the target guest page table has reached the threshold value, the prediction processing of the GVA to be accessed when the next page fault exception occurs for the target application is started.

[0123] The execution of steps 603 - 605 refers to the description in the aforementioned other embodiments and will not be repeated here.

[0124] The communication devices of one or more embodiments of the present invention will be described in detail below. Those skilled in the art will appreciate that these devices can be configured using commercially available hardware components through the steps taught in this solution.

[0125] Figure 7 A schematic diagram of the structure of a memory preloading processing device provided by an embodiment of the present invention, the device is applied to the above-mentioned virtual machine manager, such as Figure 7 As shown, the device includes: a collection module 11, a prediction module 12, and a loading module 13.

[0126] The collection module 11 is used to collect multiple historical page fault exception information generated when the target application in the virtual machine accesses the memory at the current prediction moment, and the multiple historical page fault exception information includes multiple client virtual addresses corresponding to the target application.

[0127] The prediction module 12 is used to determine, based on the multiple client virtual addresses, a target client virtual address to be accessed when a page fault exception occurs next time in the target application.

[0128] The loading module 13 is used to determine the target host virtual address corresponding to the target client virtual address on the host side according to the target client virtual address and the storage address of the target client system page table corresponding to the target application; and to control the host operating system to allocate the target host physical address corresponding to the target host virtual address, and load the data corresponding to the target host virtual address into the target host physical address.

[0129] Optionally, the device also includes: a first page table update module, used to obtain the target host physical address assigned by the host operating system; determine the target client physical address corresponding to the target client virtual address; and update the mapping relationship between the target client physical address and the target host physical address into the hardware-assisted page table corresponding to the target application, so that the target application will not trigger page fault exception information when accessing the target client virtual address.

[0130] Optionally, the device also includes: a first prediction update module, used to update the target client virtual address into a prediction input information set in response to the output of the target client virtual address, so as to predict the client virtual address to be accessed when a page fault exception occurs next time for the target application at the next prediction moment, and the prediction input information set includes the multiple client virtual addresses.

[0131] Optionally, the device also includes: a second page table update module, which is used to obtain the target host physical address allocated by the host operating system in response to page fault exception information triggered by the target application when accessing the target client virtual address; determine the target client physical address corresponding to the target client virtual address; and update the mapping relationship between the target client physical address and the target host physical address into the hardware-assisted page table corresponding to the target application.

[0132] Optionally, the device further comprises: a second prediction update module, configured to update the target client virtual address into the prediction input information set in response to page fault exception information triggered when the target application accesses the target client virtual address.

[0133] Optionally, the multiple historical page fault exception information also includes multiple client physical addresses corresponding to the multiple client virtual addresses. The loading module 13 is also used to: establish a mapping relationship saving record corresponding to the storage address of the target client system page table, the mapping relationship saving record includes the mapping relationship between the multiple client virtual addresses and the multiple client physical addresses; determine the mapping relationship saving record according to the storage address of the target client system page table; if the target client virtual address is found from the mapping relationship saving record, determine the target client physical address corresponding to the target client virtual address from the mapping relationship saving record; determine the target host virtual address corresponding to the target client physical address according to the stored mapping relationship between the client physical address and the host virtual address, and the mapping relationship between the client physical address and the host virtual address corresponds to the target application.

[0134] Optionally, the loading module 13 is also used to: send the storage address of the target client system page table to the client operating system, so that the client operating system determines the target client physical address corresponding to the target client virtual address according to the mapping relationship between the client virtual address and the client physical address stored in the target client system page table; determine the target host virtual address corresponding to the target client physical address according to the stored mapping relationship between the client physical address and the host virtual address, and the mapping relationship between the client physical address and the host virtual address corresponds to the target application.

[0135] Optionally, the acquisition module 11 is specifically used to: acquire a set of historical page fault exception information corresponding to the client, the set of historical page fault exception information being generated by multiple applications running in the client, wherein each page fault exception information includes a storage address of a client system page table corresponding to the corresponding application, and the target application is any one of the multiple applications; determine multiple page fault exception information corresponding to the storage address of the target client system page table from the set of historical page fault exception information as the multiple historical page fault exception information corresponding to the target application.

[0136] Figure 7 The device shown can execute the steps provided in the aforementioned embodiments. For detailed execution process and technical effects, please refer to the description in the aforementioned embodiments, which will not be repeated here.

[0137] The embodiment of the present invention also provides an electronic device, such as Figure 8 As shown, it may include: a processor 21, a memory 22, and a communication interface 23. The memory 22 stores executable codes, and when the executable codes are executed by the processor 21, the memory preloading processing method in the above-mentioned embodiment is implemented.

[0138] In addition, an embodiment of the present invention provides a non-temporary machine-readable storage medium, on which executable code is stored. When the executable code is executed by a processor in an electronic device, the memory preloading processing method provided in the aforementioned embodiment can be implemented.

[0139] The device embodiments described above are merely illustrative, wherein the units described as separate components may or may not be physically separated. Some or all of the modules may be selected according to actual needs to achieve the purpose of the present embodiment. Those of ordinary skill in the art may understand and implement the present invention without creative effort.

[0140] Through the description of the above embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by adding a necessary general hardware platform, and of course can also be implemented by combining hardware and software. Based on such an understanding, the above technical solution is essentially or the part that contributes to the prior art can be embodied in the form of a computer product, and the present invention can be in the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program codes.

[0141] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit it. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A memory preloading processing method, characterized in that: Applied to a virtual machine manager, the method comprises: At the current prediction moment, a plurality of historical page fault exception information generated when a target application in a client accesses a memory is collected, wherein the plurality of historical page fault exception information includes a plurality of client virtual addresses corresponding to the target application; Determine, based on the multiple client virtual addresses, a target client virtual address to be accessed when a page fault exception occurs next time in the target application program; Determine a target host machine virtual address corresponding to the target client machine virtual address on the host machine side according to the target client machine virtual address and a storage address of a target client machine system page table corresponding to the target application program; The host machine operating system is controlled to allocate a target host machine physical address corresponding to the target host machine virtual address, and data corresponding to the target host machine virtual address is loaded into the target host machine physical address.

2. The method according to claim 1, characterized in that The method further comprises: Obtaining the physical address of the target host machine assigned by the host machine operating system; Determine a target client physical address corresponding to the target client virtual address; The mapping relationship between the target client physical address and the target host physical address is updated into the hardware-assisted page table corresponding to the target application so that the target application will not trigger page fault exception information when accessing the target client virtual address.

3. The method according to claim 2, characterized in that The method further comprises: In response to the output of the target client virtual address, the target client virtual address is updated to a prediction input information set for predicting the client virtual address to be accessed when a page fault exception occurs next time for the target application at the next prediction moment, wherein the prediction input information set includes the multiple client virtual addresses.

4. The method according to claim 1, characterized in that: The method further comprises: In response to page fault exception information triggered by the target application when accessing the target client virtual address, obtaining the target host machine physical address allocated by the host machine operating system; Determine a target client physical address corresponding to the target client virtual address; The mapping relationship between the target client physical address and the target host physical address is updated into the hardware-assisted page table corresponding to the target application.

5. The method according to claim 4, characterized in that The method further comprises: In response to page fault exception information triggered by the target application when accessing the target client virtual address, the target client virtual address is updated into the prediction input information set.

6. The method according to any one of claims 1 to 5, characterized in that The plurality of historical page fault exception information also includes a plurality of client physical addresses corresponding to the plurality of client virtual addresses; The method further comprises: establishing a mapping relationship saving record corresponding to a storage address of the target client system page table, wherein the mapping relationship saving record comprises a mapping relationship between the plurality of client virtual addresses and the plurality of client physical addresses; The determining, based on the target client virtual address and the storage address of the target client system page table corresponding to the target application, a target host virtual address corresponding to the target client virtual address on the host side includes: Determine the mapping relationship saving record according to the storage address of the target client system page table; If the target client virtual address is found from the mapping relationship storage record, then determining the target client physical address corresponding to the target client virtual address from the mapping relationship storage record; The target host virtual address corresponding to the target client physical address is determined according to the stored mapping relationship between the client physical address and the host virtual address, and the mapping relationship between the client physical address and the host virtual address corresponds to the target application.

7. The method according to any one of claims 1 to 5, characterized in that The determining, based on the target client virtual address and the storage address of the target client system page table corresponding to the target application, a target host virtual address corresponding to the target client virtual address on the host side includes: Sending the storage address of the target client system page table to the client operating system, so that the client operating system determines the target client physical address corresponding to the target client virtual address according to the mapping relationship between the client virtual address and the client physical address stored in the target client system page table; The target host virtual address corresponding to the target client physical address is determined according to the stored mapping relationship between the client physical address and the host virtual address, and the mapping relationship between the client physical address and the host virtual address corresponds to the target application.

8. The method according to any one of claims 1 to 5, characterized in that The acquisition of multiple historical page fault exception information generated when the target application in the client accesses the memory includes: Collecting a set of historical page fault exception information corresponding to the client, wherein the set of historical page fault exception information is generated by multiple applications running in the client, wherein each page fault exception information includes a storage address of a client system page table corresponding to the corresponding application, and the target application is any one of the multiple applications; A plurality of page fault exception information corresponding to the storage address of the target client system page table is determined from the historical page fault exception information set as the plurality of historical page fault exception information corresponding to the target application.

9. An electronic device, characterized in that: include: A memory, a processor, and a communication interface; wherein the memory stores executable code, and when the executable code is executed by the processor, the memory preloading processing method as described in any one of claims 1 to 8 is executed.

10. A non-transitory machine-readable storage medium, characterized in that: The non-transitory machine-readable storage medium stores executable code, and when the executable code is executed by a processor in an electronic device, the memory preloading processing method according to any one of claims 1 to 8 is executed.

11. A memory preloading processing system, characterized in that: include: A host machine and a client machine virtualized on the host machine, wherein the host machine includes a virtual machine manager and a host machine operating system; The virtual machine manager is used to execute the memory preloading processing method according to any one of claims 1 to 8.

Images