Memory page fault handling method, and device, storage medium and program product

Abstract

The embodiments of the present disclosure relate to the technical field of the cloud. Provided are a memory page fault handling method, and a device, a storage medium and a program product. In the embodiments of the present disclosure, for a direct pass-through device bound to a process in a virtualized instance, a page fault handling channel is implemented between an operating system of the virtualized instance and the direct pass-through device. The channel can bypass an operating system of a host and directly connect to the operating system of the virtualized instance, and the implementation of the channel comprises a page fault request device, which is implemented on the side of the direct pass-through device, and a page fault driver module, which is implemented on the side of the operating system of the virtualized instance. On the basis of the channel, a page fault request can be directly injected into the operating system of the virtualized instance, and the operating system allocates a missing guest memory page from a physical memory space of the virtualized instance to the direct pass-through device. Since an injection process no longer passes through the operating system of the host, an IOMMU of the host can be skipped, thereby reducing the latency of injecting the page fault request into the operating system of the virtualized instance.

Description

Memory page fault handling methods, devices, storage media and program products

[0001] This disclosure claims priority to Chinese Patent Application No. 202411053030.9, filed with the China Patent Office on August 1, 2024, entitled “Method, apparatus, storage medium and program product for handling memory page faults”, the entire contents of which are incorporated herein by reference. Technical Field

[0002] This disclosure relates to the field of cloud technology, and in particular to a method, device, storage medium, and program product for handling memory page faults. Background Technology

[0003] In the field of cloud computing, applications or services typically run in VMs (Virtual Machines) on a host machine. A VM can be referred to as a guest machine, in contrast to a host machine. Like a host machine, a VM also requires I / O (Input / Output) operations, such as the process of a virtual I / O device in a VM accessing its GVA (Guest Virtual Address).

[0004] To improve the I / O performance of VMs, direct pass-through technology can be used to directly map the host machine's physical I / O devices into the VM. The virtualized I / O devices directly mapped into the VM are simply called pass-through devices. An IOMMU (Input / Output Memory Management Unit) is introduced to translate the virtual addresses visible to the pass-through devices into physical addresses, enabling the pass-through devices to access the physical memory on the host machine.

[0005] During the process of a passthrough device accessing physical memory, a page fault may occur. In this case, the passthrough device can inject the page fault request into the VM's operating system (OS) via a hardware IOMMU, so that the VM's OS can perform ODP (On-demand Paging) operation on the page fault request to resolve the memory page fault problem.

[0006] However, the current process of injecting page fault requests into the VM's OS is cumbersome and has high latency. Summary of the Invention

[0007] This disclosure provides a method, apparatus, storage medium, and program product for handling memory page faults, thereby reducing OS latency in injecting page fault requests into a VM in the event of a memory page fault.

[0008] This disclosure provides a computer device, including: a host machine, on which a virtualization instance is deployed and a target pass-through device is mounted. The target pass-through device is bound to a target process running in the virtualization instance and is used to access the virtual memory space of the target process. A page fault handling channel is implemented between the operating system of the virtualization instance and the target pass-through device. The page fault handling channel can bypass the operating system of the host machine and directly access the operating system of the virtualization instance. The target pass-through device is further used to send a page fault request directly to the operating system of the virtualization instance through the page fault handling channel when a guest memory page is missing during access to the virtual memory space of the target process, so that the operating system of the virtualization instance can allocate the missing guest memory page from the physical memory space of the virtualization instance.

[0009] This disclosure provides a memory page fault handling method applied to a target pass-through device mounted on a host machine. The host machine has a virtualization instance deployed on it, and the target pass-through device is bound to a target process running within the virtualization instance. The method includes: accessing the virtual memory space of the target process; if a guest memory page is missing during access to the virtual memory space, sending a page fault request to the operating system of the virtualization instance through a page fault handling channel, so that the operating system of the virtualization instance can allocate the missing guest memory page from the physical memory space of the virtualization instance; wherein the page fault handling channel is implemented between the operating system of the virtualization instance and the target pass-through device, and the page fault handling channel can bypass the host machine's operating system and directly access the operating system of the virtualization instance.

[0010] This disclosure also provides a memory page fault handling method applied to a page fault requesting device, wherein the page fault requesting device is located on a target physical peripheral on a host machine, the host machine deploys a virtualization instance and mounts a target passthrough device obtained by virtualizing the target physical peripheral, and the target passthrough device is bound to a target process running in the virtualization instance; the method includes: obtaining a page fault request initiated by the target passthrough device during access to the virtual memory space of the target process; sending the page fault request to a page fault driver module in the operating system of the virtualization instance, so that the page fault driver module can call the memory management module in the operating system of the virtualization instance to allocate the missing guest memory page from the physical memory space of the virtualization instance.

[0011] This disclosure also provides a memory page fault handling method applied to a page fault driver module, wherein the page fault driver module is located in the operating system of a virtualization instance, the virtualization instance is deployed on a host machine, the host machine is equipped with a target passthrough device, and the target passthrough device is bound to a target process running in the virtualization instance; the method includes: receiving a page fault request sent by a page fault request device, the page fault request being sent by the target passthrough device when a guest memory page is missing during access to the virtual memory space of the target process; and, according to the page fault request, invoking a memory management module in the operating system of the virtualization instance to allocate the missing guest memory page from the physical memory space of the virtualization instance.

[0012] This disclosure also provides an electronic device, including a memory and a processor. The memory is used to store a computer program, and the processor is coupled to the memory to execute the computer program for implementing the steps in the various methods provided in this disclosure.

[0013] This disclosure also provides a computer-readable storage medium storing a computer program that, when executed by a processor, enables the processor to perform the steps in the methods described above.

[0014] This disclosure also provides a computer program product, which includes a computer program / instructions that, when executed by a processor, enable the processor to perform the steps described in the method embodiments above.

[0015] In this embodiment of the disclosure, for a pass-through device bound to a process running in a virtualization instance, a page fault handling channel is implemented between the operating system of the virtualization instance and the pass-through device. This channel bypasses the host operating system and directly connects to the operating system of the virtualization instance. Based on the page fault handling channel, page fault requests can be directly injected into the operating system of the virtualization instance, so that the operating system can allocate missing guest memory pages for the pass-through device from the physical memory space of the virtualization instance. Since the page fault request injection process no longer goes through the host operating system, it also means that related hardware of the host, such as the IOMMU, can be bypassed, thus reducing the latency of injecting page fault requests into the operating system of the virtualization instance. Attached Figure Description

[0016] The accompanying drawings, which are included to provide a further understanding of this disclosure and form part of this disclosure, illustrate exemplary embodiments of the present disclosure and are used to explain the disclosure, but do not constitute an undue limitation of the disclosure. In the drawings:

[0017] Figure 1 is a schematic diagram of a client virtual address to host physical address translation process provided by an exemplary embodiment of the present disclosure;

[0018] Figure 2 is a schematic diagram of the structure of a computer device provided in an exemplary embodiment of the present disclosure;

[0019] Figures 3a-3c are schematic diagrams of the structure of a computer device provided in another exemplary embodiment of the present disclosure;

[0020] Figure 4 is an interactive flowchart of a memory page fault handling method provided in another exemplary embodiment of this disclosure;

[0021] Figure 5 is a flowchart illustrating another memory page fault handling method provided in yet another exemplary embodiment of this disclosure;

[0022] Figure 6 is a flowchart illustrating yet another exemplary embodiment of the present disclosure of a memory page fault handling method;

[0023] Figure 7 is a flowchart illustrating yet another exemplary embodiment of the present disclosure of a memory page fault handling method. Detailed Implementation

[0024] To make the objectives, technical solutions, and advantages of this disclosure clearer, the technical solutions of this disclosure will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this disclosure, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of this disclosure without creative effort are within the scope of protection of this disclosure.

[0025] 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, and displayed data) involved in this disclosure are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use, and processing of such data must comply with the relevant laws, regulations, and standards of the relevant countries and regions, and corresponding access points are provided for users to choose to authorize or refuse. In addition, the various models involved in this disclosure (including but not limited to language models or large models) comply with relevant laws and standards.

[0026] In the cloud computing field, applications or services can run in virtualized instances on a host machine. These virtualized instances are virtualized by a Virtual Machine Manager (VMM) on the host machine. The VMM is responsible for both virtualizing various resources on the host machine and creating and managing virtualized instances. Virtualized instances can be, but are not limited to, VMs, containers, or various cloud computing instances; a single VMM can manage one or more virtualized instances simultaneously.

[0027] In this disclosure, the implementation of the virtualization manager is not limited. For example, it can be implemented as a combination of kernel-mode Xen or KVM (Kernel-based Virtual Machine) and user-mode QEMU (Quick EMUlator). Xen is an open-source virtualization manager that runs directly on the host machine's hardware resources, replacing the operating system. It allows multiple operating system instances to run on a single host, providing high-performance virtualization without relying on special hardware support. KVM is an open-source Linux-based virtualization technology that transforms Linux into a virtualization manager, providing virtual machines with CPU (Central Processing Unit) virtualization and memory management capabilities. KVM can utilize hardware virtualization technology to improve virtual machine performance. KVM and QEMU can be used together. QEMU is a user-mode virtualization software, and KVM relies on QEMU to emulate I / O devices, such as virtual network cards and virtual disk controllers. The combination of KVM and QEMU can provide a complete virtualization solution.

[0028] In this embodiment, the host machine can be any computer device with computing, storage, and communication functions, such as a computer, mobile phone, tablet, or other terminal device, or a traditional server, cloud server, server cluster, or workstation, etc., without limitation. The host machine can have physical peripherals, which can include, but are not limited to, NIC (Network Interface Card), GPU (Graphics Processing Unit), CIPU (Cloud Infrastructure Processing Unit), DPU (Data Processing Unit), keyboard, or storage media. The physical peripherals can be interconnected with the host machine's CPU through a PCI (Peripheral Component Interconnect) bus or a PCIe (Peripheral Component Interconnect Express) bus. In this case, the physical peripherals can also be referred to as PCI devices. In addition to PCI or PCIe buses, other buses can also be used between the physical peripherals and the host machine's CPU, such as the CXL (Compute Express Link) bus, without limitation.

[0029] In this embodiment of the disclosure, a virtualization instance can be referred to as a guest relative to the host machine. A virtualization instance may also have virtual peripherals, which are derived from the virtualization of the host machine's physical peripherals. One physical peripheral can be virtualized into one or more virtual peripherals. For a virtualization instance, the virtual peripherals can achieve the same functionality as the physical devices.

[0030] With the advent of passthrough technology, virtualized instances can directly access the host machine's physical peripherals through the virtualization manager, thus avoiding the emulation and filtering by the virtualization manager. Commands from the virtualized instance are sent directly to the virtual peripheral (which can also be understood as passthrough to the physical peripheral corresponding to the virtual peripheral), reducing performance overhead. In this embodiment, any virtual peripheral virtualized from a physical peripheral is called a passthrough device.

[0031] For passthrough devices, the host machine's physical memory can be accessed through Direct Memory Access (DMA). DMA allows passthrough devices to exchange data directly with the host machine's physical memory without the host machine's CPU participating in data transfer. In other words, the passthrough device of a virtualization instance can access the physical memory space of the host machine where the virtualization instance resides.

[0032] The following section introduces and explains the concepts of memory space involved in virtualization instances and the host machine:

[0033] In this embodiment, the virtualization instance has physical memory space, and the operating system of the virtualization instance can allocate virtual memory space from the physical memory space of the virtualization instance for each process running in the virtualization instance. The operating system of the virtualization instance can be called the Guest OS. The address that each process in the virtualization instance can directly access is called the Guest Virtual Address (GVA). As shown in Figure 1, within the operating system of the virtualization instance, when any process attempts to access memory, it uses the Guest Virtual Address. The Guest Virtual Address can be translated to the Guest Physical Address (GPA) by querying the guest page table. The guest page table is responsible for the translation from Guest Virtual Address to Guest Physical Address. The Guest Physical Address is the physical address seen by the virtualization instance, hence the name Guest Physical Address. From the host machine's perspective, the address space constituted by the Guest Physical Address is a mapping of the host virtual address (i.e., HVA) in the guest address space. The client's physical address is mapped to the host virtual address (HVA), and then the host virtual address is automatically translated into a host physical address (HPA) by querying the host page table. The host physical address is the address provided by the host's physical memory and is the actual physical address. The host page table is responsible for the translation from host virtual address to host physical address. The host page table can be a software page table or a hardware page table. Taking a hardware page table as an example, the host page table can be, but is not limited to, an EPT (Extended Page Table).

[0034] It should be noted that GVA is an example of a client virtual address, but is not limited thereto. Similarly, GPA is an example of a client physical address; HVA is an example of a host virtual address; HPA is an example of a host physical address, and none of these constitute a limitation on the embodiments of this disclosure.

[0035] The access of pass-through devices to the memory space involved in virtualization instances includes different granularity access modes. The first is at the virtualization instance level: as the pass-through device for the entire virtualization instance, the pass-through device can access the physical memory space of the virtualization instance (such as GPA), and then, based on the mapping relationship between the guest physical address and the host physical address recorded in the EPT (Extended Page Table) page table, it can access the host's physical memory space. The second is at the process level: as the pass-through device for the processes running in the virtualization instance, the pass-through device can access the virtual memory space (such as GVA) of each process, and then, based on the mapping relationship between the guest virtual address and the guest physical address recorded in the process page table, it can access the guest physical address, and further, based on the mapping relationship between the guest physical address and the host physical address recorded in the EPT page table, it can access the host's physical memory space.

[0036] In this embodiment, the focus is on the second scenario, where the pass-through device accesses the memory space of the virtualization instance at the process level. The process running within the virtualization instance and possessing virtual memory space is referred to as the target process, the pass-through device bound to the target process is called the target pass-through device, and the physical peripheral virtualized to obtain the target pass-through device is called the target physical peripheral. The target physical peripheral can be a CIPU, DPU, keyboard, network card, or other physical device interconnected with the host CPU. Correspondingly, the target pass-through device can be a virtual peripheral obtained by virtualizing any of the aforementioned target physical peripherals. In this embodiment, VFIO (Virtual Function I / O) technology can be used, but is not limited to, to virtualize the target physical peripheral to obtain the target pass-through device. Based on this, the target pass-through device can also be called a VF (Virtual Function) device. Correspondingly, the target physical peripheral mounted on the host machine can be called a PF (Physical Function). In one example, SR-IOV (Single Root I / O Virtualization) passthrough technology can be used to support the virtualization of a single PF (Physical Function) into multiple VFs (Virtual Functions), and passthrough of multiple VFs to different processes.

[0037] It should be noted that although this disclosure focuses on the second scenario, it also provides methods for handling memory page faults in the first scenario. For details, please refer to the following embodiments.

[0038] Next, regarding the second scenario described above, the method for handling memory page faults provided in the embodiments of this disclosure will be described in detail.

[0039] In this process, when the target pass-through device accesses the virtual memory space of the target process, it sends an address translation request to the Memory Management Unit (MMU) on the target physical peripheral or the IOMMU on the host machine. This request requests the MMU on the target physical peripheral or the IOMMU on the host machine to translate the client virtual address requested by the target pass-through device based on the process page table of the target process. Optionally, if a MMU exists on the target physical peripheral, the address translation request is sent to the MMU on the target physical peripheral first; otherwise, it is sent to the IOMMU on the host machine. The process page table stores the mapping between the client virtual address in the virtual memory space of the target process and the client physical address in the physical memory space of the virtualized instance. The address translation request carries the client virtual address and is used to request the MMU on the target physical peripheral or the IOMMU on the host machine to translate the client virtual address into a client physical address. The memory management unit on the target physical peripheral or the IOMMU on the host machine queries the process page table of the target process based on the address translation request. If the process page table does not contain the client physical address corresponding to the client virtual address carried in the address translation request, it is determined that the memory page requested by the target passthrough device is missing. Therefore, the target passthrough device returns the address translation result indicating a missing memory page. The missing memory page is the memory page pointed to by the client physical address corresponding to the client virtual address accessed by the target passthrough device; this missing memory page belongs to the client's physical memory. For ease of description and distinction, memory pages in the client's physical memory are referred to as client memory pages; memory pages in the host's physical memory are referred to as host memory pages, which are the actual physical memory pages. If the memory management unit on the target physical peripheral or the IOMMU on the host machine returns the address translation result indicating a missing client memory page, the target passthrough device determines that a client memory page fault has occurred.

[0040] It should be noted that this disclosure focuses on the occurrence of client memory page misses, that is, the situation where a client virtual address cannot be mapped to the corresponding client physical address. Furthermore, the causes of client memory page misses can be varied. For example, when the target process accesses a client virtual address, the client page table has not yet established a mapping relationship between that client virtual address and the client physical address, thus preventing normal conversion and resulting in a client memory page miss. Another example is that the memory page pointed to by the client physical address that the target process wants to access has been swapped out to the hard disk; in this case, when the target passthrough device accesses that memory page again, a client memory page miss will occur.

[0041] During the aforementioned access process, a page fault may occur in the client's memory. In this case, the target pass-through device can employ the injection path shown in Figure 2. This involves injecting the page fault request into the operating system 27 of VM 29 via IOMMU 24 and its driver 251, as well as the vIOMMU (virtual IOMMU) driver 272 implemented in VM 29. This allows the VM 29's operating system 27 to perform on-demand paging operations for the page fault request, thus resolving the memory page fault issue. Figure 2 uses VM 29 as an example of a virtualized instance implementation, but it is not limited to this. The following is a detailed description of this solution.

[0042] A virtualization manager 231 (i.e., VMM 231 shown in Figure 2) is implemented on the host machine 23. The virtualization manager 231 may include a kernel-mode KVM 25 and a user-mode QEMU 26. The virtualization manager 231 can be used to create and manage VMs.

[0043] In this embodiment, the host machine has an IOMMU 24 and its IOMMU driver 251. Furthermore, QEMU 26 implements an IOMMU emulation backend 261 corresponding to IOMMU 24 and a vIOMMU driver 272 corresponding to IOMMU driver 251. The IOMMU driver 251 resides in the host machine's kernel mode, i.e., belongs to the host machine's operating system 232. In this embodiment, the relationship between the host machine's operating system and KVM is not limited. Figure 2 illustrates some functions of KVM 25 belonging to the host machine's operating system 232.

[0044] In this embodiment, VM 29 is an example of a virtualization instance; the operating system 27 of VM 29 is an example of an operating system for the virtualization instance. Furthermore, in this embodiment, during the memory access process initiated by the target passthrough device 22, an address translation request is sent to the IOMMU 24 on the host machine 23 as an example, but this is not a limitation. For example, an address translation request may also be sent to the memory management unit (not shown in FIG2) on the target physical peripheral 21.

[0045] Furthermore, if the IOMMU 24 returns an address translation result indicating a missing client memory page, the target passthrough device 22 determines that a missing client memory page has occurred (as shown in ① of Figure 2). For example, the target passthrough device 22 passes through its mapped target physical peripheral 21, which sends an address translation command to the IOMMU 24 via the PCIe bus. This address translation command contains the client virtual address. The IOMMU 24 maintains a mapping table between client virtual addresses and client physical addresses, also known as a page table. The page table records the correspondence between client virtual addresses and client physical addresses for address translation from client virtual addresses to client physical addresses. The IOMMU 24 returns an address translation result message indicating the status of the address translation result for the missing client memory page. In this embodiment, the IOMMU 24 returns an address translation result message indicating the status of the address translation result for the missing client memory page, thus determining that a missing client memory page has occurred. In Figure 2, the shaded area of ​​the target process 35 represents the situation where a client memory page miss occurs when the target pass-through device accesses the virtual memory space of the target process 35. The shaded areas in the following figures have the same meaning as the shaded areas in Figure 2, and will not be described again in subsequent embodiments.

[0046] Furthermore, the Page Request Interface (PRI) is an industry-standard PCI bus protocol defined by the PCI-SIG (Peripheral Component Interconnect Special Interest Group) for the target pass-through device 22 to provide page fault requests to the operating system 27 of VM 29. For a target pass-through device 29 that supports the PRI protocol, a page fault request is sent to the IOMMU 24 via the PCIe bus (as shown in ② of Figure 2). This page fault request includes the identification information of the target pass-through device 22, which determines which pass-through device issued the request. In addition, the page fault request also includes the client virtual address requested by the target pass-through device 22, the target process ID, and other information. This page fault request triggers an interrupt in the IOMMU 24. The host machine's IOMMU driver 251 responds to the interrupt to receive the page fault request (not shown in Figure 2).

[0047] The host machine's IOMMU driver 251 injects a simulated interrupt into the vIOMMU driver 272 in QEMU 26 via eventfd. Here, eventfd is a file descriptor (fd) specifically used to transmit events. During the injection process, the host machine's IOMMU driver 251 notifies the IOMMU emulation backend 261 via eventfd (as shown in ③ of Figure 2). Then, the IOMMU emulation backend 261, based on the identifier information of the target passthrough device 22 carried in the page fault request, associates with the passthrough device corresponding to the page fault request and suspends the VM to which the target passthrough device 22 belongs, i.e., switches from non-root mode to root mode and enters the KVM 25 kernel. It then writes the page fault request to the page request queue (PRQ) of vIOMMU driver 272 and injects a simulated interrupt into vIOMMU driver 272, so that the VM 29 to which the target passthrough device belongs is aware of the simulated interrupt (as shown in ④ of Figure 2). In this embodiment, the page fault request queue is referred to as page fault request queue 1 to distinguish it from the page fault request queues in subsequent embodiments. Page fault request queue 1 is a shared message queue shared by the IOMMU emulation backend 261 and the vIOMMU driver 272 for information exchange between the two. For example, as mentioned above, when the IOMMU emulation backend 261 writes a page fault request to page fault request queue 1 of the vIOMMU driver 272, the vIOMMU driver 272 can retrieve the page fault request from page fault request queue 1.

[0048] When VM 29 is restarted, after receiving a simulated interrupt, VM 29 calls and executes the interrupt handler of vIOMMU driver 272. In the interrupt handler, the memory management module 273 of operating system 27 is called (as shown in ⑤ in Figure 2). Based on the guest virtual address of the page fault address in the page fault request, the corresponding guest physical address is allocated to the guest virtual address of the page fault address (as shown in ⑥ in Figure 2).

[0049] After the allocation is completed, the vIOMMU driver 272 of the operating system 27 writes a page allocation completion message to the page fault request queue 1. This page allocation completion message is intercepted by QEMU 26, which then calls the host machine's IOMMU driver 251 to return the page allocation completion message to the target pass-through device 22.

[0050] The aforementioned method involves multiple steps during the process of injecting a simulated interrupt from the host machine's IOMMU driver to the vIOMMU driver, and during the process of returning a page fault allocation completion message from the vIOMMU driver to the target passthrough device, thus resulting in high latency. Furthermore, the simulation and debugging complexity of the vIOMMU driver is extremely high. For different hardware platforms, such as those from different companies, different vIOMMU drivers need to be simulated, leading to platform dependencies and compatibility issues. To address these problems, this disclosure also provides another page fault handling method. In this method, for a target passthrough device bound to a target process in the virtualization instance, a page fault handling channel is implemented between the operating system of the virtualization instance and the target passthrough device. This channel can bypass the host machine's operating system and directly connect to the virtualization instance's operating system. Based on the page fault handling channel, page fault requests can be directly injected into the operating system of the virtualization instance. This allows the operating system to allocate the missing guest memory pages from the physical memory space of the virtualization instance to the target passthrough device. Since this page fault request injection process bypasses the host operating system, it also means that related host hardware such as the IOMMU can be skipped, thus reducing the latency of injecting page fault requests into the virtualization instance's operating system. While solving the page fault problem, this approach also avoids the complexity of simulating and debugging the IOMMU driver, as it eliminates the need for the IOMMU and its driver, the IOMMU emulation backend, and the vIOMMU driver. It also avoids hardware platform limitations and compatibility issues.

[0051] As shown in Figure 3a, a computer device provided in this embodiment includes a host machine 33, on which a virtualization instance 37 is deployed and a target pass-through device 32 is mounted. The target pass-through device 32 is obtained by virtualizing a target physical peripheral 31 of the host machine 33. The target pass-through device 32 is bound to a target process 35 running in the virtualization instance 37 and is used to access the virtual memory space of the target process 35. In this embodiment, a page fault handling channel 34 is implemented between the operating system 36 of the virtualization instance and the target pass-through device 32. Detailed information regarding the host machine, virtualization instance, target process, and target pass-through device can be found in the foregoing embodiments and will not be repeated here.

[0052] In this embodiment, as described in the previous embodiments, the focus is on the fact that the target pass-through device 32 serves as a pass-through device for the target process 35 running in the virtualization instance 37, and can access the virtual memory space of the target process 35. In other words, the target pass-through device 32 is bound to the target process 35 running in the virtualization instance 37 and can be used to access the virtual memory space of the target process 35.

[0053] During the access to the virtual memory space of the target process 35, the client virtual address requested by the target pass-through device 32 can be translated into a client physical address. For details on the client virtual address and client physical address, please refer to the aforementioned embodiments, which will not be repeated here. In the absence of a mapping from client virtual address to client physical address, that is, in the case of a client memory page missing (as shown in ① in Figure 3a), the target pass-through device 32 sends a page fault request directly to the operating system 36 of the virtualization instance through the page fault handling channel 34 (as shown in ② in Figure 3a), so that the operating system 36 of the virtualization instance can allocate the missing client memory page from the physical memory space (i.e., the client physical address) of the virtualization instance 37 (as shown in ③ in Figure 3a).

[0054] In this embodiment, the implementation of the page fault handling channel 34 is not limited. Any implementation that can inject the page fault request of the target passthrough device 32 into the operating system 36 of the virtualization instance in a manner that bypasses the host operating system is applicable to this embodiment. The implementation of the page fault handling channel 34 is described below by way of example:

[0055] By leveraging a vendor-defined PRI protocol, a page fault handling channel 34 is established between the target physical peripheral 31 and the operating system 36 of the virtualized instance. This vendor-defined PRI protocol, also known as Vendor PRI, differs from the standard PRI protocol but is also a message interface protocol based on the PCI bus.

[0056] In one optional implementation, the page fault handling channel 34 includes: a page fault request device located on a target physical peripheral on the host machine and a page fault driver module located in the operating system of the virtualization instance, wherein the target physical peripheral is a physical peripheral of the target passthrough device obtained by virtualization; the page fault request device is used to receive a page fault request initiated by the target passthrough device in the event of a missing guest memory page, and send the page fault request to the page fault driver module; the page fault driver module is used to, according to the page fault request, call the memory management module in the operating system of the virtualization instance to allocate the missing guest memory page from the physical memory space (i.e., the guest physical address) of the virtualization instance.

[0057] In this context, the page fault requesting device is obtained by virtualizing the target physical peripheral, and the target physical peripheral is also a virtualized target passthrough device. That is, both the page fault requesting device and the target passthrough device can coexist on the target physical peripheral. There are no restrictions on the relative deployment locations of the page fault requesting device and the target passthrough device. The page fault driver module resides in the operating system of the virtualization instance. Simultaneously, the operating system of the virtualization instance also includes at least the driver for the target passthrough device. There are also no restrictions on the relative deployment locations of the page fault driver module and the driver for the target passthrough device. The following provides an exemplary implementation of the relative deployment locations between the page fault requesting device and the target passthrough device, and between the page fault driver module and the driver for the target passthrough device, with a detailed explanation of the exemplary implementation.

[0058] In an optional implementation, as shown in FIG3b, the page fault driver module 481 is implemented in the driver 48 of the target pass-through device; the page fault request device 421 is implemented in the target pass-through device 32, which is equivalent to implementing a page fault request device 421 for each target pass-through device 32, and each page fault request device 421 corresponds to a page fault request driver 481. The cooperation between a set of page fault request devices 421 and page fault request drivers 481 with a corresponding relationship can be used as an implementation of the page fault processing channel 34.

[0059] In another optional embodiment, as shown in FIG3c, the page fault driver module 60 is implemented independently of the driver 48 of the target passthrough device and is implemented separately in the operating system 36 of the virtualization instance; the page fault request device 61 is implemented independently of the target passthrough device 32 and is implemented separately on the target physical peripheral 31. In this optional embodiment, all target passthrough devices 32 on the target physical peripheral 31 can share the page fault request device 61 and the page fault driver module 60. The cooperation between the page fault request device 61 and the page fault driver module 60 can serve as another implementation of the page fault processing channel 34.

[0060] Besides the deployment methods of the page fault driver module 60 and page fault request device 61 shown in Figures 3b and 3c, other deployment methods are also possible. For example, the page fault driver module can be implemented in the driver program of the target passthrough device, and the page fault request device can be implemented independently of the target passthrough device and separately on the target physical peripheral. This means that each target passthrough device has its own page fault driver module, but different target passthrough devices share the same page fault request device. The cooperation between a single page fault request device and multiple page fault driver modules can serve as another implementation method for the page fault processing channel. Alternatively, the page fault driver module can be implemented independently of the driver program of the target passthrough device and separately in the operating system of the virtualization instance, and the page fault request device can be implemented in the target passthrough device. This means that each target passthrough device has its own page fault request device, but different target passthrough devices share the same page fault driver module. The cooperation between multiple page fault request devices and a single page fault driver module can serve as another implementation method for the page fault processing channel.

[0061] The technical solutions provided by the embodiments of this disclosure will be described in detail below with reference to Figures 3b and 3c.

[0062] As shown in Figure 3b, based on the computer device shown in Figure 3a, the page fault driver module 481 is implemented in the driver 48 of the target passthrough device; the page fault request device 421 is implemented in the target passthrough device 32. Optionally, the page fault processing channel 34 further includes a page fault request queue. The initial value of the number of page fault requests in the page fault request queue can be zero.

[0063] When the target pass-through device 32 determines that a guest memory page is missing, it sends a page fault request to the operating system 36 of the virtualization instance through the page fault handling channel 34. This can be implemented by sending a page fault request to the page fault request device 421. Upon receiving a page fault request, the page fault request device 421 writes the page fault request into the page fault request queue. As guest memory page missing events continue to occur (as shown in ① of Figure 3b), the page fault request queue may include one or more page fault requests. Figure 3b shows a page fault request queue containing page fault requests 1-n as an example, where n≥1 and is a natural number. The page fault driver module 481 reads the page fault request from the page fault request queue; based on the page fault request, it calls the memory management module 49 to allocate the missing guest memory page from the physical memory space (i.e., the guest physical address) of the virtualization instance 37.

[0064] It should be noted that, in this embodiment, it is equivalent to implementing a page fault request device 421 for each target pass-through device 32, and each page fault request device 421 corresponds to a page fault request driver 481. Alternatively, it can be understood that each target pass-through device 32 has a page fault processing channel 34, and each page fault processing channel 34 has a page fault request queue for data interaction between the page fault request device 421 and the page fault request driver 481. The data interaction can be, but is not limited to, page fault request interaction, page fault allocation completion message interaction, etc.

[0065] In this embodiment, the page fault request device 421 writes the page fault request into the page fault request queue (as shown in ② of Figure 3b) based on the address information of the page fault request queue in the physical memory space of the virtualization instance 37. This embodiment does not limit the method by which the page fault request device 421 obtains the address information of the page fault request queue. In an optional embodiment, the address information of the page fault request queue can be pre-written into the code of the page fault request device 421. This is equivalent to the page fault request device knowing the address information of the page fault request queue by default, and thus being able to directly write the page fault request into the page fault request queue based on the address information. In this embodiment, a fixed memory address needs to be allocated to the page fault request queue. In another optional embodiment, the page fault processing channel 34 further includes an address register (not shown in Figure 3b) for storing the address information of the page fault request queue in the physical memory space of the virtualization instance. Then, when the page fault request device 421 receives a page fault request, it writes the page fault request into the page fault request queue based on the address information stored in the address register.

[0066] In this embodiment, when reading page fault requests from the page fault request queue, page fault requests can be read according to a preset reading strategy (as shown in ③ of Figure 3b). For example, a first-in-first-out (FIFO) strategy can be followed, where requests that enter the page fault request queue first can be read first. Alternatively, a priority strategy can be used, where a priority is set for the missing page request based on the missing page status. The target process's virtual address space is divided into user space and kernel space. Therefore, missing page requests occurring in the target process's virtual memory space can be categorized as either user space-generated or kernel space-generated. Page fault requests generated by kernel space-generated page faults can be given a higher priority, and these higher-priority page fault requests are placed at the head of the page fault queue. The page fault driver module reads the page fault request at the head of the queue each time, ensuring that it is processed first.

[0067] This embodiment does not limit the method by which the page fault driver module reads page fault requests from the page fault request queue. Several exemplary implementation methods are given below.

[0068] In one alternative implementation, when using a polling approach, the page fault driver module periodically checks the page fault request queue for new page fault requests awaiting processing. If a new page fault request exists, it reads the page fault request at the head of the queue and, based on the page fault request, calls the memory management module (as shown in ④ of Figure 3b) to allocate the missing guest memory from the physical memory space of the virtualization instance (as shown in ⑤ of Figure 3b). After processing a page fault request, it checks the page fault request queue again for any requests to be processed; if none exist, it proceeds to the next polling cycle.

[0069] In another alternative implementation, when using an interrupt-driven approach, the page fault handling channel further includes an extended page fault interrupt register located at one end of the page fault requesting device. When the page fault requesting device writes a page fault request into the page fault request queue, it sends an interrupt message to the page fault driver module via the page fault interrupt register to trigger the page fault driver module to read the page fault request from the page fault request queue. Further, the page fault driver module reads the page fault request from the page fault request queue based on the interrupt message; executes the page fault interrupt routine corresponding to the interrupt message; and calls the memory management module (as shown in ④ of Figure 3b) in the page fault interrupt routine to allocate the missing guest memory page from the physical memory space of the virtualization instance (as shown in ⑤ of Figure 3b).

[0070] In one optional embodiment, the interrupt vectors used by the target pass-through device are extended based on MSI-X (Message Signaled Interrupts eXtended, a method of extending interrupt vectors), and a corresponding interrupt handler is assigned to each interrupt vector. The interrupt vector is the entry address of the interrupt handler and is stored in the interrupt vector table. The interrupt message sent by the page fault register to the page fault driver may contain the interrupt vector. Upon receiving this interrupt message, the corresponding interrupt handler can be found based on the interrupt vector.

[0071] It should be noted that the interrupt handler is pre-written and written to the corresponding location in the interrupt vector table, so that when an interrupt message is received, the corresponding interrupt handler can be found based on the interrupt vector. The address register and page fault interrupt register are registers on the target physical peripheral 31. When the page fault handling channel includes an address register, a page fault interrupt register, and a page fault queue, the address register, page fault interrupt register, and page fault request queue can be initialized during the initialization process for the target passthrough device. Specifically, during the initialization process of the driver 48 for the target passthrough device, a page fault request queue can be allocated, the address information of the page fault request queue can be initialized into the address register, and the interrupt register can be initialized. Optionally, the page fault request queue can be implemented as a shared memory space in the host machine's physical memory, but is not limited to this.

[0072] Furthermore, this disclosure also provides a deployment method for a page fault request device and a page fault driver module. As shown in FIG3c, based on the computer device shown in FIG3a, the page fault driver module 60 is independent of the driver 48 of the target passthrough device and is implemented separately in the operating system 36 of the virtualization instance; the page fault request device 61 is independent of the target passthrough device 32 and is implemented separately on the target physical peripheral 31.

[0073] In this embodiment, all target pass-through devices 32 on the target physical peripheral 31 share the page fault request device 61 and the page fault driver module 60.

[0074] In this embodiment, when the target pass-through device 32 encounters a missing guest memory page during access to the virtual memory space (as shown in ① of Figure 3c), it sends a page fault request to the page fault request device 61. The page fault request device 61 receives the page fault request (as shown in ② of Figure 3c) and writes it into the page fault request queue (as shown in ③ of Figure 3c). The implementation method for obtaining the address information of the page fault request queue can be referred to the aforementioned embodiments and will not be repeated here. Further, the page fault driver module 60 reads the page fault request from the page fault request queue (as shown in ④ of Figure 3c); based on the page fault request, it calls the memory management module 59 (as shown in ⑤ of Figure 3c) to allocate the missing guest memory page from the physical memory space of the virtualization instance 37 (as shown in ⑥ of Figure 3c). The implementation method for the page fault driver module 60 to read the page fault request queue can be referred to the aforementioned embodiments and will not be repeated here.

[0075] Optionally, after the memory management module allocates a missing guest memory page from the physical memory space of the virtualization instance, if a corresponding physical memory page exists for the allocated guest memory page, the target pass-through device can directly access the host's physical memory. If a corresponding physical memory page is missing for the allocated guest memory page, the memory management module can also jump from the virtualization instance to the virtualization manager on the host machine, so that the virtualization manager can restore the physical memory page to the host machine's physical memory space.

[0076] The following section, using an interaction flowchart, describes the interaction process between the various terminals involved in this disclosed technical solution.

[0077] Figure 4 shows an interactive flowchart of a memory page fault handling method provided in an embodiment of this disclosure. The interacting counterparts in Figure 4 include: a page fault requesting device, a page fault driver module, a memory management module, and a target pass-through device. These counterparts cooperate with each other to complete the memory page fault handling.

[0078] It should be noted that the aforementioned counterparts are not necessarily included or can only include the aforementioned counterparts. They are merely examples to illustrate the memory page fault handling method provided in the embodiments of this disclosure and do not constitute a limitation.

[0079] In Figure 4, the page fault request queue is specifically shown to illustrate that it can be used for data interaction between the page fault request device and the page fault driver module. However, strictly speaking, the page fault request queue is not an interaction terminal. It should be noted that the page fault request queue is not the only way for data interaction between the page fault request device and the page fault driver module; other methods can be found in the above embodiments, and will not be repeated here.

[0080] It should be noted that in this embodiment, the page fault driver module reads page fault requests from the page fault request queue using an interrupt method, but it is not limited to this. Other methods can be found in the above embodiments, which will not be described in detail here.

[0081] As shown in Figure 4, when a client memory page is missing during access to the virtual memory space, the target pass-through device sends a page fault request to the page fault request device (as shown in S41 of Figure 4). Upon receiving the page fault request, the page fault request device retrieves the address information of the page fault request queue in the physical memory space of the virtualization instance from the address register; based on the address information, it writes the page fault request into the page fault request queue (as shown in S42 of Figure 4). The method of retrieving the address information of the page fault request queue from the address register is only an example and is not limited to this; when the page fault request is written into the page fault request queue, an interrupt message is sent to the page fault driver module through the page fault interrupt register (as shown in S43 of Figure 4).

[0082] Furthermore, upon receiving an interrupt message, the page fault driver module reads a page fault request from the page fault request queue (as shown in S44 of Figure 4). The interrupt message includes an interrupt vector. The module then locates the corresponding interrupt handler based on the interrupt vector and executes the page fault interrupt handler corresponding to the interrupt message (as shown in S45 of Figure 4). Within the page fault interrupt handler, the memory management module is called (as shown in S46 of Figure 4). The memory management module allocates the missing guest memory page from the physical memory space of the virtualization instance (as shown in S47 of Figure 4). Note that steps S46 and S47 in Figure 4 can be combined into a single step.

[0083] The above embodiments focused on how to handle missing guest memory pages when the passthrough device accesses the memory space involved in the virtualization instance at the process level. The following embodiments will describe a method for handling missing memory pages when the passthrough device accesses the memory space involved in the virtualization instance at the virtualization instance level.

[0084] In this embodiment, for ease of distinction and description, the pass-through device belonging to the virtualization instance is referred to as a non-target pass-through device, to differentiate it from the target pass-through device in the aforementioned embodiments. Specifically, the non-target pass-through device is a pass-through device bound to the virtualization instance.

[0085] This embodiment provides a computer device, including a host machine, on which a target virtualization instance is deployed and a non-target passthrough device is mounted. The non-target passthrough device is bound to the target virtualization instance and used to access the virtual memory space of the target virtualization instance. A virtualization manager is deployed on the host machine, which can be implemented as either kernel-mode KVM or user-mode QEMU. The virtualization manager can perform tasks, load balancing, and status monitoring on the target virtualization instance. Detailed information regarding the host machine, virtualization instance, virtualization manager, and target passthrough device can be found in the foregoing embodiments and will not be repeated here.

[0086] In this embodiment, a page fault request service component is added to the non-target pass-through device, and a page fault request driver corresponding to the page fault request component is added within the virtualization manager. The page fault request service component and the page fault request driver have a communication link. The page fault request service component can be implemented as a hardware module, for example, it can be built using hardware functional circuits or constructed using programmable devices.

[0087] During access to the virtual memory space of a virtualized instance, a non-target passthrough device sends an address translation request to the IOMMU. This address translation request includes the client's physical address, requesting the IOMMU to translate the client's physical address requested by the non-target passthrough device based on the virtualized instance's page table. The IOMMU receives the address translation request and queries the mapping between the client's physical address and the host's physical address. If the mapping is not found, the IOMMU returns the address translation result to the non-target passthrough device, confirming that a memory page is missing. Therefore, in this embodiment, the missing memory page is the memory page pointed to by the host's physical address corresponding to the client's physical address accessed by the target passthrough device.

[0088] When a page fault is detected as a missing memory page by a non-target passthrough device, the page fault request service component sends a page fault request to the page fault request driver. This request carries the client physical address accessed by the target passthrough device. Upon receiving the page fault request, the page fault request driver requests the memory management module of the virtualization instance's operating system to restore the missing memory page. Responding to the page fault request driver's request, the memory management module escapes from the virtualization instance and enters the virtualization manager on the host machine, allowing the virtualization manager to restore the physical memory page (i.e., the memory page pointed to by the host machine's physical address) into the host machine's physical memory space.

[0089] In this embodiment, memory space access for virtualization instances is performed at the virtualization instance level. Furthermore, a page fault request service component is added to the non-target passthrough device, and a page fault request driver is added within the virtualization manager. The page fault request service component and the page fault request driver work together to restore the memory pages pointed to by the host machine's physical addresses.

[0090] The following embodiment of the method for handling memory page misses when accessing memory space involving a virtualization instance at the virtualization instance level will be compared with the aforementioned embodiment, which is the embodiment of the method for handling memory page misses when accessing memory space involving a virtualization instance at the process level. For ease of description, the "embodiment of the method for handling memory page misses when accessing memory space involving a virtualization instance at the process level" will be referred to as Embodiment 1; and the "embodiment of the method for handling memory page misses when accessing memory space involving a virtualization instance at the virtualization instance level" will be referred to as Embodiment 2.

[0091] Example 1 and Example 2 differ in at least the following ways:

[0092] 1. Difference in access granularity: In Example 2, the non-target passthrough device accesses the memory space involved in the virtualization instance at the virtualization instance level. In Example 1, the target passthrough device accesses the memory space involved in the virtualization instance at the process level.

[0093] 2. The page fault request device in Embodiment 1 differs from the page fault request service component in Embodiment 2: In Embodiment 2, the page fault request service component is located inside a non-target passthrough device. In Embodiment 1, the page fault request device is virtualized on the target physical peripheral. There are no restrictions on the relative positions of the page fault request device and the target passthrough device; relevant details can be found in the above embodiments and will not be repeated here.

[0094] 3. The page fault driver module in Example 1 differs from the page fault request driver in Example 2: In Example 2, the page fault request driver is implemented inside the virtualization manager. In Example 1, the page fault driver module resides in the operating system of the virtualization instance.

[0095] In this embodiment of the disclosure, a similar solution is adopted to solve the memory page fault problem faced by pass-through devices at the virtualization instance level and process level. Moreover, it can bypass the host operating system and pass through to the virtualization manager or the operating system of the virtualization instance, which can reduce the latency of injecting page fault requests into the corresponding objects.

[0096] The technical solution disclosed herein will be described below from different perspectives.

[0097] Figure 5 is a flowchart illustrating another exemplary embodiment of the present disclosure of a memory page fault handling method. This method is applied to a target passthrough device mounted on a host machine, where a virtualization instance is deployed. The target passthrough device is bound to a target process running within the virtualization instance. As shown in Figure 5, the method includes:

[0098] S501: Access the virtual memory space of the target process;

[0099] S502: If a missing guest memory page occurs during access to the virtual memory space, a page fault request is sent to the operating system of the virtualization instance through the page fault handling channel, so that the operating system of the virtualization instance can allocate the missing guest memory page from the physical memory space of the virtualization instance; wherein, the page fault handling channel is implemented between the operating system of the virtualization instance and the target pass-through device, and the page fault handling channel can bypass the host operating system and pass through to the operating system of the virtualization instance.

[0100] In one optional embodiment, the page fault handling channel includes: a page fault request device implemented on a target physical peripheral of the host machine and a page fault driver module implemented in the operating system of the virtualization instance, wherein the target physical peripheral is a physical peripheral that is virtualized to obtain the target pass-through device; if a guest memory page is missing during access to the virtual memory space, a page fault request is sent to the operating system of the virtualization instance through the page fault handling channel, including: if a guest memory page is missing during access to the virtual memory space, a page fault request is sent to the page fault request device, so that the page fault request device sends the page fault request to the page fault driver module, and the page fault driver module calls the memory management module in the operating system of the virtualization instance to allocate the missing guest memory page from the physical memory space of the virtualization instance.

[0101] In an optional embodiment, the method further includes: during the access to the virtual memory space of the target process, sending an address translation request to the memory management unit on the target physical peripheral or the input / output memory management unit on the host machine, to request the memory management unit or the input / output memory management unit to perform address translation on the client virtual address requested by the target passthrough device based on the process page table of the target process; if the memory management unit or the input / output memory management unit returns an address translation result indicating a client memory page missing, determining that a client memory page missing situation has occurred; wherein, the process page table stores the correspondence between the client virtual address in the virtual memory space of the target process and the client physical address in the physical memory space of the virtualization instance.

[0102] Figure 6 is a flowchart illustrating another exemplary embodiment of a memory page fault handling method provided in this disclosure. This method is applied to a page fault requesting device, which is located on a target physical peripheral on the host machine. A virtualization instance is deployed on the host machine, and a target passthrough device obtained by virtualizing the target physical peripheral is mounted on it. The target passthrough device is bound to a target process running in the virtualization instance. As shown in Figure 6, the method includes:

[0103] S601: Obtain the page fault request initiated by the target pass-through device during the access to the virtual memory space of the target process;

[0104] S602: Send a page fault request to the page fault driver module in the virtualization instance's operating system, so that the page fault driver module can call the memory management module in the virtualization instance's operating system to allocate the missing guest memory page from the virtualization instance's physical memory space.

[0105] In one optional embodiment, sending the page fault request to the page fault driver module in the operating system of the virtualization instance includes: writing the page fault request into a page fault request queue, and sending an interrupt message to the page fault driver module through a page fault interrupt register to trigger the page fault driver module to read the page fault request from the page fault request queue.

[0106] In one optional embodiment, writing the page fault request into the page fault request queue includes: obtaining the address information of the page fault request queue in the physical memory space of the virtualization instance from the address register; and writing the page fault request into the page fault request queue according to the address information.

[0107] Figure 7 is a flowchart illustrating another exemplary embodiment of a memory page fault handling method provided in this disclosure. This method is applied to a page fault driver module, which resides in the operating system of a virtualized instance. The virtualized instance is deployed on a host machine, and the host machine has a target passthrough device mounted on it. The target passthrough device is bound to a target process running in the virtualized instance. As shown in Figure 7, the method includes:

[0108] S701: Receives a page fault request sent by the page fault requesting device. The page fault request is sent by the target pass-through device when a client memory page is missing during access to the virtual memory space of the target process.

[0109] S702: Based on the page fault request, invoke the memory management module in the operating system of the virtualization instance to allocate the missing guest memory page from the physical memory space of the virtualization instance.

[0110] In one optional embodiment, receiving a page fault request sent by a page fault requesting device includes: receiving an interrupt message sent by the page fault requesting device through a page fault interrupt register; reading the page fault request written by the page fault requesting device from a page fault request queue according to the interrupt message; and invoking a memory management module in the operating system of the virtualization instance according to the page fault request to allocate the missing guest memory page from the physical memory space of the virtualization instance, including: executing a page fault interrupt routine corresponding to the interrupt message, and invoking the memory management module in the page fault interrupt routine to enable the memory management module to allocate the missing guest memory page from the physical memory space of the virtualization instance.

[0111] The detailed implementation methods and beneficial effects of each step in this embodiment have been described in detail in the foregoing embodiments, and will not be elaborated here.

[0112] It should be noted that the execution subject of each step of the method provided in the above embodiments can be the same device, or the method can be executed by different devices. For example, the execution subject of steps 501 to 502 can be device A; or the execution subject of step 501 can be device A, and the execution subject of step 502 can be device B; and so on.

[0113] Furthermore, in some of the processes described in the above embodiments and accompanying drawings, multiple operations appear in a specific order. However, it should be clearly understood that these operations may not be executed in the order they appear herein, or they may be executed in parallel. The operation numbers, such as 501, 502, etc., are merely used to distinguish different operations and do not represent any execution order. Additionally, these processes may include more or fewer operations, and these operations may be executed sequentially or in parallel. It should be noted that the descriptions such as "first" and "second" in this document are used to distinguish different messages, devices, modules, etc., and do not represent a chronological order, nor do they limit "first" and "second" to different types.

[0114] Accordingly, this disclosure also provides an electronic device, comprising: a memory and a processor, wherein the memory is used to store a computer program, and the processor is coupled to the memory and used to execute the computer program for the steps in the methods shown in FIG. 5, FIG. 6, or FIG. 7 provided in this disclosure. For detailed implementation processes of these steps and the resulting technical effects, please refer to the foregoing embodiments, which will not be repeated here. It should be noted that the electronic device provided in this disclosure can be of various device forms capable of executing the above methods, such as a host machine, a physical peripheral with execution capabilities on the host machine, or other devices. The physical peripheral with execution capabilities on the host machine can be, but is not limited to, a CIPU, a DPU, etc.

[0115] This disclosure also provides a computer-readable storage medium storing a computer program that, when executed by a processor, enables the processor to perform the steps in the methods described above.

[0116] This disclosure also provides a computer program product, which includes a computer program / instructions that, when executed by a processor, enable the processor to perform the steps described in the method embodiments above.

[0117] The computer device described in the above embodiments may further include, depending on its implementation, a memory, a processor, a display, a communication component, an audio component, and a power supply component.

[0118] 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 storage, flash memory, magnetic disk, or optical disk.

[0119] The aforementioned communication components are configured to facilitate wired or wireless communication between the device containing the communication components and other devices. The device containing the communication components can access wireless networks based on communication standards, such as WiFi, 2G, 3G, 4G / LTE, 5G, or combinations thereof. In one exemplary embodiment, the communication components receive broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel. In one exemplary embodiment, the communication components also include a Near Field Communication (NFC) module to facilitate short-range communication. For example, the NFC module may be implemented based on Radio Frequency Identification (RFID), Infrared Data Association (IrDA), Ultra Wide Band (UWB), Bluetooth (BT), and other technologies.

[0120] The aforementioned display includes a screen, which may include a Liquid Crystal Display (LCD) and a Touch Panel (TP). If the screen includes a Touch Panel, the screen can be implemented as a touchscreen to receive input signals from the user. The Touch Panel includes one or more touch sensors to sense touches, swipes, and gestures on the Touch Panel. The touch sensors can sense not only the boundaries of touch or swipe actions but also the duration and pressure associated with the touch or swipe operation.

[0121] The aforementioned power supply components provide power to various components within the device in which they reside. These power supply components may include a power management system, one or more power sources, and other components associated with generating, managing, and distributing power to the device in which they reside.

[0122] The aforementioned audio component can be configured to output and / or input audio signals. For example, the audio component includes a microphone (MIC) configured to receive external audio signals when the device containing the audio component is in an operating mode, such as call mode, recording mode, or voice recognition mode. The received audio signals can be further stored in memory or transmitted via a communication component. In some embodiments, the audio component also includes a speaker for outputting audio signals.

[0123] Those skilled in the art will understand that embodiments of this disclosure can be provided as methods, systems, or computer program products. Therefore, this disclosure can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this disclosure can take the form of a computer program product embodied on one or more computer-readable storage media (including, but not limited to, disk storage, compact disc read-only memory (CD-ROM), optical storage, etc.) containing computer-usable program code.

[0124] This disclosure is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in one or more flowchart illustrations and / or one or more block diagrams.

[0125] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means that implement the functions specified in one or more flowcharts and / or one or more block diagrams.

[0126] These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, such that the instructions, which execute on the computer or other programmable apparatus, provide steps for implementing the functions specified in one or more flowcharts and / or one or more block diagrams.

[0127] In a typical configuration, a computing device includes one or more processors (Central Processing Units, CPUs), input / output interfaces, network interfaces, and memory.

[0128] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0129] Computer-readable media, including both permanent and non-permanent, removable and non-removable media, can store information using any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change random access memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, Digital Video Disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0130] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0131] The above are merely embodiments of this disclosure and are not intended to limit the scope of this disclosure. Various modifications and variations can be made to this disclosure by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this disclosure should be included within the scope of the claims of this disclosure.

Claims

1. A computer device, wherein, include: A host machine, on which a virtualization instance is deployed and a target pass-through device is mounted, the target pass-through device being bound to a target process running in the virtualization instance and used to access the virtual memory space of the target process; A page fault handling channel is implemented between the operating system of the virtualization instance and the target pass-through device. The page fault handling channel can bypass the operating system of the host machine and pass directly to the operating system of the virtualization instance. The target pass-through device is also used to send a page fault request directly to the operating system of the virtualization instance through the page fault handling channel when a guest memory page is missing during access to the virtual memory space of the target process, so that the operating system of the virtualization instance can allocate the missing guest memory page from the physical memory space of the virtualization instance.

2. The computer device according to claim 1, wherein, The page fault handling channel includes: a page fault request device located on the target physical peripheral of the host machine and a page fault driver module located in the operating system of the virtualization instance, wherein the target physical peripheral is a physical peripheral that is virtualized to obtain the target pass-through device; The page fault request device is configured to receive a page fault request initiated by the target pass-through device in the event of a missing client memory page, and send the page fault request to the page fault driver module. The page fault driver module is used to call the memory management module in the operating system of the virtualization instance to allocate the missing guest memory page from the physical memory space of the virtualization instance according to the page fault request.

3. The computer device according to claim 2, wherein, The page fault handling channel also includes: a page fault request queue; The page fault request device is specifically used to: upon receiving the page fault request, write the page fault request into the page fault request queue; The page fault driver module is specifically used to: read the page fault request from the page fault request queue; and, based on the page fault request, call the memory management module to allocate the missing guest memory page from the physical memory space of the virtualization instance.

4. The computer device according to claim 3, wherein, The page fault handling channel also includes: a page fault interrupt register; The page fault request device is further configured to: when the page fault request is written into the page fault request queue, send an interrupt message to the page fault driver module through the page fault interrupt register to trigger the page fault driver module to read the page fault request from the page fault request queue; The page fault driver module is specifically used to: read the page fault request from the page fault request queue according to the interrupt message; execute the page fault interrupt routine corresponding to the interrupt message; and call the memory management module in the page fault interrupt routine to allocate the missing guest memory page from the physical memory space of the virtualization instance.

5. The computer device according to claim 3, wherein, The page fault handling channel further includes an address register for storing the address information of the page fault request queue in the physical memory space of the virtualization instance. The page fault request device is specifically used to: upon receiving the page fault request, write the page fault request into the page fault request queue according to the address information stored in the address register.

6. The computer device according to any one of claims 2-5, wherein, The operating system of the virtualization instance also includes: the driver for the target pass-through device; The page fault driver module is implemented in the driver program of the target pass-through device; the page fault request device is implemented in the target pass-through device. or The page fault driver module is independent of the driver for the target passthrough device and is implemented separately in the operating system of the virtualization instance; the page fault request device is independent of the target passthrough device and is implemented separately on the target physical peripheral.

7. The computer device according to any one of claims 2-5, wherein, The target through-pass device is also used for: During the process of accessing the virtual memory space of the target process, an address translation request is sent to the memory management unit on the target physical peripheral or the input / output memory management unit on the host machine to request the memory management unit or the input / output memory management unit to perform address translation on the client virtual address requested by the target pass-through device based on the process page table of the target process; If the memory management unit or the input / output memory management unit returns the address translation result of the missing client memory page, it is determined that a missing client memory page has occurred. The process page table stores the correspondence between the client virtual address in the virtual memory space of the target process and the client physical address in the physical memory space of the virtualization instance.

8. The computer device according to any one of claims 2-5, wherein, The memory management module is further configured to: in the event that the allocated guest memory page is missing a corresponding physical memory page, trap from the virtualization instance to the virtualization manager on the host machine, so that the virtualization manager can restore the physical memory page to the physical memory space of the host machine.

9. A method for handling memory page faults, wherein, A method for applying a target passthrough device mounted on a host machine, wherein a virtualization instance is deployed on the host machine, and the target passthrough device is bound to a target process running in the virtualization instance, the method comprising: Access the virtual memory space of the target process; If a missing guest memory page occurs during access to the virtual memory space, a page fault request is sent to the operating system of the virtualization instance through the page fault handling channel, so that the operating system of the virtualization instance can allocate the missing guest memory page from the physical memory space of the virtualization instance. The page fault handling channel is implemented between the operating system of the virtualization instance and the target pass-through device, and the page fault handling channel can bypass the host machine's operating system and pass directly to the operating system of the virtualization instance.

10. The method according to claim 9, wherein, The page fault handling channel includes: a page fault request device implemented on the target physical peripheral of the host machine and a page fault driver module implemented in the operating system of the virtualization instance, wherein the target physical peripheral is a physical peripheral that is virtualized to obtain the target pass-through device; If a missing page occurs during access to the virtual memory space, a page fault request is sent to the operating system of the virtualization instance through the page fault handling channel, including: If a missing guest memory page occurs during access to the virtual memory space, a page fault request is sent to the page fault request device, which then forwards the page fault request to the page fault driver module. The page fault driver module then calls the memory management module in the operating system of the virtualization instance to allocate the missing guest memory page from the physical memory space of the virtualization instance.

11. The method according to claim 10, wherein, Also includes: During the process of accessing the virtual memory space of the target process, an address translation request is sent to the memory management unit on the target physical peripheral or the input / output memory management unit on the host machine to request the memory management unit or the input / output memory management unit to perform address translation on the client virtual address requested by the target pass-through device based on the process page table of the target process; If the memory management unit or the input / output memory management unit returns an address translation result indicating a missing client memory page, it is determined that a missing client memory page has occurred. The process page table stores the correspondence between the client virtual address in the virtual memory space of the target process and the client physical address in the physical memory space of the virtualization instance.

12. A method for handling memory page faults, wherein, The method is applied to a page fault requesting device, which is located on a target physical peripheral on a host machine. The host machine has a virtualization instance deployed on it and is equipped with a target passthrough device obtained by virtualizing the target physical peripheral. The target passthrough device is bound to a target process running in the virtualization instance. The method includes: Obtain the page fault request initiated by the target pass-through device during the process of accessing the virtual memory space of the target process; The page fault request is sent to the page fault driver module in the operating system of the virtualization instance, so that the page fault driver module can call the memory management module in the operating system of the virtualization instance to allocate the missing guest memory page from the physical memory space of the virtualization instance.

13. The method according to claim 12, wherein, Sending the page fault request to the page fault driver module in the operating system of the virtualization instance includes: The page fault request is written into the page fault request queue, and an interrupt message is sent to the page fault driver module through the page fault interrupt register to trigger the page fault driver module to read the page fault request from the page fault request queue.

14. The method according to claim 13, wherein, Writing the page fault request to the page fault request queue includes: Obtain the address information of the page fault request queue in the physical memory space of the virtualization instance from the address register; Based on the address information, the page fault request is written into the page fault request queue.

15. A method for handling memory page faults, wherein, The method is applied to a page fault driver module, which resides in the operating system of a virtualization instance deployed on a host machine. The host machine has a target passthrough device mounted on it, and the target passthrough device is bound to a target process running in the virtualization instance. The method includes: The device receives a page fault request sent by a page fault requesting device, wherein the page fault request is sent by the target pass-through device when a client memory page is missing during access to the virtual memory space of the target process; Based on the page fault request, the memory management module in the operating system of the virtualization instance is invoked to allocate the missing guest memory page from the physical memory space of the virtualization instance.

16. The method according to claim 15, wherein, The receiving device sends a page fault request, including: Receive the interrupt message sent by the page fault requesting device through the page fault interrupt register; read the page fault request written by the page fault requesting device from the page fault request queue according to the interrupt message; Based on the page fault request, the memory management module in the operating system of the virtualization instance is invoked to allocate the missing guest memory page from the physical memory space of the virtualization instance, including: The page fault interrupt routine corresponding to the interrupt message is executed. The page fault interrupt routine calls the memory management module so that the memory management module allocates the missing guest memory page from the physical memory space of the virtualization instance.

17. An electronic device, wherein, The method includes a memory and a processor, the memory being used to store a computer program, and the processor being coupled to the memory for executing the computer program to implement the steps of the method according to any one of claims 9-11, 12-14, and 15-16.

18. A computer-readable storage medium storing a computer program / instructions, wherein, When the computer program is executed by a processor, it causes the processor to perform the steps of the method according to any one of claims 9-11, 12-14, and 15-16.

19. A computer program product, wherein, include: A computer program / instruction that, when executed by a processor, causes the processor to perform the steps of the method according to any one of claims 9-11, 12-14, and 15-16.

Images