Page fault recovery method, device, and storage medium

Abstract

A page fault recovery method, a device, and a storage medium. The method comprises: in response to monitoring a page fault request initiated by any IO device on a physical machine, determining a target virtual machine to which the page fault request belongs; for the target virtual machine, selecting, from among a plurality of physical kernels, a target physical kernel for processing the page fault request; and scheduling the page fault request to the target physical kernel so as to use the target physical kernel to process the page fault request. By determining virtual machines to which IOPFs occurring in a physical machine belongs, IOPF scheduling can be performed by using the virtual machines as a constraint condition, so that the IOPFs can be prevented from being concentrated on a designated physical kernel on the physical machine for processing, and disturbance to unrelated virtual machines caused by the IOPF scheduling can be effectively avoided, thereby ensuring rational scheduling of the IOPFs, and further improving the processing efficiency of the IOPFs.

Description

A missing page recovery method, device and storage medium

[0001] This application claims priority to the Chinese patent application filed with the China Patent Office on August 16, 2023, with application number 202311046986.1 and application name “A Page Missing Recovery Method, Device and Storage Medium”, the entire contents of which are incorporated by reference into this application. Technical Field

[0002] 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

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

[0004] Currently, in physical machines with multi-core processors, page fault requests initiated by various IO devices connected to the physical machine are concentrated on a designated physical core for processing. This not only puts huge workload on the physical core, but also causes queuing problems in page fault recovery, affecting the efficiency of page fault recovery.

[0005] Summary of the Invention

[0006] Various aspects of the present application provide a method, device, and storage medium for recovering a page fault, so as to improve the processing efficiency of an IOPF.

[0007] An embodiment of the present application provides 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 includes:

[0008] 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;

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

[0010] The page fault request is dispatched to the target physical core, so that the target physical core is used to process the page fault request.

[0011] An embodiment of the present application further provides a computing device, including a memory, a processor, and a communication component;

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

[0013] 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.

[0014] An embodiment of the present application further 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.

[0015] 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 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 not only avoids the IOPF being concentrated on a designated physical core on the physical machine for processing, but also effectively avoids the disturbance caused by IOPF scheduling to irrelevant virtual machines, thereby ensuring the reasonable scheduling of IOPF and further improving the processing efficiency of IOPF. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] 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:

[0017] FIG1 is a flow chart of a method for recovering a missing page according to an exemplary embodiment of the present application;

[0018] FIG2a is a logical diagram of a page fault recovery method provided by an exemplary embodiment of the present application;

[0019] FIG2 b is a schematic diagram of an exemplary structure of an IOPF scheduler provided by an exemplary embodiment of the present application;

[0020] FIG3 is a flow chart of a method for recovering a missing page according to another exemplary embodiment of the present application;

[0021] FIG4 is a logic diagram of an optional implementation method provided by an exemplary embodiment of the present application;

[0022] FIG5 is a schematic structural diagram of a computing device provided by another exemplary embodiment of the present application. DETAILED DESCRIPTION

[0023] To make the purpose, technical solutions, and advantages of this application more clear, the technical solutions of this application will be clearly and completely described below in conjunction with the specific embodiments of this application and the corresponding drawings. Obviously, the embodiments described are only part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0024] At present, all IOPFs occurring on a physical machine are concentrated on a designated physical core for processing, 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; a target physical core for processing the page fault request can be selected from the multiple physical cores for the target virtual machine; and the page fault request can be 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 using the virtual machine as a constraint condition, which not only avoids IOPF being concentrated on a designated physical core on the physical machine for processing, but also effectively avoids IOPF scheduling causing disturbances to unrelated virtual machines, thereby ensuring reasonable scheduling of IOPF and improving the processing efficiency of IOPF.

[0025] The following describes in detail the technical solutions provided by various embodiments of the present application in conjunction with the accompanying drawings.

[0026] FIG1 is a flow chart illustrating a page fault recovery method provided in an exemplary embodiment of the present application. FIG2a is a logic diagram illustrating a page fault recovery method provided in an exemplary embodiment of the present application. Referring to FIG2a , the page fault recovery method provided in this embodiment can be implemented by a virtual machine monitor (VMM) in a physical machine. A virtual machine monitor (VMM) is an intermediate software layer running between underlying physical resources and an operating system, allowing multiple operating systems and applications to share physical resources. It is also called a hypervisor.

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

[0028] An IOPF (IO Page Fault) is a page fault request initiated by an IO device. Currently, an increasing number of IO devices support the Page Request Interface (PRI) protocol, enabling IO devices to perform page faults in memory access scenarios, similar to CPUs. This removes the restriction that prohibits memory swapping in the physical machine memory accessed by IO devices in scenarios such as cloud computing. Hereinafter, a page fault request initiated by an IO device will be referred to as an IOPF.

[0029] Memory swapping is a technology that copies infrequently used memory pages to external storage areas such as disks, freeing up physical machine memory and increasing system available memory. Using memory swapping can significantly improve physical machine memory utilization and plays a crucial role in high-density memory data centers and cloud computing. However, memory swapping can cause the aforementioned page fault problem.

[0030] Referring to Figure 2a, the physical machine in this embodiment is equipped with an IO device. The IO device in this embodiment can be understood as a PCI device / PCIe device, that is, an external device connected to the physical machine based on a bus protocol. In this embodiment, there is no limitation on the type of IO device installed on the physical machine. For example, the IO device can be a network card device, a GPU (graphics processing unit), a DPU (Data Processing Unit), etc. Moreover, the physical machine in this embodiment may include multiple physical cores. In addition, the physical machine in this embodiment also runs a virtual machine based on virtualization technology. The aforementioned virtual machine manager can be used to manage the virtual machines running on the physical machine.

[0031] In traditional page fault recovery schemes, IOP page fault recovery is typically triggered asynchronously by external interrupts. Furthermore, these interrupts are centrally handled by a specific physical core within the physical machine. As described in the background section, all IOP page fault recovery work occurring within the physical machine is centralized on this specific core, leading to the aforementioned IOP page fault queuing problem and affecting IOP page fault processing efficiency.

[0032] To this end, this embodiment proposes adding an IOPF scheduler to the virtual machine manager and using it to schedule IOPFs occurring on physical machines. Compared to the traditional solution where all IOPFs are centrally handled by a designated physical core, this effectively improves IOPF processing efficiency. The IOPF scheduler in this embodiment interacts with other components in the virtual machine controller to implement IOPF scheduling.

[0033] On this basis, referring to FIG1 , the IOPF scheduler proposed in this embodiment can execute the following page fault recovery method:

[0034] 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;

[0035] Step 101: Select a target physical core for processing IOPF for a target virtual machine from multiple physical cores;

[0036] Step 102: Schedule the IOPF to the target physical core to process the IOPF using the target physical core.

[0037] FIG2b is a schematic diagram of an exemplary structure of an IOPF scheduler provided in an exemplary embodiment of the present application. Referring to FIG2b , in addition to the proposed IOPF scheduler, this embodiment further proposes that the IOPF scheduler 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, thereby providing the IOPF sent from the hardware interface to the kernel layer.

[0038] 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. Wherein, referring to 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 connecting to the PRI interface in the IOMMU and a driver for connecting to 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 connecting to page request interfaces in more IOPF implementation architectures, which are not exhaustive here. It is worth noting that in the two exemplary IOPF implementation architectures in Figure 2b, 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); while the custom page request interface built into the IO device itself can comply with a 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.

[0039] Thus, in this embodiment, the hardware abstraction layer in the IOPF scheduler can support docking with more IOPF implementation architectures, not just the IOMMU. It can also convert hardware IOPFs received from different IOPF implementation architectures into a consistent abstract IOPF for provision to the kernel layer, without requiring modifications to other components in the VMM.

[0040] Based on this, referring to FIG1 , in step 100, the IOPF scheduler can monitor IOPFs initiated by IO devices installed on the physical machine. Here, as mentioned above, IOPFs can be initiated by the IO device based on its own built-in custom page request interface, or based on the PRI interface in the IOMMU. Referring to FIG1 , 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 for the IOPF.

[0041] It is worth noting 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.

[0042] This embodiment innovatively proposes determining the target virtual machine for an IOPF, thereby introducing the virtual machine as an important reference dimension and constraint for IOPF scheduling. This effectively prevents the IOPF scheduling scheme introduced in this embodiment from causing disturbances to unrelated virtual machines. Unrelated virtual machines can be understood as virtual machines that are not related to the current IOPF.

[0043] In this embodiment, various implementations can be used to determine the target virtual machine to which the IOPF belongs. In one optional implementation, the scheduling domain corresponding to the IOPF can be determined; based on the scheduling domain lists 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 includes the scheduling domain corresponding to the IOPF.

[0044] In actual applications, in order to achieve device direct access, scheduling domain lists domain tables are usually configured for different virtual machines separately 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 direct access in different virtual machines are different, that is, to ensure that the device direct 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 in detail 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, the relevant components used to connect to device direct access protocols such as VFIO, etc., which are not limited here.

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

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

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

[0048] Continuing with Figure 1 , after determining the target virtual machine for 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, step 101 proposes converting the scheduling problem based on the IOPF into a scheduling problem based on the target virtual machine. Thus, in step 101, a target physical core can be selected from the physical cores available for the target virtual machine on the physical machine to process the current IOPF. The physical cores available for the target virtual machine can be understood as physical cores that are not occupied or locked by other virtual machines.

[0049] Based on this, in step 101, IOPF scheduling is performed using the target virtual machine as the scheduling unit and using the constraint of minimizing interference with the operation of unrelated virtual machines as a scheduling constraint. This allows for more reasonable selection of the target physical core, effectively avoiding interference with unrelated virtual machines during IOPF scheduling.

[0050] For example, if the current IOPF belongs to virtual machine A, then in step 101, the IOPF can be avoided from being scheduled on a physical core occupied or locked by another virtual machine to prevent resource preemption for the other virtual machine and thus a cross-VM attack. In actual applications, resource preemption is likely to cause failures in other virtual machines, and this embodiment can effectively avoid this problem.

[0051] 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 here.

[0052] After selecting a target physical core, referring to FIG1 , in step 102, the IOPF can be dispatched to the target physical core so that the target physical core can process the IOPF. 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 fault, reading the page fault data from an external storage device, and storing the page fault data in the allocated free physical pages, which will not be described in detail here.

[0053] In this embodiment, various implementations can be used to schedule an IOPF to a target physical core. In one optional implementation, when a page fault interrupt corresponding to an IOPF is detected on a designated physical core in a physical machine, the designated physical core is prohibited from initiating a page fault recovery task corresponding to the IOPF; the page fault recovery task is scheduled to the target physical core; wherein the designated physical core is the default core for page fault recovery. The VMM has the ability to sense page fault interrupts because the interrupt handler is registered with the page fault interrupt by the VMM. Based on this, in this implementation, the page fault interrupt corresponding to the IOPF can be detected from relevant components in the VMM. It is worth noting that a page fault interrupt and the aforementioned page fault request (i.e., IOPF) are not the same concept. In addition to issuing an IOPF, the IO device also issues a page fault interrupt corresponding to the IOPF to the designated physical core. In this implementation, the page fault request can be triggered by the aforementioned input / output memory management unit (IOMMU) or by a custom page request interface built into the IO device. Of course, in other IOPF implementation architectures, it can also be triggered by other entities, which is not limited here.

[0054] According to the traditional solution, the designated physical core will receive the IOPF and, upon receiving the corresponding page fault interrupt, will stop other work and start the corresponding page fault recovery task for the page fault interrupt. In this implementation, the designated physical core is prohibited from starting the corresponding page fault recovery task, and the page fault recovery task is instead scheduled to the target physical core.

[0055] In one exemplary solution, a designated physical core can be controlled to remotely call a target physical core, thereby utilizing the target physical core to process page fault recovery tasks. While the remote call technology between physical cores will not be discussed in detail here, based on this technology, the target physical core can be triggered to execute the page fault recovery task by simply initiating a simple remote call request, without requiring task migration. Of course, within this implementation, other exemplary solutions can also be used to schedule the page fault recovery task to the target physical core. For example, the entire page fault recovery task on the designated physical core can be migrated to the target physical core. For another example, 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 (MM) in the VMM, so that the MM forwards the page fault request to the target physical core, thereby enabling the target physical core to initiate processing of the IOPF upon receiving the interrupt sent by the designated physical core. Further examples are not provided here.

[0056] 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 for the target virtual machine from the multiple physical cores; 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 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 not only avoids the IOPF being concentrated on a designated physical core on the physical machine for processing, but also effectively avoids the disturbance caused by IOPF scheduling to irrelevant virtual machines, thereby ensuring the reasonable scheduling of IOPF and further improving the processing efficiency of IOPF.

[0057] FIG3 is a flow chart of a method for recovering a missing page according to another exemplary embodiment of the present invention. Referring to FIG3 , the method may include:

[0058] 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;

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

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

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

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

[0063] In this embodiment, an optional implementation method for determining a target physical core is provided. FIG4 is a logical diagram of the optional implementation method.

[0064] Referring to step 3a in FIG4 , in this optional implementation, it is possible to determine whether the target virtual machine is associated with an idle physical core based on the associated usage relationship between the idle physical core and the virtual machine; if so, the idle physical core that is associated with the target virtual machine is used as the target physical core. The associated usage relationship describes the idle physical cores that can be used by each of the related virtual machines in the physical machine. The storage structure of the associated usage relationship is not limited in this optional implementation. For example, the associated usage relationship can use a key-value pair to record the idle physical cores that can be used by each of the related 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 associated usage 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 associated usage relationship, and no further examples are given here.

[0065] In this alternative implementation, idle physical cores on the physical machine can be obtained from other components in the VMM. Idle physical cores are physical cores that are not hosting any virtual machines. As can be seen, using idle physical cores to handle page fault requests does not interfere with the operation of any virtual machines. Therefore, in this alternative implementation, if the target virtual machine is associated with an idle physical core, the associated idle physical core can be directly used as the target physical core.

[0066] In this optional implementation, the association and usage relationship between the idle physical cores and virtual machines used above can be dynamically maintained. In an exemplary solution: page fault recovery threads can be created in the idle physical cores in the physical machine respectively 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 usage 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 usage relationship with the idle physical core to which the page fault recovery thread assigned to it belongs. In addition, the association and usage 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 usage relationship in any storage location that the physical machine can access and update in a timely manner.

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

[0068] An exemplary page fault recovery thread allocation scheme may 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 a page fault recovery thread is allocated to each virtual machine running on the physical machine to generate an associated usage 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 a page fault recovery thread is allocated to some virtual machines running on the physical machine to generate an associated usage 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 address the problem of multiple IOPFs occurring in parallel.

[0069] This exemplary page fault recovery thread allocation scheme considers two scenarios. In one scenario, there are sufficient page fault recovery threads in the page fault recovery thread pool, allowing each virtual machine to be allocated a sufficient number of page fault recovery threads. Consequently, each virtual machine is associated with an idle physical core. In another scenario, there are insufficient page fault recovery threads in the page fault recovery thread pool, which inevitably results in 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 metrics such as priority, with page fault recovery threads being allocated preferentially to the higher-ranked virtual machines. This way, some virtual machines running on the physical machine can be associated with idle physical cores, while the remaining virtual machines are not.

[0070] Furthermore, in this exemplary solution, the VMM can interact with other components in the physical machine to detect changes in the number of idle physical cores (e.g., when a virtual machine creation event occurs). Upon detecting a change in the number of idle physical cores in the physical machine, the association between the idle physical cores and the virtual machine usage is updated. This ensures the accuracy of the association through low-frequency updates.

[0071] Of course, in this implementation, other schemes can also be adopted to maintain the associated use relationship between the idle physical core and the virtual machine, and are not limited thereto. In different schemes, the relevant information required for maintaining this associated use relationship can be obtained by interacting with other components in the VMM.

[0072] Further, referring to Figure 3 and step 3b in Figure 4, 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.

[0073] An exemplary target virtual core selection scheme may be: obtaining the load rate corresponding to each virtual core contained in the target virtual machine; and using the virtual core whose load rate meets the specified requirements as the target virtual core. Referring to Figure 4, in actual applications, the load rate corresponding to each virtual core contained in the target virtual machine can be queried 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 will be used as the target virtual core according to the polling mechanism. Among them, the polling mechanism can be implemented using round robin or multi-queue receive RSS (receive side scaling) and other technologies, which are not limited here. Through the polling mechanism, page fault requests can be evenly distributed to the physical cores where the virtual cores contained in the target virtual machine are located.

[0074] 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 being lower than the specified load rate threshold and lasting for a period exceeding the specified time threshold, or the load rate being lower than the specified load rate threshold and not being locked with more loads, etc.

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

[0076] For example, if the specified requirement is "the load rate must be below a specified load rate threshold and the duration must exceed a specified duration threshold," then the target virtual core will be selected from the virtual cores in the target virtual machine that meet both the load rate and duration requirements. Duration refers to the duration for which the load rate remains below the specified load rate threshold. If multiple virtual cores meet this requirement, the one with the longest duration will be selected as the target virtual core. This prevents virtual cores with excessively high load rates or insufficient duration of low load rates from being selected.

[0077] For example, if the specified requirement is "the load rate is lower than the specified load rate threshold and no additional load is locked," then a virtual core with a sufficiently low load rate and no additional load locked by other tasks can be selected from the virtual cores of the target virtual machine as the target virtual core. In actual applications, some high-priority tasks on the physical machine may pre-lock some virtual cores, making these locked virtual cores unavailable for other tasks. In this case, using this specified requirement, virtual cores with sufficiently low load rates but already locked by other tasks will not be selected.

[0078] Based on this, this embodiment fully considers the constraints at the virtual machine level and the actual load of each physical core in the physical machine, thereby selecting the appropriate target physical core for the page fault request. In this way, the majority of page fault requests can be dispatched to idle physical cores for processing. When a few page fault requests need to be dispatched to non-idle physical cores, the operating needs of other virtual machines are fully considered. These page fault requests will be dispatched 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 among them to better avoid interference with other virtual machines on the selected non-idle physical core.

[0079] It should be noted that some of the processes described in the above embodiments and accompanying drawings include multiple operations that appear in a specific order. However, 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. The sequence numbers of the operations, such as 801 and 802, are merely used to distinguish between different operations and do not represent any execution order. In addition, these processes may include more or fewer operations, and these operations may be executed sequentially or in parallel.

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

[0081] The processor 51 is coupled to the memory 50 and the IO device 52, and is configured to execute the computer program in the memory 50 to:

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

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

[0084] The page fault request is dispatched to the target physical core, so that the target physical core is used to process the page fault request.

[0085] 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:

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

[0087] 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.

[0088] 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:

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

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

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

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

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

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

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

[0096] 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 usage relationship between the idle physical cores and the virtual machines;

[0097] 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.

[0098] 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 usage relationship between the idle physical core and the virtual machine, it can be specifically configured to:

[0099] 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 usage relationship between the idle physical cores and the virtual machines;

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

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

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

[0103] Obtaining the load rate corresponding to each virtual core included in the target virtual machine;

[0104] A virtual core with a load rate lower than the specified requirement is used as the target virtual core.

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

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

[0107] In an optional embodiment, when the processor 51 dispatches the page fault request to the target physical core, it may be specifically configured to:

[0108] 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;

[0109] Dispatching the page fault recovery task to the target physical core;

[0110] The designated physical core is a default core for page fault recovery.

[0111] In an optional embodiment, when scheduling the page fault recovery task to the target physical core, the processor 51 may be specifically configured to:

[0112] 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.

[0113] 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;

[0114] 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 connecting to the PRI interface in the IOMMU and a driver for connecting to the custom page request interface built into the IO device, so as to provide the received page fault request to the kernel layer, and the kernel layer is used to schedule the page fault request.

[0115] Furthermore, as shown in Figure 5 , the computing device further includes other components such as a communication component 53 and a power supply component 54. Figure 5 only schematically illustrates some components, which does not mean that the computing device only includes the components shown in Figure 5 .

[0116] It is worth noting that the technical details in the above-mentioned embodiments of the computing device can be referred 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 any loss of the scope of protection of this application.

[0117] 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.

[0118] The memory in Figure 5 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.

[0119] The communication component in Figure 5 above 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.

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

[0121] 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 combining software and hardware. Furthermore, the present application may adopt the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0122] The present application is described with reference to the flow chart and / or block diagram of the method, device (system), and computer program product according to the embodiment of the present application. It should be understood that each flow process and / or box in the flow chart and / or block diagram and the combination of the flow process and / or box in the flow chart and / or block diagram can be realized 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 processing machine or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device produce a device for realizing the function specified in one flow chart flow or multiple flows and / or one box or multiple boxes of the block diagram.

[0123] These computer program instructions may also be stored in a computer-readable memory that can direct 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 a product including an instruction device that implements the functions specified in one or more processes in the flowchart and / or one or more boxes in the block diagram.

[0124] 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, so that the instructions executed on the computer or other programmable device provide steps for implementing the functions specified in one or more processes in the flowchart and / or one or more boxes in the block diagram.

[0125] It should also be noted that the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, commodity, or apparatus that includes a series of elements includes not only those elements but also other elements not explicitly listed, or includes elements inherent to such process, method, commodity, or apparatus. In the absence of further limitations, an element defined by the phrase "comprises a ..." does not exclude the presence of other identical elements in the process, method, commodity, or apparatus that includes the element.

[0126] 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 relevant countries and regions, and provide corresponding operation entrances for users to choose to authorize or refuse.

[0127] The foregoing is merely an 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 modifications and variations. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present application should all 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 the idle physical cores. The associated usage relationship with the virtual machine; 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 for executing the one or more computer programs. Instructions are used to execute the page fault recovery method described in any one of claims 1-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