Fault page recovery method and device and storage medium

Abstract

The embodiment of the invention provides a missing page recovery method and device and a storage medium. A new IOPF scheduling function is innovatively provided in the virtual machine manager. The method comprises the following steps: determining a target virtual machine to which a missing page request belongs in response to monitoring of the missing page request initiated by any IO device on a physical machine; selecting a target physical kernel used for processing the page missing request for the target virtual machine from the plurality of physical kernels; and scheduling the missing page request to the target physical kernel so as to process the missing page request by utilizing the target physical kernel. Therefore, by determining the virtual machine to which each IOPF occurring in the physical machine belongs, the IOPF scheduling can be carried out by taking the virtual machine as a constraint condition, so that the IOPF can be prevented from being concentrated on a certain specified physical kernel on the physical machine to be processed, and disturbance of IOPF scheduling to irrelevant virtual machines can be effectively avoided, thereby ensuring reasonable scheduling of the IOPF and further improving the processing efficiency of the IOPF.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a missing page recovery method, device and storage medium. Background Art

[0002] IOPF (IO Page fault) is a page fault request sent by an IO (Input / Output) device.

[0003] Currently, in a physical machine with a multi-core processor, the page fault requests initiated by various IO devices connected to the physical machine are concentrated on a designated physical core for processing, which not only brings huge workload to the physical core, but also causes queuing problems in page fault recovery, affecting the efficiency of page fault recovery. Summary of the invention

[0004] Multiple aspects of the present application provide a page fault recovery method, device and storage medium to improve the processing efficiency of IOPF.

[0005] The embodiment of the present application provides a method for recovering a page fault, which is applicable to a virtual machine manager in a physical machine, wherein the physical machine is equipped with an IO device and includes multiple physical cores, and the method includes:

[0006] In the case of monitoring that any IO device on the physical machine initiates a page fault request, determining a target virtual machine to which the page fault request belongs;

[0007] Selecting a target physical core for processing a page fault request for the target virtual machine from the multiple physical cores;

[0008] The page fault request is dispatched to the target physical core so as to utilize the target physical core to process the page fault request.

[0009] The embodiment of the present application also provides a computing device, including a memory, a processor, and a communication component;

[0010] The memory is used to store one or more computer instructions;

[0011] The processor is coupled to the memory and the communication component, and is configured to execute the one or more computer instructions to perform the aforementioned page fault recovery method.

[0012] An embodiment of the present application also provides a computer-readable storage medium storing computer instructions. When the computer instructions are executed by one or more processors, the one or more processors are caused to execute the aforementioned page fault recovery method.

[0013] In an embodiment of the present application, it is innovatively proposed to add a scheduling function for IOPF in the virtual machine manager. In response to monitoring a page fault request initiated by any IO device on the physical machine, the target virtual machine to which the page fault request belongs can be determined; a target physical core for processing the page fault request is selected from the multiple physical cores for the target virtual machine; and the page fault request is scheduled to the target physical core to use the target physical core to process the page fault request. In this way, by clarifying the virtual machines to which each IOPF occurring in the physical machine belongs, IOPF scheduling can be performed with the virtual machine as a constraint condition, which can not only avoid IOPF being concentrated on a designated physical core on the physical machine for processing, but also effectively avoid IOPF scheduling causing disturbances to unrelated virtual machines, thereby ensuring reasonable scheduling of IOPF, and further improving the processing efficiency of IOPF. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:

[0015] Figure 1 A flowchart of a missing page recovery method provided by an exemplary embodiment of the present application;

[0016] Figure 2a A logical schematic diagram of a missing page recovery method provided for an exemplary embodiment of the present application;

[0017] Figure 2b An exemplary structural diagram of an IOPF scheduler provided for an exemplary embodiment of the present application;

[0018] Figure 3 A flowchart of a missing page recovery method provided for another exemplary embodiment of the present application;

[0019] Figure 4 A logical diagram of an optional implementation method provided for an exemplary embodiment of the present application;

[0020] Figure 5 A schematic diagram of the structure of a computing device provided for another exemplary embodiment of the present application. DETAILED DESCRIPTION

[0021] In order to make the purpose, technical solution and advantages of the present application clearer, the technical solution of the present application will be clearly and completely described below in combination with the specific embodiments of the present application and the corresponding drawings. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of the present application.

[0022] At present, all IOPFs occurring on a physical machine are processed on a designated physical core, which brings huge work pressure to the designated physical core and causes IOPF queuing problems, affecting the processing efficiency of IOPF. To this end, in some embodiments of the present application: it is innovatively proposed to add a scheduling function for IOPF in the virtual machine manager. In response to monitoring a page fault request initiated by any IO device on the physical machine, the target virtual machine to which the page fault request belongs can be determined; the target physical core for processing the page fault request is selected from the multiple physical cores for the target virtual machine; the page fault request is scheduled to the target physical core to use the target physical core to process the page fault request. In this way, by clarifying the virtual machine to which each IOPF occurring in the physical machine belongs, IOPF scheduling can be performed with the virtual machine as a constraint condition, which can not only avoid IOPF being concentrated on a designated physical core on the physical machine for processing, but also effectively avoid IOPF scheduling causing disturbances to irrelevant virtual machines, thereby ensuring the reasonable scheduling of IOPF, and then improving the processing efficiency of IOPF.

[0023] The technical solutions provided by various embodiments of the present application are described in detail below in conjunction with the accompanying drawings.

[0024] Figure 1 A flowchart of a missing page recovery method provided by an exemplary embodiment of the present application. Figure 2a A logical diagram of a missing page recovery method provided by an exemplary embodiment of the present application. Figure 2a The page fault recovery method provided in this embodiment can be implemented by a virtual machine monitor (VMM) in a physical machine. The virtual machine monitor can be an intermediate software layer running between basic physical resources and operating systems, allowing multiple operating systems and applications to share physical resources, and can also be called a Hypervisor.

[0025] The following is a brief description of several technical concepts involved in this embodiment.

[0026] IOPF (IO Page fault) is a page fault request initiated by an IO device. Currently, more and more IO devices begin to support the Page Request Interface (PRI) protocol, allowing IO devices to make page fault requests (Page Fault) in memory access scenarios like the CPU. In this way, in scenarios such as cloud computing, the restriction that the physical machine memory accessed by the IO device is not allowed to perform memory swap (Swap) can be lifted. In the following text, the page fault request initiated by the IO device is described as IOPF.

[0027] Memory swap technology is a technology that copies infrequently used memory pages to external storage areas such as disks, and releases physical machine memory to increase system available memory. Using memory swap technology can significantly improve the utilization rate of physical machine memory. This technology plays an important role in high-density memory data centers and cloud computing. However, memory swapping may cause the aforementioned page fault problem.

[0028] refer to Figure 2a , the physical machine in this embodiment is equipped with IO devices. The IO devices in this embodiment can be understood as PCI devices / PCIe devices, that is, external devices connected to the physical machine based on the bus protocol. In this embodiment, the types of IO devices installed on the physical machine are not limited. For example, the IO devices can be network card devices, GPUs (graphics processing units), DPUs (Data Processing Units), etc. Moreover, the physical machine in this embodiment may include multiple physical cores. In addition, the physical machine in this embodiment also runs virtual machines based on virtualization technology. The aforementioned virtual machine manager can be used to manage the virtual machines running on the physical machine.

[0029] In traditional page fault recovery schemes, the processing of IOPF is usually triggered by external interrupts in an asynchronous manner. Moreover, these interrupts are all processed by a designated physical core in the physical machine. In this way, as described in the background technology, all IOPF page fault recovery work occurring in the physical machine will be concentrated on the designated physical machine core, which will cause the aforementioned IOPF queuing problem and affect the processing efficiency of IOPF.

[0030] To this end, this embodiment proposes to add an IOPF scheduler in the virtual machine manager, and schedule the IOPFs occurring in the physical machine through the newly added IOPF scheduler. Compared with the traditional solution that all IOPFs are centrally processed by a designated physical core by default, this can effectively improve the processing efficiency of IOPFs. The IOPF scheduler in this embodiment can interact with other components in the virtual machine controller to implement the IOPF scheduling function.

[0031] On this basis, reference Figure 1 The IOPF scheduler proposed in this embodiment can execute the following page fault recovery method:

[0032] Step 100: When any IO device on the physical machine is detected to initiate an IOPF, determine the target virtual machine to which the IOPF belongs;

[0033] Step 101, selecting a target physical core for processing IOPF for a target virtual machine from multiple physical cores;

[0034] Step 102: Schedule the IOPF to the target physical core, so as to utilize the target physical core to process the IOPF.

[0035] Figure 2b An exemplary structural diagram of an IOPF scheduler provided by an exemplary embodiment of the present application, refer to Figure 2b In this embodiment, based on the IOPF scheduler, it is further proposed that the IOPF scheduler can be divided into at least two layers: a hardware abstraction layer and a kernel layer. The hardware abstraction layer is used to connect to the page request interface used by the IO device to provide the IOPF sent from the hardware interface to the kernel layer.

[0036] In this embodiment, based on the hardware abstraction layer, the monitoring of IOPF under various IOPF implementation architectures can be supported. To this end, in this embodiment, the hardware abstraction layer may include a driver for connecting to the page request interface under different IOPF implementation architectures. Figure 2b , two exemplary IOPF implementation architectures may be: the IO device initiates IOPF based on the PRI interface in the input-output memory management unit IOMMU; the IO device itself has a built-in custom page request interface, and initiates IOPF based on its own built-in custom page request interface. In response to these two exemplary IOPF implementation architectures, the hardware abstraction layer in this embodiment may at least include a driver for docking the PRI interface in the IOMMU and a driver for docking the built-in custom page request interface of the IO device. Of course, the hardware abstraction layer in this embodiment may also include more page request interface drivers for docking more page request interfaces in IOPF implementation architectures, which are not listed here exhaustively. It is worth noting that Figure 2bIn the two exemplary IOPF implementation architectures, the PRI interface in the IOMMU refers to a page request interface that complies with the conventional page request interface protocol (Page Request Interface, PRI); and the custom page request interface built into the IO device itself can comply with the custom page request interface protocol. The custom page request interface protocol is not described in detail here. This embodiment can support various custom page request interface protocols.

[0037] Thus, in this embodiment, based on the hardware abstraction layer in the IOPF scheduler, it can support docking with more IOPF implementation architectures, rather than just the IOMMU, and can convert the hardware IOPF received from different IOPF implementation architectures into a consistent abstract IOPF to provide to the kernel layer, without the need to modify other components in the VMM.

[0038] Based on this, reference Figure 1 In step 100, the IOPF scheduler may monitor the IOPF initiated by the IO device installed on the physical machine. Here, as mentioned above, the IOPF may be initiated by the IO device based on its own built-in custom page request interface, or may be initiated based on the PRI interface in the IOMMU. Figure 1 In step 100, when an IOPF is detected, it is not directly submitted to the default physical kernel for page fault recovery in the traditional solution. Instead, as described in step 100, the target virtual machine to which the IOPF belongs is determined.

[0039] It is worth mentioning that in the traditional solution, the VMM does not pay attention to the virtual machine corresponding to the IOPF it receives. This is because the VMM only needs to submit all IOPFs to the designated physical core by default, and the designated physical core only needs to process each IOPF indiscriminately to ensure that the corresponding page faults are recovered. Neither party needs to pay attention to the initiator of the IOPF.

[0040] In this embodiment, it is innovatively proposed to determine the target virtual machine to which the IOPF belongs, thereby introducing the virtual machine as an important reference dimension and constraint condition for IOPF scheduling, which can effectively avoid disturbances to irrelevant virtual machines caused by the IOPF scheduling scheme introduced in this embodiment. Among them, irrelevant virtual machines can be understood as virtual machines that are irrelevant to the current IOPF.

[0041] In this embodiment, multiple implementation methods can be used to determine the target virtual machine to which the IOPF belongs. In an optional implementation method: the scheduling domain domain corresponding to the IOPF can be determined; based on the scheduling domain lists domain tables corresponding to each virtual machine running on the physical machine, the target virtual machine to which the IOPF belongs is queried, wherein the scheduling domain list corresponding to the target virtual machine contains the scheduling domain corresponding to the IOPF.

[0042] In actual applications, in order to achieve device pass-through, scheduling domain lists domain tables are usually configured for different virtual machines respectively to restrict the various VF (Virtual Function) devices under the scheduling domain list belonging to a single virtual machine to share the same page table for direct memory access (Direct Memory Access, DMA), thereby ensuring that the page tables used to achieve device pass-through access in different virtual machines are different, that is, to ensure that the device pass-through access in different virtual machines is isolated from each other. Among them, VF devices are virtual devices generated by virtualizing IO devices, and these virtual devices can be installed on different virtual machines as needed. The background knowledge about scheduling domains will not be introduced further here. In this implementation method, the scheduling domain lists domain tables corresponding to each virtual machine running on the physical machine can be obtained from other components in the VMM, for example, related components for docking with device pass-through protocols such as VFIO, etc., which are not limited here.

[0043] In this implementation, an exemplary scheme for determining the scheduling domain corresponding to the IOPF may be: parsing the IO device information corresponding to the IO device that triggers the IOPF from the IOPF; based on the mapping relationship table between the IO device identifier and the scheduling domain, querying the scheduling domain mapped to the IO device identifier corresponding to the IOPF as the scheduling domain corresponding to the IOPF. Among them, the mapping relationship table can be obtained from other components in the VMM. It should be understood that the scheduling domain list of a single virtual machine usually contains multiple scheduling domains. The VF device mentioned above is divided into the scheduling domain, and the IO device corresponding to the VF device will also be divided into the corresponding scheduling domain, thereby generating the mapping relationship table. In this exemplary scheme, when the IO device initiates the IOPF based on the page request interface, it can carry its own device identifier (Source Identifier) ​​in the IOPF. For example, the IO device identifier can be BDF information, that is, bus BUS, device Device and function Func information, to support the determination of the corresponding scheduling domain for the IOPF by querying the mapping relationship table.

[0044] Based on this, in this implementation, the IOPF scheduler can have the same resource management perspective within the scheduling domain as the VMM, so that the target virtual machine to which the current IOPF belongs can be determined by comparing the scheduling domain corresponding to the IOPF with the scheduling domain list corresponding to each virtual machine running on the physical machine.

[0045] It should be understood that the technical details in the above implementation are only exemplary and not limited thereto. In addition, in this embodiment, other implementations may be used to determine the virtual machine to which the IOPF belongs, but are not limited thereto, and no further examples are given here.

[0046] Continue to refer Figure 1 After determining the target virtual machine described in the IOPF, in step 101, a target physical core for processing the IOPF can be selected from multiple physical cores for the target virtual machine. Based on the target virtual machine introduced in step 100, it is proposed in step 101 to convert the scheduling problem in units of IOPF into a scheduling problem in units of target virtual machines. In this way, in step 101, a target physical core can be selected from the physical cores that can be occupied by the target virtual machine on the physical machine to process the current IOPF. Among them, the physical core that can be occupied by the target virtual machine can be understood as a physical core that is not occupied or locked by other virtual machines.

[0047] Based on this, in step 101, the target virtual machine is actually used as the scheduling unit and the scheduling constraint condition of not interfering with the operation of irrelevant virtual machines as much as possible is used to perform IOPF scheduling. In this way, the target physical core can be selected more reasonably, and the interference of irrelevant virtual machines in the IOPF scheduling work can be effectively avoided.

[0048] For example, if the current IOPF belongs to virtual machine A, then in step 101, the IOPF can be avoided from being scheduled to a physical core occupied or locked by other virtual machines as much as possible, so as to avoid resource preemption of other virtual machines and cross-virtual machine attacks. In actual applications, if resource preemption occurs, it is likely to cause failures of other virtual machines, and this embodiment can effectively avoid this problem.

[0049] There are many implementation schemes for selecting the target physical core in step 101, which will be described in detail in the following embodiments and are not limited too much here.

[0050] After selecting the target physical core, refer to Figure 1In step 102, the IOPF may be dispatched to the target physical core so as to process the IOPF using the target physical core. Processing the IOPF using the target physical core means using the target physical core to perform page fault recovery according to the IOPF. In this embodiment, the page fault recovery process may include but is not limited to allocating free physical pages for the page faults, reading the page fault data from the external storage device, and storing the page fault data in the free physical pages allocated above, etc., which will not be described in detail here.

[0051] In this embodiment, multiple implementations can be used to schedule IOPF to the target physical core. In an optional implementation: when a page fault interrupt corresponding to IOPF is detected on a specified physical core in a physical machine, the specified physical core is prohibited from starting the page fault recovery task corresponding to the IOPF; the page fault recovery task is scheduled to the target physical core; wherein the specified physical core is the default core for page fault recovery. Among them, VMM has the function of sensing page fault interrupts, which is because the interrupt handler is registered by VMM to the page fault interrupt. Based on this, in this implementation, the page fault interrupt corresponding to IOPF can be monitored from the relevant components in VMM. It is worth noting that the page fault interrupt and the aforementioned page fault request (that is, IOPF) are not the same concept. In addition to issuing IOPF, the IO device will also issue a page fault interrupt corresponding to IOPF to the specified physical core. In this implementation, the page fault request can be triggered by the aforementioned input and output memory management unit IOMMU, or by the custom page request interface built into the IO device. Of course, in other IOPF implementation architectures, it can also be triggered by other subjects, which is not limited here.

[0052] According to the traditional scheme, the designated physical core will receive the IOPF, and when receiving the corresponding page fault interrupt, it will stop other work and start the corresponding page fault recovery task for the page fault interrupt. In this implementation, the designated physical core will be prohibited from starting the corresponding page fault recovery task, and the page fault recovery task will be scheduled to the target physical core.

[0053] In an exemplary solution: the designated physical core can be controlled to remotely call the target physical core so as to utilize the target physical core to process the page fault recovery task. The remote call technology between physical cores will not be described in detail here. Based on the remote call technology between physical cores, there is no need to migrate tasks, and the target physical core can be triggered to perform the page fault recovery task by initiating a simple remote call request. Of course, in this implementation, other exemplary solutions can also be used to schedule the page fault recovery task to the target physical core. For example, the page fault recovery task on the designated physical core is migrated to the target physical core as a whole. For another example, on the one hand, the designated physical core can be controlled to send an interrupt for the current IOPF to the target physical core; on the other hand, the identification information of the target physical core can be notified to the memory management unit (Memory Management, MM) in the VMM, so that the memory management unit forwards the page fault request to the target physical core, so that the target physical core starts processing the IOPF when receiving the interrupt sent by the designated physical core. No more examples are given here.

[0054] In summary, in this embodiment, it is innovatively proposed to add a scheduling function for IOPF in the virtual machine manager. In response to monitoring a page fault request initiated by any IO device on the physical machine, the target virtual machine to which the page fault request belongs can be determined; a target physical core for processing the page fault request is selected from the multiple physical cores for the target virtual machine; and the page fault request is scheduled to the target physical core to use the target physical core to process the page fault request. In this way, by clarifying the virtual machines to which each IOPF occurring in the physical machine belongs, IOPF scheduling can be performed with the virtual machine as a constraint condition, which can not only avoid IOPF being concentrated on a designated physical core on the physical machine for processing, but also effectively avoid IOPF scheduling causing disturbances to unrelated virtual machines, thereby ensuring reasonable scheduling of IOPF and further improving the processing efficiency of IOPF.

[0055] Figure 3 A flowchart of a missing page recovery method provided by another exemplary embodiment of the present application. Figure 3 , the method may include:

[0056] Step 300: When any IO device on the physical machine is detected to initiate an IOPF, determine the target virtual machine to which the IOPF belongs;

[0057] Step 301: Based on the association and use relationship between the idle physical cores and the virtual machines, determine whether the target virtual machine is associated with an idle physical core;

[0058] Step 302: If yes, use the idle physical core associated with the target virtual machine as the target physical core;

[0059] Step 303: Schedule the IOPF to the target physical core, so as to use the target physical core to process the IOPF.

[0060] Among them, step 300 and step 303 can refer to the description of steps 100 and 102 in the above-mentioned embodiment, and will not be repeated here.

[0061] In this embodiment, an optional implementation method for determining a target physical core is provided. Figure 4 The following is a logical diagram of this optional implementation.

[0062] refer to Figure 4 In the 3a link, in this optional implementation: based on the association and use relationship between the idle physical core and the virtual machine, it can be determined whether the target virtual machine is associated with an idle physical core; if so, the idle physical core that has an association and use relationship with the target virtual machine is used as the target physical core. Among them, the association and use relationship describes the idle physical cores that can be used by the relevant virtual machines in the physical machine. In this optional implementation, the storage structure of the association and use relationship is not limited. For example, the association and use relationship can use a key-value pair to record the idle physical cores that can be used by the relevant virtual machines, wherein the identifier of the virtual machine can be used as the key, and the identifier of the idle physical core can be used as the value. Based on this, if the identifier of the target virtual machine is found in the association and use relationship, it can be determined that the target virtual machine is associated with an idle physical core, otherwise, it can be determined that the target virtual machine is not associated with an idle physical core. Of course, other storage structures can also be used to implement the association and use relationship, and no more examples are given here.

[0063] In this optional implementation, the idle physical cores on the physical machine can be obtained from other components in the VMM, wherein the idle physical cores refer to the physical cores that do not host any virtual machines. It can be seen that using the idle physical cores to process page fault requests will not interfere with the operation of any virtual machine. Therefore, in this optional implementation, if the target virtual machine is associated with an idle physical core, the idle physical core associated with it can be directly used as the target physical core.

[0064] In this optional implementation, the association and use relationship between the idle physical cores and virtual machines used above can be dynamically maintained. In an exemplary scheme: page fault recovery threads can be created in the idle physical cores in the physical machine to form a page fault recovery thread pool; the page fault recovery threads in the page fault recovery thread pool are assigned to the virtual machines running in the physical machine to generate an association and use relationship between the idle physical cores and the virtual machines; wherein the virtual machine exclusively occupies the page fault recovery thread assigned to it, and the virtual machine has an association and use relationship with the idle physical core to which the page fault recovery thread assigned to it belongs. In addition, the association and use relationship can be stored in the memory of the physical machine for on-demand calling by the IOPF in this embodiment. Of course, it can also be stored in a storage device external to the physical machine or an associated remote storage device. This embodiment does not limit this. This embodiment supports storing the association and use relationship in any storage location that the physical machine can access and update in a timely manner.

[0065] In this optional implementation, it is proposed that Figure 4 It should be understood that the number of page fault recovery threads in the page fault recovery thread pool changes dynamically, and by allocating page fault recovery threads in the pool to virtual machines in a physical machine, an associated use relationship between the idle physical cores to which the page fault recovery threads belong and the virtual machines can be indirectly established.

[0066] Among them, an exemplary page fault recovery thread allocation scheme can be: if the number of page fault recovery threads in the page fault recovery thread pool is greater than or equal to the number of virtual cores, then each virtual machine running on the physical machine is respectively allocated a page fault recovery thread to generate an associated use relationship between idle physical cores and virtual machines; if the number of page fault recovery threads in the page fault recovery thread pool is less than the number of virtual cores, then some virtual machines running on the physical machine are respectively allocated page fault recovery threads to generate an associated use relationship between idle physical cores and virtual machines; wherein a single virtual machine may contain one or more virtual cores. In actual applications, a single virtual machine may be allocated to one or more page fault recovery threads. For example, when a virtual machine contains multiple virtual cores, multiple page fault recovery threads may be allocated to it to cope with the problem that multiple IOPFs may occur in parallel.

[0067] In this exemplary page fault recovery thread allocation scheme, two situations are considered. In one situation, there are enough page fault recovery threads in the page fault recovery thread pool, and each virtual machine can be allocated a sufficient number of page fault recovery threads, so that each virtual machine will be associated with an idle physical core. In another situation, the number of page fault recovery threads in the page fault recovery thread pool is insufficient, which will inevitably lead to some virtual machines being unable to be allocated page fault recovery threads. In this case, the virtual machines in the physical machine can be sorted based on indicators such as priority, and page fault recovery threads are preferentially allocated to the virtual machines in the front order. In this way, some virtual machines running on the physical machine can be associated with idle physical cores, while the remaining virtual machines will not be associated with idle physical cores.

[0068] In addition, in this exemplary solution, the change of idle physical cores in the physical machine (for example, the occurrence of a virtual machine creation event, etc.) can be sensed by interacting with other components in the VMM, and when the number of idle physical cores in the physical machine is sensed to have changed, the associated use relationship between the idle physical cores and the virtual machine is updated. In this way, the accuracy of the associated use relationship can be guaranteed by low-frequency updates.

[0069] Of course, in this implementation, other solutions can also be used to maintain the associated use relationship between the idle physical core and the virtual machine, but it is not limited to this. The relevant information required for maintaining this associated use relationship in different solutions can be obtained through interaction with other components in the VMM.

[0070] Further, refer to Figure 3 as well as Figure 4 In step 3b, if it is determined in step 301 that the target virtual machine is not associated with an idle physical core, the page fault recovery method provided in this embodiment may also include step 304: selecting a target virtual core from the virtual cores included in the target virtual machine; and using the physical core where the target virtual core is located as the target physical core.

[0071] An exemplary target virtual core selection scheme may be: obtaining the load rates of the virtual cores included in the target virtual machine; and selecting the virtual core whose load rate meets the specified requirement as the target virtual core. Figure 4In actual applications, the load rates corresponding to the virtual cores contained in the target virtual machine can be inquired from the virtual machine scheduler used in virtualization technology (for example, KVM and other technologies). Furthermore, in this exemplary target virtual core selection scheme, if there is no virtual core whose load rate meets the specified requirements, the virtual core hit in this round is used as the target virtual core according to the polling mechanism. Among them, the polling mechanism can be implemented by round robin or multi-queue receiving RSS (receive sidescaling) and other technologies, which are not limited here. Through the polling mechanism, the page fault requests can be evenly distributed to the physical cores where the virtual cores contained in the target virtual machine are located.

[0072] In this exemplary target virtual core selection scheme, the preset specified requirements for the load rate may include but are not limited to the lowest load rate, the load rate is lower than the specified load rate threshold and the duration exceeds the specified duration threshold, or the load rate is lower than the specified load rate threshold and no more loads are locked, etc.

[0073] For example, if the specified requirement is "lowest load rate," then a virtual core with the lowest load rate may be selected from the virtual cores included in the target virtual machine as the target virtual core.

[0074] For example, if the specified requirement is "the load rate is lower than the specified load rate threshold and the duration exceeds the specified duration threshold", a virtual machine core that meets both the load rate and duration requirements can be selected from the virtual cores included in the target virtual machine as the target virtual core. The duration refers to the duration for which the load rate is continuously kept below the specified load rate threshold. If there are multiple virtual cores that meet the specified requirement, the one with the longest duration can be further selected as the target virtual core. In this way, virtual cores with too high load rates or insufficient duration of low load rate states will not be selected.

[0075] For example, if the specified requirement is "the load rate is lower than the specified load rate threshold and no more loads are locked", then a virtual core with a sufficiently low load rate and no additional loads locked by other tasks can be selected from the virtual cores of the target virtual machine as the target virtual core. In actual applications, there may be some high-priority tasks in the physical machine that will pre-lock some virtual cores, and the locked virtual cores will not be available for other tasks. In this case, through this specified requirement, virtual cores that have a sufficiently low load rate but have been locked by other tasks will not be selected.

[0076] Based on this, in this embodiment, the constraints at the virtual machine level and the actual load of each physical core in the physical machine can be fully considered, so as to select a suitable target physical core for the page fault request. In this way, most page fault requests can be scheduled to be processed on idle physical cores, and when a few page fault requests need to be scheduled to non-idle physical cores, the operation requirements of other virtual machines are also fully considered. These page fault requests will be scheduled to the physical cores that the target virtual machine originally needs to occupy, and the physical core with the lowest load rate is selected from them to better avoid interference with other virtual machines on the selected non-idle physical cores.

[0077] It should be noted that in some of the processes described in the above embodiments and the accompanying drawings, multiple operations appearing in a specific order are included, but it should be clearly understood that these operations may not be executed in the order in which they appear in this document or may be executed in parallel, and the sequence numbers of the operations, such as 801, 802, etc., are only used to distinguish between different operations, and the sequence numbers themselves do not represent any execution order. In addition, these processes may include more or fewer operations, and these operations may be executed in sequence or in parallel.

[0078] Figure 5 A schematic diagram of a computing device provided by another exemplary embodiment of the present application is shown in FIG. Figure 5 As shown, the computing device includes: a memory 50 and a processor 51. The computing device is equipped with an IO device 52 and includes multiple physical cores, wherein the processor 51 is a physical core for running a virtual machine manager.

[0079] The processor 51 is coupled to the memory 50 and the IO device 52, and is used to execute the computer program in the memory 50, so as to:

[0080] In the case where any IO device 52 on the physical machine is monitored to initiate a page fault request, determining a target virtual machine to which the page fault request belongs;

[0081] Selecting a target physical core for processing a page fault request for the target virtual machine from the multiple physical cores;

[0082] The page fault request is dispatched to the target physical core so as to utilize the target physical core to process the page fault request.

[0083] In an optional embodiment, when determining the target virtual machine to which the page fault request belongs, the processor 51 may specifically be configured to:

[0084] Determine the scheduling domain domain corresponding to the page fault request;

[0085] Based on the domain tables corresponding to each virtual machine running on the physical machine, the target virtual machine to which the page fault request belongs is queried, wherein the scheduling domain list corresponding to the target virtual machine contains the scheduling domain corresponding to the page fault request.

[0086] In an optional embodiment, when the processor 51 selects a target physical core for processing a page fault request for the target virtual machine from the multiple physical cores, it may be specifically configured to:

[0087] Based on the association and use relationship between the idle physical cores and the virtual machines, determining whether the target virtual machine is associated with an idle physical core;

[0088] If so, an idle physical core associated with the target virtual machine is used as the target physical core.

[0089] In an optional embodiment, the processor 51 may also be configured to:

[0090] If not, selecting a target virtual kernel from the virtual kernels included in the target virtual machine;

[0091] The physical core where the target virtual core is located is used as the target physical core.

[0092] In an optional embodiment, the processor 51 may also be configured to:

[0093] Creating page fault recovery threads in idle physical cores in the physical machine respectively to form a page fault recovery thread pool;

[0094] Allocating the page fault recovery threads in the page fault recovery thread pool to the virtual machines running in the physical machine to generate an associated use relationship between the idle physical cores and the virtual machines;

[0095] The virtual machine exclusively occupies the page fault recovery thread allocated to it, and there is an associated use relationship between the virtual machine and the idle physical core to which the page fault recovery thread allocated to it belongs.

[0096] In an optional embodiment, when the processor 51 allocates the page fault recovery thread in the page fault recovery thread pool to the virtual machine running in the physical machine to generate an associated use relationship between the idle physical core and the virtual machine, it can be specifically used to:

[0097] If the number of page fault recovery threads in the page fault recovery thread pool is greater than or equal to the number of virtual cores, a page fault recovery thread is allocated to each virtual machine running on the physical machine to generate an associated use relationship between the idle physical cores and the virtual machines;

[0098] If the number of page fault recovery threads in the page fault recovery thread pool is less than the number of virtual cores, respectively allocating page fault recovery threads to some virtual machines running on the physical machine to generate an associated use relationship between the idle physical cores and the virtual machines;

[0099] A single virtual machine includes one or more virtual cores.

[0100] In an optional embodiment, when the processor 51 selects the target virtual kernel from the virtual kernels included in the target virtual machine, it can be specifically used to:

[0101] Obtaining the load rates corresponding to the virtual cores included in the target virtual machine;

[0102] A virtual core whose load rate is lower than the specified requirement is used as the target virtual core.

[0103] In an optional embodiment, the processor 51 may also be configured to:

[0104] If there is no virtual core whose load rate is lower than the specified requirement, the virtual core hit in this round is used as the target virtual core according to the polling mechanism.

[0105] In an optional embodiment, when the processor 51 schedules the page fault request to the target physical core, it can be specifically used to:

[0106] When a page fault interrupt corresponding to the page fault request is detected on a designated physical core in the physical machine, prohibiting the designated physical core from starting a page fault recovery task corresponding to the page fault request;

[0107] Scheduling the page fault recovery task to the target physical core;

[0108] The designated physical kernel is a default kernel for page fault recovery.

[0109] In an optional embodiment, when the processor 51 schedules the page fault recovery task to the target physical core, it can be specifically used to:

[0110] The designated physical core is controlled to remotely call the target physical core, so as to utilize the target physical core to process the page fault recovery task.

[0111] In an optional embodiment, the page fault request is triggered by an input-output memory management unit IOMMU, or by a custom page request interface built into the IO device;

[0112] Among them, the virtual machine manager is deployed with a hardware abstraction layer and a kernel layer for scheduling page fault requests, the hardware abstraction layer includes a driver for docking with the PRI interface in the IOMMU and a driver for docking with the custom page request interface built into the IO device, so as to provide the received page fault requests to the kernel layer, and the kernel layer is used to schedule the page fault requests.

[0113] Further, if Figure 5 As shown, the computing device also includes: a communication component 53, a power supply component 54 and other components. Figure 5 Only some components are shown schematically, and it does not mean that the computing device only includes Figure 5 Components shown.

[0114] It is worth noting that the technical details in the above-mentioned embodiments of the computing device can refer to the relevant description in the aforementioned method embodiment. In order to save space, they will not be repeated here, but this should not cause a loss in the scope of protection of this application.

[0115] Accordingly, an embodiment of the present application further provides a computer-readable storage medium storing a computer program, which, when executed, can implement the steps that can be executed by a computing device in the above method embodiment.

[0116] Above Figure 5 The memory in the computer is used to store computer programs and can be configured to store various other data to support operations on the computing platform. Examples of such data include instructions for any application or method operating on the computing platform, contact data, phone book data, messages, pictures, videos, etc. The memory can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disk or optical disk.

[0117] Above Figure 5The communication component in is configured to facilitate wired or wireless communication between the device where the communication component is located and other devices. The device where the communication component is located can access a wireless network based on a communication standard, such as WiFi, 2G, 3G, 4G / LTE, 5G and other mobile communication networks, or a combination thereof. In an exemplary embodiment, the communication component receives a broadcast signal or broadcast-related information from an external broadcast management system via a broadcast channel. In an exemplary embodiment, the communication component also includes a near field communication (NFC) module to facilitate short-range communication. For example, the NFC module can be implemented based on radio frequency identification (RFID) technology, infrared data association (IrDA) technology, ultra-wideband (UWB) technology, Bluetooth (BT) technology and other technologies.

[0118] Above Figure 5 The power supply component in the device provides power to various components of the device where the power supply component is located. The power supply component may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to the device where the power supply component is located.

[0119] Those skilled in the art will appreciate that the embodiments of the present application may be provided as methods, systems, or computer program products. Therefore, the present application may adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment in combination with software and hardware. Moreover, the present application may adopt the form of a computer program product implemented in one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) that include computer-usable program code.

[0120] The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0121] These computer program instructions may also be stored in a computer readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer readable memory produce an article of manufacture including an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1A function specified in one or more boxes.

[0122] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

[0123] It should also be noted that the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, commodity or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, commodity or device. In the absence of more restrictions, the elements defined by the sentence "comprises a ..." do not exclude the existence of other identical elements in the process, method, commodity or device including the elements.

[0124] 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 this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and provide corresponding operation entrances for users to choose to authorize or refuse.

[0125] The above is only the embodiment of the present application and is not intended to limit the present application. For those skilled in the art, the present application may have various changes and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application should be included in the protection scope of the present application.

Claims

1. A page fault recovery method, applicable to a virtual machine manager in a physical machine, wherein the physical machine is equipped with an IO device and includes multiple physical cores, the method comprising: In the case of monitoring that any IO device on the physical machine initiates a page fault request, determining a target virtual machine to which the page fault request belongs; Selecting a target physical core for processing a page fault request for the target virtual machine from the multiple physical cores; The page fault request is dispatched to the target physical core so as to utilize the target physical core to process the page fault request.

2. The method according to claim 1, determining the target virtual machine to which the page fault request belongs, comprising: Determine the scheduling domain domain corresponding to the page fault request; Based on the domain tables corresponding to each virtual machine running on the physical machine, the target virtual machine to which the page fault request belongs is queried, wherein the scheduling domain list corresponding to the target virtual machine contains the scheduling domain corresponding to the page fault request.

3. The method according to claim 1, selecting a target physical core for processing a page fault request for the target virtual machine from the multiple physical cores, comprising: Based on the association and use relationship between the idle physical cores and the virtual machines, determining whether the target virtual machine is associated with an idle physical core; If so, an idle physical core associated with the target virtual machine is used as the target physical core.

4. The method according to claim 3, further comprising: If not, selecting a target virtual kernel from the virtual kernels included in the target virtual machine; The physical core where the target virtual core is located is used as the target physical core.

5. The method according to any one of claims 3 or 4, further comprising: Creating page fault recovery threads in idle physical cores in the physical machine respectively to form a page fault recovery thread pool; Allocating the page fault recovery threads in the page fault recovery thread pool to the virtual machines running in the physical machine to generate an associated use relationship between the idle physical cores and the virtual machines; The virtual machine exclusively occupies the page fault recovery thread allocated to it, and there is an associated use relationship between the virtual machine and the idle physical core to which the page fault recovery thread allocated to it belongs.

6. The method according to claim 5, allocating the page fault recovery threads in the page fault recovery thread pool to the virtual machines running in the physical machine to generate an associated use relationship between the idle physical cores and the virtual machines, comprising: If the number of page fault recovery threads in the page fault recovery thread pool is greater than or equal to the number of virtual cores, a page fault recovery thread is allocated to each virtual machine running on the physical machine to generate an associated use relationship between the idle physical cores and the virtual machines; If the number of page fault recovery threads in the page fault recovery thread pool is less than the number of virtual cores, respectively allocating page fault recovery threads to some virtual machines running on the physical machine to generate an associated use relationship between the idle physical cores and the virtual machines; A single virtual machine includes one or more virtual cores.

7. The method according to claim 4, selecting a target virtual kernel from the virtual kernels included in the target virtual machine, comprising: Obtaining the load rates corresponding to the virtual cores included in the target virtual machine; The virtual core whose load rate meets the specified requirement is used as the target virtual core.

8. The method according to claim 7, further comprising: If there is no virtual core whose load rate meets the specified requirement, the virtual core hit in this round is used as the target virtual core according to the polling mechanism.

9. The method according to claim 7, wherein the specified requirements include the lowest load rate, the load rate being lower than a specified load rate threshold and lasting for a period exceeding a specified time threshold, or the load rate being lower than the specified load rate threshold and no more loads are locked.

10. The method according to claim 1, scheduling the page fault request to the target physical core, comprising: When a page fault interrupt corresponding to the page fault request is detected on a designated physical core in the physical machine, prohibiting the designated physical core from starting a page fault recovery task corresponding to the page fault request; Scheduling the page fault recovery task to the target physical core; The designated physical kernel is a default kernel for page fault recovery.

11. The method according to claim 10, scheduling the page fault recovery task to the target physical core, comprising: The designated physical core is controlled to remotely call the target physical core, so as to utilize the target physical core to process the page fault recovery task.

12. The method according to claim 1, wherein the page fault request is triggered by an input / output memory management unit (IOMMU) or a custom page request interface built into the IO device; in, The virtual machine manager is deployed with a hardware abstraction layer and a kernel layer for scheduling page fault requests. The hardware abstraction layer includes a driver for docking with the PRI interface in the IOMMU and a driver for docking with the custom page request interface built into the IO device, so as to provide the received page fault requests to the kernel layer, and the kernel layer is used to schedule the page fault requests.

13. A computing device comprising a memory, a processor, and a communication component; The memory is used to store one or more computer instructions; The processor is coupled to the memory and the communication component, and is configured to execute the one or more computer instructions to execute the page fault recovery method according to any one of claims 1 to 12.

14. A computer-readable storage medium storing computer instructions, which, when executed by one or more processors, causes the one or more processors to execute the page fault recovery method according to any one of claims 1 to 12.

Images