IO device management methods, devices, systems, media and software products

Abstract

This application provides an I / O device management method, device, system, media, and program product. By cooperating between the host machine (i.e., the first host machine) where the virtual machine requiring cross-host I / O device allocation resides and the host machine providing the I / O device (i.e., the target host machine), I / O devices on the target host are allocated to virtual machines on the first host, thus achieving cross-host I / O device allocation. Compared to traditional virtualization, where virtual machines typically can only use the local I / O devices of their host machine, this breaks down the physical host machine boundary, allowing I / O resources to be pooled and shared throughout the entire cloud service system. This breaks down resource silos and enables virtual machines to use I / O devices on other hosts, exceeding the limit on the number of I / O devices a virtual machine can use due to local I / O devices.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to an I / O device management method, device, system, medium, and program product. Background Technology

[0002] With the rapid development of Artificial Intelligence (AI) technology and cloud computing, public and private cloud customers are increasingly demanding computing resources, especially for processing large-scale datasets and running complex machine learning models. These applications place higher demands on the performance of input / output (IO) devices in virtual machines, such as requiring the use of more high-performance, large-scale devices. However, in traditional virtualization models, both direct and shared device allocation are limited by the quantity and type of local hardware on the host machine. This not only limits the upper limit of the number of devices that a virtual machine can use but also hinders the flexible migration capabilities of virtual machines. Therefore, how to achieve cross-host IO device allocation for virtual machines while ensuring high IO performance has become a pressing technical challenge. Summary of the Invention

[0003] This application provides an IO device management method, device, system, media, and program product to enable cross-host allocation of IO devices for virtual machines, which can break through the upper limit of the number of IO devices that a virtual machine can use from a local IO device.

[0004] This application provides a cloud service system, including: multiple host machines; the multiple host machines are communicatively connected; a first host machine among the multiple host machines deploys a virtual machine; at least one second host machine among the multiple host machines has at least one input / output (I / O) device; the first host machine includes: a virtual machine manager and a device agent component;

[0005] In response to a cross-host allocation event for an I / O device, the virtual machine manager sends an I / O device request to the device proxy component, which then forwards the first I / O device request to a device service component in the target host; the at least one second host includes the target host.

[0006] In response to the IO device request, the device service component determines the target IO device from at least one IO device on the target host and obtains the configuration information of the target IO device; and returns the physical device identifier of the target IO device and the configuration information to the device agent component.

[0007] The device proxy component obtains the virtual device identifier of the target I / O device in the first host machine based on the physical device identifier; and sends the virtual device identifier and the configuration information to the virtual machine; the virtual device identifier has the same encoding method as the physical device identifier;

[0008] The virtual machine initializes and configures the resources of the target I / O device according to the virtual device identifier and the configuration information, so as to allocate the target I / O device to the virtual machine.

[0009] This application embodiment also provides an IO device management method, applicable to a first host machine where virtual machines are deployed, the method comprising:

[0010] In response to a cross-host allocation event for an input / output (I / O) device, a request is made to the target host to allocate the I / O device on the target host to the virtual machine;

[0011] Receive the first physical device identifier and the first configuration information of the first I / O device on the target host machine, returned by the target host machine;

[0012] Based on the first physical device identifier, obtain the first virtual device identifier of the first I / O device in the first host machine; the first virtual device identifier has the same encoding method as the first physical device identifier.

[0013] The first virtual device identifier and the first configuration information are sent to the virtual machine to allocate the first I / O device to the virtual machine.

[0014] This application also provides an I / O device management method applicable to a first host machine where virtual machines are deployed; the virtual machines are allocated a first I / O device on the target host machine; the first host machine includes: a device proxy component and a device driver proxy component running in the kernel of the first host machine; the method includes:

[0015] When an application in the virtual machine initiates an access operation to the first I / O device based on the first virtual device identifier, the device driver proxy component is used to send the target access request corresponding to the access operation to the device proxy component; the first virtual device identifier is the device identifier of the first I / O device in the first host machine.

[0016] The device proxy component is used to send the target access request to the target host machine; the first virtual device identifier is used by the target host machine to determine the first physical device identifier of the first IO device in the target host machine, and to access the first IO device based on the first physical device identifier to obtain a first access result;

[0017] The device proxy component is used to obtain the first access result returned by the target host machine, and the device driver proxy component is used to send the first access result to the application in the virtual machine.

[0018] This application embodiment also provides an I / O device management method, applicable to a first host machine where virtual machines are deployed, wherein the virtual machines are allocated a first I / O device on the target host machine; the first host machine includes: a device agent component; the method includes:

[0019] The device proxy component is used to obtain the first interrupt request of the first IO device forwarded by the target host.

[0020] The device proxy component is used to obtain the first physical device identifier of the first I / O device and the identifier of the target host machine from the first interrupt request; the first physical device identifier refers to the device identifier of the first I / O device in the target host machine;

[0021] The device proxy component uses the first physical device identifier of the first I / O device and the identifier of the target host machine to determine the first virtual device identifier of the first I / O device; the first virtual device identifier is the device identifier of the first I / O device in the first host machine;

[0022] The device proxy component uses the first virtual device identifier to query the mapping relationship between the target interrupt number and the first virtual device identifier maintained by the IOMMU in the first host machine, so as to obtain the target interrupt number of the first IO device in the first host machine;

[0023] The target interrupt number is sent to the interrupt management unit in the first host machine using the device proxy component, so that the interrupt management unit in the first host machine can perform interrupt processing based on the target interrupt number.

[0024] This application embodiment also provides an I / O device management method, applicable to a target host machine, wherein a first I / O device on the target host machine is allocated to a virtual machine on the first host machine for use; the target host machine includes: a device service component; the method includes:

[0025] The device service component is used to obtain the first I / O device request of the first host machine;

[0026] In response to the first IO device request, the device service component determines the first IO device from at least one IO device on the target host.

[0027] The device service component is used to return the physical device identifier of the first IO device and the first configuration information of the first IO device to the first host machine;

[0028] Wherein, the first physical device identifier is used for the first host to obtain the first virtual device identifier of the first I / O device in the first host; and to allocate the first I / O device to a virtual machine in the first host based on the first virtual device identifier and the first configuration information; the first virtual device identifier has the same encoding method as the first physical device identifier.

[0029] This application embodiment also provides an I / O device management method, applicable to a target host machine, wherein a first I / O device on the target host machine is allocated to a virtual machine on the first host machine for use; the target host machine includes: a device service component; the method includes:

[0030] The device service component is used to obtain the target access request for the first IO device sent by the first host.

[0031] In response to the target access request, the device service component determines the first physical device identifier of the first IO device; the first physical device identifier refers to the device identifier of the first IO device on the target host.

[0032] The device service component is used to access the first I / O device based on the first physical device identifier and the access requirements reflected in the access request, so as to obtain the access result;

[0033] The access result is returned to the first host machine using the device service component.

[0034] This application also provides an I / O device management method applicable to a target host machine, wherein a first I / O device on the target host machine is allocated to a virtual machine on the first host machine for use; the target host machine includes: a device service component and an interrupt management unit running in the kernel of the target host machine; the method includes:

[0035] In response to an interrupt event of the first I / O device, the interrupt management unit sends a first interrupt request to the device service component; the first interrupt request includes: a first physical device identifier and the identifier of the target host; the first physical device identifier refers to the device identifier of the first I / O device on the target host;

[0036] The device service component is used to send the first interrupt request to the first host machine; wherein the first physical device identifier and the identifier of the target host machine are used for the first host machine to determine the target interrupt number of the first I / O device in the first host machine, and to perform interrupt processing based on the target interrupt number.

[0037] This application also provides an electronic device, including: a memory and a processor; wherein the memory is used to store computer programs;

[0038] The processor is coupled to the memory and is used to execute the computer program to perform the steps in the above-described I / O device management methods.

[0039] This application also provides a computer-readable storage medium storing computer instructions, which, when executed by one or more processors, cause the one or more processors to perform the steps in the above-described I / O device management methods.

[0040] This application also provides a computer program product, including a computer program that, when executed by one or more processors, causes the one or more processors to perform the steps in the above-described I / O device management methods.

[0041] In this embodiment, by cooperating between the host machine (i.e., the first host machine) where the virtual machine requiring cross-host I / O device allocation resides and the host machine providing the I / O device (i.e., the target host machine), the I / O device on the target host machine is allocated to the virtual machine on the first host machine, thus achieving cross-host I / O device allocation. Compared to traditional virtualization, where virtual machines typically can only use the local I / O devices of their host machine, this breaks the boundaries of physical hosts, allowing I / O resources to be pooled and shared throughout the entire cloud service system. This breaks the limitation of resource silos and enables virtual machines to use I / O devices on other hosts, exceeding the upper limit on the number of I / O devices that a virtual machine can use due to local I / O devices. Furthermore, the target host machine returns a physical device identifier, and the first host machine, based on the physical device identifier, obtains a virtual device identifier with the same encoding method, and finally sends the virtual device identifier to the virtual machine. The operating system and device drivers within the virtual machine see a "physical" device with a device identifier that conforms to a standard bus interface specification (such as PCIe or PCI). The virtual machine will automatically enumerate, load drivers, and initialize as if it were a local I / O device, without requiring modification to the guest operating system and device drivers, thus improving the compatibility of this solution with existing virtual machine systems. Attached Figure Description

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

[0043] Figure 1 This application provides a schematic diagram of the structure of a cloud service system and a schematic diagram of the cross-host I / O allocation process.

[0044] Figure 2 and Figure 3 A schematic diagram illustrating the process of cross-host I / O allocation in a cloud service system provided in this application embodiment;

[0045] Figure 4 A schematic diagram illustrating the process of cross-host I / O device access in a cloud service system provided in this application embodiment;

[0046] Figure 5 A schematic diagram illustrating the process of cross-host machine interrupt handling for I / O devices in a cloud service system provided in this application embodiment;

[0047] Figure 6a and Figure 6b A flowchart illustrating the IO device management method provided in an embodiment of this application;

[0048] Figures 7-11Flowcharts illustrating other IO device management methods provided in embodiments of this application;

[0049] Figure 12 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0050] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application 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 application, and not all of them. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0051] It should be noted that, in the case of user information involved in the embodiments of this application, 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, data stored, data displayed, etc.) involved in the embodiments of this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0052] The concepts and terms involved in the embodiments of this application will be explained below.

[0053] Virtualization is a computing model that uses software technology to simulate hardware resources (such as processors, memory, storage, network cards, etc.), allowing a physical resource to be divided into multiple logical instances.

[0054] Kernel-Based Virtual Machine (KVM) is an open-source, fully virtualization solution based on the Linux kernel (an operating system), which allows multiple virtual machines to run on hardware that supports virtualization extensions.

[0055] Virtual Machine Manager (VMM): The VMM is a core component of virtualization technology, responsible for creating, running, and managing virtual machines. A Hypervisor is a specific implementation of a virtual machine manager; it's middleware software running between the physical server and the operating system, allowing multiple operating systems and applications to share a single set of underlying physical hardware.

[0056] I / O devices are hardware or virtual devices in a computer system used to exchange data with the outside world, such as disks, network cards, and keyboards.

[0057] Hardware device driver: The hardware device driver is responsible for interacting with I / O devices and converting data read and write requests from upper-layer programs into instructions that the device can execute.

[0058] Peripheral Component Interconnect (PCI): PCI is a standard interface for connecting peripheral devices on a computer motherboard. PCI offers advantages such as high data transfer rates and plug-and-play functionality.

[0059] Peripheral Component Interconnect Express (PCIe): PCIe is an extension of PCI, a high-speed serial computer expansion bus standard used to connect hardware devices within a computer (such as graphics cards, sound cards, storage controllers, network interface cards, etc.). Compared to the traditional parallel PCI bus, PCIe offers higher bandwidth, lower latency, and better scalability.

[0060] Bus Number-Device Number-Function Number (BUS, Device and Function, BDF): BDF is a device identifier, a coding method used in the PCI or PCIe bus standard to uniquely identify each device or device function.

[0061] Interrupt: An asynchronous event notification mechanism in a computer system that allows hardware devices or software programs to interrupt the current task of the Central Processing Unit (CPU) and request immediate processing of urgent or high-priority operations.

[0062] The virtualization technology involved in the embodiments of this application will be described below.

[0063] 1. PCI Passthrough: PCI passthrough is a virtualization technology that allows virtual machines (VMs) to directly access physical hardware devices (such as I / O devices), bypassing the VMM's software emulation layer to achieve near-native performance. Its core relies on the Input-Output Memory Management Unit (IOMMU) to achieve device isolation and secure access. The IOMMU is a key hardware unit connecting the processor (such as the CPU) and I / O devices, primarily managing I / O device access to memory and interrupt isolation, playing a central role in virtualization, security, and high-performance computing.

[0064] Under device passthrough technology, I / O devices can be directly assigned to virtual machines, i.e., direct device allocation mode, such as Virtualization Technology for Directed I / O (VT-d) and Virtualization with I / O Memory Management Unit (IMU) technology. VT-d is a hardware-assisted virtualization technology specifically designed to support and enhance I / O device operations in virtualized environments. It provides features such as Direct Memory Access (DMA) remapping and interrupt remapping, allowing virtual machines to directly access physical I / O devices (such as network interface cards and storage controllers) while maintaining system security and isolation. VT-d is implemented based on the IOMMU (Input / Output Memory Management Unit) architecture, which helps improve performance and security in virtualized environments.

[0065] Virtualization technology supporting I / O memory management units is a hardware-assisted virtualization technology focused on enhancing the security and performance of I / O devices in a virtualized environment. This technology allows virtual machines to directly access physical I / O devices and ensures that the operation of these devices does not affect the security of other virtual machines or the host system through DMA remapping and interrupt remapping. This technology helps improve I / O performance in virtualized environments and provides better resource isolation.

[0066] In the direct device allocation mode, physical I / O devices are directly assigned to a single virtual machine. The virtual machine can directly access the physical I / O device as if it were its own. Virtual machines in direct device allocation mode have the highest I / O device performance because there is no intermediate layer for translation, resulting in almost no performance loss. However, in direct device allocation mode, an I / O device can only be assigned to one virtual machine, and multiple virtual machines cannot share the same I / O device. It also requires the motherboard to support corresponding virtualization technologies, such as VT-d or virtualization technologies that support I / O memory management units. Furthermore, in direct device allocation mode, virtual machines can only be migrated to a host machine that can provide the required I / O device, thus limiting virtual machine migration.

[0067] 2. Hardware-based virtualization technologies, such as Single Root I / O Virtualization (SR-IOV): Hardware-based virtualization technologies (such as SR-IOV) can virtualize I / O devices into multiple virtual I / O devices, such as multiple virtual functions (VFs). Each VF can be assigned to different virtual machines or processes, allowing them to directly access hardware resources and reducing the overhead of the virtualization layer. SR-IOV is a hardware acceleration technology based on the PCIe specification, designed to improve the performance and efficiency of I / O devices in a virtualized environment. SR-IOV allows virtual machines to directly access physical I / O devices, bypassing the VMM's emulation layer, thereby reducing latency during data transfer and increasing throughput. Since data can be transferred directly between I / O devices and virtual machines without going through the VMM, the involvement of the processor (such as the CPU) is greatly reduced, freeing up computing resources. Each VF is a lightweight PCIe function with its own independent resource set (such as memory, registers, etc.), ensuring that operations between different virtual machines are isolated from each other. Each SR-IOV-enabled device has a Physical Function (PF) responsible for managing and configuring the VF.

[0068] SR-IOV technology allows multiple virtual machines to share a single physical I / O device, offering greater flexibility and performance close to direct device allocation. However, virtual machine migration is limited to hosts that can provide the required I / O device and that the device itself supports SR-IOV.

[0069] 3. Virtualized I / O (Virtio): Virtio is a paravirtualization solution that requires the virtual machine operating system to have the Virtio driver installed. Virtio establishes an efficient communication channel between the virtual machine and the host machine. Virtio is an I / O virtualization standard for virtualized environments, designed to provide an efficient and universal interface that enables virtual machines to perform efficient I / O operations with the VMM. Virtio defines a standardized set of mechanisms and protocols for simulating various types of I / O devices such as network, storage, memory, and console devices, thereby improving virtual machine performance and reducing dependence on specific hardware. Virtio devices are virtualized, but they are designed to reduce virtualization overhead.

[0070] Virtio-net is a virtual network interface card based on the Virtio standard. It allows virtual machines to communicate with the host machine or other virtual machines via the Virtio interface. Compared to traditional fully virtualized or semi-virtualized network devices, virtio-net offers higher performance and lower latency because it reduces the overhead of the virtualization layer and supports direct data packet transmission between the virtual machine and the host machine.

[0071] The Virtual Host User (vhost-user) protocol is an extension protocol designed to optimize data path processing on Virtio-based high-performance network and storage devices. It allows some data processing tasks to be offloaded from the user-space VMM (Virtual Machine Manager) such as QEMU to dedicated background processes or user-space applications, thereby reducing the VMM's workload and improving overall system performance. Specifically, vhost-user is typically used to accelerate network functions, such as communication between virtual switches and virtual machines.

[0072] Virtio can support multiple virtual machines sharing a device; however, it requires the virtual machines to have the Virtio driver installed, and its performance is not as good as device passthrough and SR-IOV.

[0073] 4. Quick Emulator (QEMU) - Pure Software Emulation: QEMU is an open-source hardware virtualization software that can run on a host operating system and provides support for other operating systems. It creates a virtual machine environment by simulating computer hardware (such as CPU, memory, I / O devices, etc.), allowing users to run multiple different operating system instances simultaneously on a single physical machine. A device (such as a network card) is entirely simulated by QEMU software; the virtual machine sees a "fake device," while QEMU uses the real device to help the virtual machine complete operations behind the scenes. This virtualization technology requires no hardware support and no cooperation from the guest operating system; it is a relatively simple implementation method in virtualization. However, all operations in this virtualization technology are simulated by QEMU software, resulting in the worst virtual machine performance and significant latency in I / O device operations.

[0074] Device passthrough technology and SR-IOV virtualization technology require the use of the local I / O devices of the host machine where the virtual machine is located, which limits the upper limit of the number of I / O devices that the virtual machine can use.

[0075] In some embodiments of this application, a scheme for allocating I / O devices to virtual machines across host machines is proposed to overcome the upper limit on the number of I / O devices used by virtual machines. Specifically, the host machine where the virtual machine requiring cross-host I / O device allocation resides (i.e., the first host machine) cooperates with the host machine providing the I / O devices (i.e., the target host machine) to allocate the I / O devices on the target host machine to the virtual machines on the first host machine, thus realizing the cross-host allocation of I / O devices. Compared to the traditional virtualization scheme where virtual machines can usually only use the local I / O devices of their host machine, this breaks the physical host machine boundary, allowing I / O resources to be pooled and shared throughout the entire cloud service system, breaking the limitation of resource silos, and enabling virtual machines to use I / O devices on other hosts across host machines, thus overcoming the upper limit on the number of I / O devices that a virtual machine can use due to local I / O devices. In addition, the device service component returns a physical device identifier, and the device agent component obtains a virtual device identifier with the same encoding method based on the physical device identifier, and finally sends the virtual device identifier to the virtual machine. The operating system and device driver inside the virtual machine see a "physical" device with a device identifier with a standard bus interface specification (such as PCIe or PCI). The virtual machine will automatically enumerate, load drivers, and initialize as if it were a local I / O device, without requiring modification to the guest operating system and device drivers, thus improving the compatibility of this solution with existing virtual machine systems.

[0076] The technical solutions provided by the various embodiments of this application are described in detail below with reference to the accompanying drawings.

[0077] It should be noted that the same reference numerals in the following figures and embodiments denote the same object or the same step. Therefore, once an object or step is defined in one figure or embodiment, it does not need to be discussed further in subsequent figures and embodiments.

[0078] Figures 1-3 This is a schematic diagram of the cloud service system provided in an embodiment of this application. The cloud service system can be a public cloud service system or a private cloud service system. Figures 1-3As shown, the cloud service system includes multiple host machines, such as a first host machine 10 and a target host machine 20. "Multiple" refers to two or more (including two). Virtual machines can be deployed on the host machines. Virtual machines can be deployed on some or all of the multiple host machines. The first host machine 10 refers to the host machine among the multiple host machines that has deployed virtual machine 101; it can be any one of the multiple host machines. In this embodiment, for ease of description and distinction, the other host machines among the multiple host machines besides the first host machine 10 are defined as second host machines. The number of second host machines can be one or more, and is less than the total number of host machines in the cloud service system. The second host machines include the target host machine 20; that is, the target host machine 20 is one of the second host machines.

[0079] The second host machine has one or more I / O devices. "Multiple" refers to two or more (including two). The I / O devices can communicate with the host machine's processor via a bus interface. The bus interface can be a serial bus interface, such as PCI, PCIe, or other bus interfaces. In this embodiment, the specific implementation of the I / O devices is not limited. For example, the I / O device can be a storage device, such as a hard disk or magnetic disk, or it can be a network card, keyboard, graphics card, or other physical device. The first host machine 10 may also have I / O devices; however, the first host machine 10 may also not have I / O devices, and this is not limited in this embodiment.

[0080] In this embodiment, multiple host machines communicate with each other. These multiple host machines can be connected wirelessly or via wired connections. Optionally, multiple host machines can be connected via a mobile network. Accordingly, the network standard of the mobile network can be any one of the following: 2G (such as Global System for Mobile Communications (GSM)), 2.5G (such as General Packet Radio Service (GPRS)), 3G (such as Wideband Code Division Multiple Access (WCDMA), Time Division-Synchronous Code Division Multiple Access (TD-SCDMA), Code Division Multiple Access 2000 (CDMA2000), Universal Mobile Telecommunications System (UTMS)), 4G (such as Long Term Evolution (LTE)), 4G+ (such as LTE-Advanced (LTE-A)), 5G, and World Interoperability for Microwave Access (WiMax). Alternatively, multiple host machines can also communicate and connect via Bluetooth, Wireless Fidelity (WiFi), infrared, or other means.

[0081] For host machines that have deployed virtual machines, such as Figures 1-3 The first host machine 10 shown may include a Virtual Machine Manager (VMM) 102. The VMM 102 is a core component of virtualization technology, responsible for creating and managing virtualized environments between physical hardware and virtual machines (VMs). The VMM 102 is a software module running on the host machine's processor (such as the CPU), primarily used to isolate multiple virtual machines, enabling them to independently and securely share the resources of the same physical machine. The VMM 102 can also perform virtual machine lifecycle management, etc.

[0082] In this embodiment, in order to allocate I / O devices to virtual machines across host machines, such as Figures 1-3As shown, a device agent component 103 can be added to a host machine where virtual machines are deployed, such as the first host machine 10. The device agent component 103 is a software function module that runs on the host machine's processor (such as the CPU). The device agent component 103 can run on the host machine's operating system, such as in the user space of the host machine's operating system.

[0083] Since VMM 102 is responsible for resource management on the host machine, including processors, memory, storage, and I / O devices, only the VMM can have a comprehensive understanding of the usage of all resources in the system, thereby making appropriate resource allocation decisions. In a multi-tenant environment, each virtual machine should be strictly isolated to ensure security and stability. The VMM can control the allocation of I / O devices to ensure that different virtual machines do not interfere with each other or access resources that do not belong to them. Therefore, in the traditional host machine local I / O device allocation scheme, the VMM is responsible for the allocation of I / O devices. To reduce the intrusion into the traditional host machine local I / O device allocation process, in this embodiment, the VMM can initiate a cross-host machine I / O device allocation process.

[0084] Based on this, such as Figures 1-3 As shown, VMM 102 can monitor cross-host allocation events for I / O devices. In this embodiment, the specific implementation of the cross-host allocation event is not limited. In some embodiments, the user corresponding to the virtual machine can initiate a request for cross-host allocation of I / O devices to the control node of the cloud service system (not shown in the figures). The control node of the cloud service system can send the request for cross-host allocation of I / O devices to the VMM on the host machine where the user's virtual machine resides. The host machine where the user's virtual machine resides is the host machine where the virtual machine requiring cross-host allocation of I / O devices resides. In this embodiment and... Figures 1-3 In this example, only the host machine where the virtual machine that needs to allocate I / O devices across host machines is located is taken as the first host machine 10, but this does not constitute a limitation.

[0085] Requests to allocate I / O devices across hosts can include: the type and performance requirements of the I / O device. The type of I / O device can include: hard drives, network cards, keyboards, and graphics cards, etc. The performance requirements of the I / O device refer to the required performance parameters. Different types of I / O devices have different performance parameters. For hard drive I / O devices, performance parameters can include: storage capacity and read / write speed. For network card I / O devices, performance parameters can include: bandwidth and throughput. For graphics card I / O devices, performance parameters can include: core frequency, video memory size, and bandwidth. For keyboard I / O devices, performance parameters can include: key type and response time.

[0086] The control node can determine, from at least one second host, a target host 20 that has an idle IO device that meets the corresponding performance requirements, based on the IO device type and performance requirements included in the IO device request, the IO device type and performance parameters on the second host, and the IO device usage status on the second host. Further, the control node can initiate a cross-host allocation request for the IO device to the VMM 102 in the first host 10. This cross-host allocation request may include: the IO device type, performance requirements, and the identifier of the target host. The target host refers to the host used to provide the IO device. Accordingly, upon receiving a cross-host allocation request for the IO device, a cross-host allocation event for the IO device can be determined to have occurred.

[0087] In other embodiments, the user corresponding to the virtual machine can initiate an I / O device request to the control node of the cloud service system (not shown in the accompanying drawings) based on their I / O device needs. This I / O device request may include: the type of I / O device and its performance requirements.

[0088] The control node can receive I / O device requests and, based on the type and performance requirements of the I / O devices included in the request, as well as the type and performance parameters of the I / O devices on the first host 10, determine whether there are any idle I / O devices on the first host 10 that meet the corresponding performance requirements. Idle I / O devices refer to I / O devices that have not been allocated to other virtual machines. If there are idle I / O devices on the first host 10 that meet the performance requirements, the I / O device is allocated to a virtual machine, and the cross-host I / O device allocation process is not initiated. If there are no idle I / O devices on the first host 10 that meet the performance requirements, the control node initiates a cross-host I / O device allocation request to VMM 102.

[0089] Specifically, the control node can determine, from at least one second host, the target host based on the type and performance requirements of the IO device in the IO device request, the type and performance parameters of the IO devices on the second host, and the usage status of the IO devices on the second host. Further, the control node can initiate a cross-host allocation request for the IO device to the VMM 102 in the first host 10. This cross-host allocation request may include: the type of IO device, performance requirements, and the identifier of the target host. The target host refers to the host used to provide the IO device. Accordingly, upon receiving a cross-host allocation request for the IO device, a cross-host allocation event for the IO device can be determined to have occurred. Figures 1-3 The VMM 102 shown in step 1 detected a cross-host allocation event for the IO device.

[0090] like Figures 1-3 As shown in step 2, the VMM 102 in the first host 10 can send an IO device request to the device agent component 103 in response to a cross-host allocation event. The IO device request may include: the type of IO device, the performance requirements of the IO device, and the identifier of the target host.

[0091] In this embodiment of the application, in order to allocate I / O devices to virtual machines across hosts, such as Figures 1-3 As shown, a device service component 201 can be added to the host machine providing the I / O device (such as the target host machine 20). The device service component 201 is a software functional module running on the host machine providing the I / O device, and can run within the host machine's operating system, such as the host machine's user space. The device service component 201 works in conjunction with a device proxy component on the host machine (such as the first host machine) requesting cross-host machine I / O device allocation to achieve cross-host machine I / O device allocation. The same host machine can be implemented only as the I / O device requesting end or only as the I / O device providing end. When the host machine is only implemented as the I / O device requesting end, its internal structure framework is as follows: Figures 1-3 The internal structure framework of the first host machine 10 is shown in the figure. When the host machine only provides an end for I / O devices, its internal structure framework is as follows. Figure 1 and Figure 2 The internal structure framework of the target host machine 20 is shown in the diagram. Of course, a host machine can also act as both a requester and provider of I / O devices; that is, the host machine includes a virtual machine manager, device agent components, and device driver agent components, and may also include device service components. This host machine deploys virtual machines and can both request and allocate I / O devices from other hosts, and provide I / O devices to virtual machines on other hosts.

[0092] Accordingly, such as Figures 1-3 As shown in step 3, the device proxy component 103 can send IO device requests to the device service component 201 in the target host machine 20. Figure 1 and Figure 2 As shown in step 4, the device service component 201 can, in response to an IO device request, determine a target IO device 203 from at least one IO device on the target host 20. The target IO device can be a physical IO device or a virtual device (VF) obtained by virtualizing a physical IO device using SR-IOV technology. In the embodiment where virtualization is performed using device passthrough technology, the target IO device is a physical IO device; in the embodiment where virtualization is performed using SR-IOV technology, the target IO device is a virtual device obtained by virtualizing a physical IO device using SR-IOV technology. Figure 1 and Figure 2The illustrations only use the target I / O device as the physical I / O device, but this does not constitute a limitation.

[0093] Specifically, the device service component 201 can obtain the target type and performance requirements of the requested IO device from the IO device request; then, based on the target type and performance requirements information, it can determine the currently idle target IO device from at least one IO device on the target host. The target IO device is of the target type and its performance metrics meet the performance requirements. The target IO device determined in this embodiment ensures that the IO devices allocated to the virtual machine can meet its specific application requirements, thereby guaranteeing the stability and efficiency of application operation.

[0094] In some embodiments, the I / O device is a physical I / O device, and the target I / O device is also a physical I / O device. If there is one currently idle I / O device of the target type with performance metrics that meet the performance requirements, then that I / O device is determined as the target I / O device. If there are multiple currently idle I / O devices of the target type with performance metrics that meet the performance requirements, then one of these I / O devices can be selected as the target I / O device. Alternatively, the I / O device whose performance parameters are closest to the corresponding performance requirements can be selected as the target I / O device, which can reduce resource waste while meeting performance requirements.

[0095] In other embodiments, the I / O device is a virtual device obtained by virtualizing physical I / O devices using SR-IOV technology. If there is one currently idle I / O device of the target type with performance indicators meeting the requirements, then that I / O device can be identified as the target I / O device. If there are multiple currently idle I / O devices of the target type with performance indicators meeting the requirements, then one of these I / O devices can be selected as the target I / O device. Alternatively, the physical I / O devices corresponding to each of these multiple I / O devices can be identified, and the number of occupied virtual devices corresponding to each physical I / O device can be counted. Then, from all the physical I / O devices, the physical I / O device with the fewest occupied virtual devices can be selected, and the idle virtual device corresponding to that physical I / O device can be identified as the target I / O device. Selecting the virtual device of the physical I / O device with the fewest occupied virtual devices and allocating it to the virtual machine helps to achieve load balancing.

[0096] After identifying the target I / O device, the device service component 201 can also obtain the device identifier of the target I / O device 203. The device identifier is a standardized code or symbol used in a computer system to uniquely identify a hardware device. It is typically defined by hardware specifications, operating systems, or bus protocols, and is unique within the same bus or topology. It allows the system to distinguish different devices and allocate resources correctly. In embodiments where the bus interface between the host and the I / O device is a PCIe or PCI interface, the device identifier can be a BDF (Best Defender).

[0097] like Figure 2 and Figure 3 As shown in step 5, the device service component 201 can interact with the device driver 202 in the target host machine 20 to obtain the device identifier of the target I / O device 203. The device driver 202 is a kernel module that runs in the kernel of the target host machine 20. The device driver 202 can access the configuration space of the target I / O device and obtain the device identifier (such as BDF) and configuration information of the target I / O device from its configuration space. The configuration information of the target I / O device refers to the set of data obtained by the operating system or system firmware from the configuration space registers of each I / O device to identify, initialize, configure, and manage I / O devices connected to the serial bus. The configuration information includes the device's identity, resource requirements, functional characteristics, and other control and status data, which is the basis for ensuring that the device can operate correctly and work collaboratively with other parts of the system. The configuration information may include: basic device attributes such as vendor ID, device ID, and class code; resource requirements such as memory address range and I / O ports; and base address registers (BARs). BARs define the size and type of address space required by a device so that the system can allocate an appropriate address range to the I / O device.

[0098] Furthermore, such as Figure 2 and Figure 3 As shown in step 5, the device driver 202 can return the device identifier and configuration information of the target I / O device to the device service component 201. Here, the device identifier of the target I / O device is the device identifier of the target I / O device in the target host machine; it is the actual device identifier of the target I / O device and can be defined as a physical device identifier. For example... Figure 1 Step 5 and Figure 2 and Figure 3As shown in step 6, the device service component 201 can return the physical device identifier and configuration information of the target I / O device to the device agent component 103. After returning the physical device identifier of the target I / O device to the device agent component 103, the target I / O device can also be marked as occupied to prevent duplicate allocation of the target I / O device and reduce usage conflicts of the target I / O device.

[0099] like Figure 1 As shown in step 6, the device agent component 103 can obtain the virtual device identifier of the target I / O device in the first host machine 10 based on the physical device identifier of the target I / O device. This virtual device identifier is the device identifier of the target I / O device on the first host machine; it is not the actual device identifier of the target I / O device, and is therefore defined as a virtual device identifier. The virtual device identifier has the same encoding method as the physical device identifier, allowing the virtual machine to see a "real" I / O device with a standard device identifier. The operating system and device drivers do not need to be modified; they will discover, enumerate, configure, and initialize this virtual device through standard configuration space access mechanisms, just like with physical I / O devices.

[0100] On the other hand, using a virtual device identifier to represent the target I / O device on the first host 10, instead of using the target I / O device's actual device identifier (i.e., physical device identifier), can prevent I / O device identifier conflicts. This is because virtual machines in the first host 10 may be assigned to I / O devices on multiple other hosts. Each host's device identifier is independently encoded; therefore, I / O devices on different hosts may have the same device identifier. In an embodiment where multiple I / O devices from different hosts but with the same device identifier are all assigned to virtual machines on the first host, if the physical device identifiers of these multiple I / O devices are used to represent the I / O devices on the first host, it will lead to device identifier conflicts among these I / O devices. That is, the virtual machine will see multiple I / O devices with the same device identifier, causing subsequent operations to fail. Therefore, this embodiment uses a virtual device identifier to represent the target I / O device to prevent I / O device identifier conflicts.

[0101] In this embodiment, the specific implementation method by which the device proxy component 103 obtains the virtual device identifier of the target I / O device in the first host 10 is not limited. In some embodiments, the device proxy component 103 may generate a virtual device identifier for the target I / O device based on the encoding method of the physical device identifier. The encoding method of the virtual device identifier is the same as that of the physical device identifier.

[0102] Optionally, if the I / O device is a PCI device or a PCIe device, then the device identifier is BDF. In some embodiments, a portion of the bus number and a portion of the device number may be reserved. When generating a virtual device identifier for the target I / O device, the encoding method of the physical device identifier can be obtained. Taking a standard PCIe BDF as an example, the bus number is 8 bits, ranging from 0x00 to 0xFF (0-255); the device number is 5 bits, ranging from 0x00 to 0x1F (0-31); and the function number is 3 bits, ranging from 0 to 7. Based on the reserved bus number, and reserving a portion of the device number under the reserved bus number, one or more specific bus numbers (such as 0x80, 0x81) can be selected specifically for all virtual devices, and on a certain bus (such as 0x00), the higher-numbered Devices (such as 0x18 to 0x1F) can be reserved for virtual devices, etc. Accordingly, when generating a virtual device identifier for a target I / O device, an unassigned target bus number can be selected from the reserved bus numbers; an unassigned target device number can be selected from the reserved device numbers under the target bus number; and a target function number can be randomly selected from the range of function numbers. Alternatively, an assigned target bus number can be selected from the reserved bus numbers; an unassigned target device number can be selected from the reserved device numbers under that target bus number; and a target function number can be randomly selected from the range of function numbers, and so on. Then, the target bus number, target device number, and target function number can be assembled according to the encoding method of the physical device identifier to obtain the virtual device identifier.

[0103] In this embodiment, a virtual device identifier is generated by reserving bus numbers and device numbers. Since the reserved bus numbers and device numbers are within the valid range of the device identifier encoding specification, the generated virtual device identifier conforms to the device identifier encoding specification, eliminating the need for encoding specification verification and improving the generation efficiency of virtual device identifiers. Furthermore, by reserving a dedicated range of bus numbers or device numbers, a clear "isolation zone" is established between virtual devices and physical devices in the identifier space, reducing the possibility of conflicts between virtual device identifiers and physical device identifiers.

[0104] In other embodiments, the device agent component can obtain the encoding method of the physical device identifier and perform a hash operation on the current timestamp to obtain the hash result. The character length of the hash result is greater than or equal to the length of the device identifier. According to the encoding method of the physical device identifier, characters of the same length as the bus number, device number, and function number are extracted from the hash result, and these characters are assembled according to the encoding method of the physical device identifier to obtain a candidate device identifier.

[0105] In some embodiments, the device agent component can use the current timestamp as a random seed and, with a set character length as a parameter, generate a random number of a set string length. The set string length is greater than or equal to the length of the device identifier. Since the current timestamp is unique, using the current timestamp as a random seed ensures that each generated random number is different, i.e., the generated random number has strong randomness. On the other hand, the current timestamp is the system timestamp of the service device, which can be easily and quickly obtained, thus resulting in faster random number generation.

[0106] Specifically, the current timestamp can be used as a random seed input into the pseudo-random number generation algorithm to initialize the internal state of the random number generator, resulting in an initialized random number generator. This step ensures that the subsequently generated random numbers are based on the current timestamp, exhibiting good randomness and unpredictability. Further, the initialized random number generator can be invoked to request the generation of a random number with a set string length. Then, according to the encoding method of the physical device identifier, characters of the same length as the bus number, device number, and function number can be extracted from the random number of the set string length, and these characters can be assembled according to the encoding method of the physical device identifier to obtain candidate device identifiers.

[0107] To ensure that candidate device identifiers conform to the device identifier encoding standard, a encoding standard verification is performed on the candidate device identifiers. If the bus number, device number, and function number in the candidate device identifier are all within their respective valid ranges, then the candidate device identifier is determined to conform to the device identifier encoding standard. If any of the bus number, device number, or function number in the candidate device identifier is not within its respective valid range, then the candidate device identifier is determined to not conform to the device identifier encoding standard. If a candidate device identifier does not conform to the device identifier encoding standard, the current timestamp is obtained, and the hash calculation and the above candidate device identifier generation operation are performed again until the candidate device identifier conforms to the device identifier encoding standard.

[0108] Furthermore, the uniqueness of candidate device identifiers can be verified. Specifically, the device agent component can query the kernel of the first host machine to obtain a list of currently allocated device identifiers, including physical device identifiers and / or virtual device identifiers. If there is no candidate device identifier in the list of currently allocated device identifiers, the candidate device identifier is determined to be unique and can be identified as the aforementioned virtual device identifier. If there is a candidate device identifier in the list of currently allocated device identifiers, the candidate device identifier is determined to be non-unique. In this case, the current timestamp is obtained, and the hash calculation and the aforementioned candidate device identifier generation operation are performed again until the candidate device identifier conforms to the device identifier encoding specification and is unique.

[0109] This implementation does not require any pre-defined reserved range. The hash algorithm can explore the entire valid identifier space (Bus: 0-255, Device: 0-31), theoretically generating any valid BDF. Identifiers can be generated dynamically, improving the flexibility of virtual device identifier generation. On the other hand, using a timestamp hash function to generate candidate device identifiers is also beneficial. Since hash functions are extremely sensitive to even small changes in the input (timestamp), each generated candidate device identifier is different. This increases the probability that the generated candidate identifier passes uniqueness verification on the first try, typically eliminating the need for many retries.

[0110] The foregoing embodiments have provided an exemplary description of the specific implementation method by which the device proxy component 103 generates the virtual device identifier of the target I / O device in the first host machine 10. In some embodiments, such as Figure 2 and Figure 3 As shown, the first host machine 10 can be equipped with a device driver proxy component 104. The device driver proxy component 104 is a software module, and can also be a kernel module, running within the kernel of the first host machine. Accordingly, as... Figure 2 and Figure 3 As shown in step 7, the device proxy component 103 can register the virtual I / O device with the device driver proxy component 104 based on the physical device identifier. Specifically, the device proxy component 103 can initiate a registration request to the device driver proxy component 104 based on the physical device identifier, and the registration request may include the physical device identifier. In response to the registration of the virtual I / O device, the device driver proxy component 104 can assign a virtual device identifier to the virtual I / O device, thereby realizing the registration of the virtual I / O device in the device driver proxy component 104. The virtual device identifier assigned to the virtual I / O device is the device identifier of the target I / O device on the first host machine.

[0111] In some embodiments, the device driver proxy component 104 can select unallocated device identifiers from the device identifiers maintained by the kernel and assign these unallocated device identifiers as virtual device identifiers to the virtual I / O device. This embodiment allows the virtual machine to perceive a "real" I / O device with a standard device identifier. The operating system and device drivers do not need modification and will discover, enumerate, configure, and initialize this virtual device using standard configuration space access mechanisms, just like with physical I / O devices. On the other hand, the allocation of device identifiers is centrally managed by the kernel, which maintains a real-time updated list of "allocated identifiers." When the device driver proxy component selects from the kernel's "unallocated pool," the kernel automatically marks it as "occupied," preventing device identifier conflicts within the same scope (such as the host machine or a specific virtual machine bus), ensuring system stability and reliable device identification.

[0112] In other embodiments, the device driver proxy component 104 can generate a virtual device identifier for the virtual I / O device based on the encoding method of the physical device identifier. The encoding method of this virtual device identifier is the same as that of the device identifier. For a detailed implementation of how the device driver proxy component 104 generates a virtual device identifier based on the encoding method of the physical device identifier, please refer to the aforementioned content regarding the generation of a virtual device identifier based on the encoding method of the physical device identifier in the device proxy component 103, which will not be repeated here. Since the virtual device identifier has the same encoding method as the device identifier, the virtual machine sees a "real" I / O device with a standard device identifier. The operating system and device driver do not need to be modified; they will discover, enumerate, configure, and initialize this virtual device through the standard configuration space access mechanism, just like with physical I / O devices. Furthermore, the device driver proxy component can define its own rules for generating virtual device identifiers, which helps improve the flexibility and customizability of virtual device identifier generation. In addition, the device driver proxy component automatically generates virtual device identifiers based on encoding rules, without completely relying on the query interface provided by the kernel, which may reduce the coupling with inherent modules in the kernel and make the device driver proxy component more independent.

[0113] In this embodiment, a virtual device identifier is used to represent the target I / O device on the first host 10, instead of using the target I / O device's actual device identifier (i.e., physical device identifier), to prevent I / O device identifier conflicts. This is because virtual machines in the first host 10 may be assigned to I / O devices on multiple other hosts. Each host's device identifier is independently encoded; therefore, I / O devices on different hosts may have the same device identifier. In an embodiment where multiple I / O devices from different hosts but with the same device identifier are all assigned to virtual machines in the first host, if the physical device identifiers of these multiple I / O devices are used to represent the I / O devices on the first host, it will lead to device identifier conflicts among these I / O devices. That is, the virtual machine will see multiple I / O devices with the same device identifier, causing subsequent operations to fail. Therefore, this embodiment uses a virtual device identifier to represent the target I / O device to prevent I / O device identifier conflicts.

[0114] Furthermore, such as Figure 2 and Figure 3 As shown in step 8, the device driver proxy component 104 can send the virtual device identifier to the device proxy component 103, and the device proxy component can receive the virtual device identifier returned by the device driver proxy component 104, thereby obtaining the virtual device identifier.

[0115] In this embodiment, since the device driver proxy component running in the kernel can directly access and manage hardware resources, such as the PCI configuration space and memory-mapped I / O regions, it can more efficiently query the device identifiers already allocated in the current system and generate conflict-free virtual device identifiers based on this information. Therefore, using the device driver proxy component running in the kernel to generate virtual device identifiers allows direct querying of the allocated device identifiers maintained by the kernel, without the need for context switching between kernel and user modes, thus improving the efficiency of virtual device identifier generation.

[0116] In some embodiments, interrupt handling of the target I / O device is also required. Accordingly, such as Figure 3 As shown in step 9, the device agent component 103 can also request an interrupt number for the target I / O device from the interrupt management unit 105 in the first host machine 10 based on the virtual device identifier. The interrupt management unit 105 runs in the kernel of the first host machine and is an inherent kernel module of the first host machine. In response to the interrupt number request, the interrupt management unit 105 can assign a target interrupt number to the virtual device identifier, and as follows... Figure 3 As shown in step 10, the target interrupt number is returned to the device agent component 103. This target interrupt number can ultimately be assigned to the target I / O device. Specifically, as... Figure 3As shown in step 11, the device agent component 103 can send the target interrupt number to the VMM 102. The VMM 102 can configure the mapping relationship between the target interrupt number and the virtual interrupt number in the virtual machine in the Input / Output Memory Management Unit (IOMMU) (not shown in the figures), thereby assigning the target interrupt number to the target I / O device. The IOMMU is a hardware unit used to manage and map the physical addresses of direct memory access to devices, providing address translation services for direct memory access operations. The IOMMU also provides interrupt remapping functionality. Interrupt remapping can redirect interrupt requests generated by the I / O device to a specified virtual machine. In this embodiment, assigning an interrupt number to the target I / O device in the first host machine supports interrupt handling for the target I / O device by the virtual machine in the first host machine.

[0117] After obtaining the virtual device identifier, device agent component 103, such as Figure 1 Steps 6 and 7 Figure 2 Steps 9 and 10 and Figure 3 As shown in steps 11 and 12, the virtual device identifier and the configuration information of the target I / O device can be sent to the virtual machine 101 via VMM 102. The virtual machine 101 can initialize and configure the resources of the target I / O device based on the virtual device identifier and the configuration information, thereby allocating the target I / O device to the virtual machine 101, i.e., achieving cross-host allocation of I / O devices. Specifically, the virtual machine 101 can identify the target I / O device based on the virtual device identifier. Specifically, the virtual machine 101 can obtain the configuration information of the target I / O device corresponding to the virtual device identifier. By reading this information, the virtual machine formally "discovers" a new I / O device and knows its basic identity and type, i.e., achieving device identification. Afterwards, the virtual machine can search and match in the kernel's driver database or loaded driver modules based on the configuration information to obtain the driver that matches the configuration information of the target I / O device, i.e., the device driver of the target I / O device, and then... Figure 3 As shown, the device driver 106 of the target I / O device is installed in the kernel of the first host machine 10, thereby realizing driver installation. Device driver 106 is the same driver as device driver 202 in the target host machine.

[0118] Furthermore, the device driver 106 reads the Base Address Registers (BARs). BARs define the size and type of the memory-mapped I / O (MMIO) address space or I / O port space required by the target I / O device. Based on the MMIO address space, the device driver can request the allocation of a physical memory region that meets the BAR size requirements from the virtual machine's kernel memory manager. This is the memory address space within the virtual machine's physical address space, i.e., the Guest Physical Address (GPA) space. After the kernel memory manager allocates the memory region for the target I / O device, it can write the starting guest physical address (i.e., the starting GPA) of this memory region back to the corresponding BAR of the target I / O device. This process establishes the mapping relationship between the virtual machine's memory and the I / O space of the target I / O device. Subsequently, the device driver can communicate with the target I / O device by reading and writing to this memory region.

[0119] To facilitate efficient access to the memory region mapped by the BAR by the device driver, the kernel can map the aforementioned GPA region to the device driver's address space (usually the kernel virtual address space). The device driver obtains a kernel virtual address (KVA) that can be directly read and written. Through this address, the I / O memory of the target I / O device can be accessed without having to perform GPA to KVA conversion every time. This simplifies the device driver's programming model and improves the efficiency of I / O operations.

[0120] After the initialization and resource configuration operations of the target I / O device are completed, the device driver 106 can set the state of the target I / O device to ready, at which point the target I / O device is allocated to the virtual machine. Within the virtual machine's operating system, the target I / O device is in an available state. Upper-layer applications within the virtual machine (such as network services and file systems) can access and use this cross-host allocated target I / O device just like they would a local physical I / O device.

[0121] In this embodiment, by adding a device proxy component and a device driver proxy component to the host machine (i.e., the first host machine) where the virtual machine requiring cross-host I / O device allocation resides, and adding a device service component to the host machine providing the I / O device (i.e., the target host machine), the device proxy component on the first host machine and the device service component on the target host machine cooperate to allocate the I / O device on the target host machine to the virtual machine on the first host machine, thus realizing cross-host allocation of I / O devices. Compared to the traditional virtualization approach where virtual machines can typically only use the local I / O devices of their host machine, this embodiment breaks the boundaries of physical host machines, allowing I / O resources to be pooled and shared throughout the entire cloud service system. This breaks the limitation of resource silos and enables virtual machines to use I / O devices on other host machines across hosts, exceeding the upper limit on the number of I / O devices that a virtual machine can use due to local I / O devices.

[0122] On the other hand, high-performance I / O devices do not need to be deployed on every host machine. They can be centrally deployed on a few host machines. Virtual machines on other host machines can use the cross-host machine I / O device allocation scheme provided in this application embodiment to use high-performance I / O devices, thus avoiding resource idleness and waste.

[0123] Virtual machine migration and deployment are no longer limited by whether their host machine has specific I / O capabilities. Virtual machines can be deployed on host machines with suitable computing resources (CPU, memory, etc.), and I / O device needs can be met by obtaining them from other host machines, thus improving the flexibility of virtual machine migration and deployment.

[0124] Furthermore, in this embodiment, the device service component returns a physical device identifier, and the device agent component obtains a virtual device identifier with the same encoding method based on the physical device identifier, and finally sends the virtual device identifier to the virtual machine. The operating system and device driver within the virtual machine see a "physical" device with a device identifier that has a standard bus interface specification (such as PCIe or PCI). The virtual machine will automatically enumerate, load the driver, and initialize it as if it were a local I / O device, without requiring modification to the guest operating system and device driver, thus improving the compatibility of this solution with existing virtual machine systems.

[0125] After a target I / O device is assigned to a virtual machine, upper-layer applications within the virtual machine (such as network services, file systems, etc.) can access and use this cross-host assigned target I / O device as if it were a local physical I / O device. The following provides an illustrative example of how a virtual machine accesses a target I / O device.

[0126] like Figure 4As shown in step 1, when an application on the virtual machine accesses an I / O device, it can initiate an access request for the I / O device to be accessed to the device driver 106 in the virtual machine. This access request may include the device identifier of the I / O device to be accessed. For example... Figure 4 As shown in step 2, the device driver proxy component 104 can monitor the access request (defined as the first access request) received by the device driver 106. If the device identifier carried by the access request is the aforementioned virtual device identifier, it is determined that the access operation initiated by the application in the virtual machine to the device driver 106 is an access operation for the target I / O device. Since the device driver 106 in the virtual machine runs in kernel mode, it is easy to implement to use a device driver proxy component in kernel mode to monitor the access requests received by the device driver.

[0127] Furthermore, when the device driver proxy component 104 detects that an application in the virtual machine initiates an access operation to the target I / O device based on the aforementioned virtual device identifier, that is, when it detects that the first access request received by the device driver 106 carries a virtual device identifier, such as... Figure 4 As shown in step 3, the target access request corresponding to the access operation can be sent to the device proxy component 103. Accordingly, as... Figure 4 As shown in step 4, the device proxy component 103 can send the target access request to the device service component 201 in the target host machine 20. For example... Figure 4 As shown in step 5, the device service component 201 can determine the physical device identifier of the target I / O device in response to the target access request. The following is an exemplary description of how the device service component 201 determines the physical device identifier of the target I / O device.

[0128] Implementation Method 1: In the embodiment described above where the device proxy component 103 in the first host machine 10 assigns a virtual device identifier to the target IO device, the device proxy component 103 can maintain the correspondence between the target host machine's identifier, the physical device identifier, and the virtual device identifier after assigning the virtual device identifier to the target IO device. In this embodiment, the target access request sent by the device driver proxy component 104 to the device proxy component 103 includes the virtual device identifier of the target IO device. The device proxy component 103 can obtain the virtual device identifier from the target access request; and determine the physical device identifier corresponding to the virtual device identifier and the target host machine's identifier based on the maintained correspondence between the target host machine's identifier, the physical device identifier, and the virtual device identifier. The target host machine's identifier indicates that the host machine where the IO device to be accessed is located is the target host machine; the physical device identifier indicates that the IO device to be accessed is located on the target host machine.

[0129] Furthermore, the device proxy component 103 can replace the virtual device identifier in the target access request corresponding to the access operation with a physical device identifier to obtain a replaced target access request. The device proxy component 103 can send the replaced target access request to the device service component 201 in the target host. The device service component 201 can obtain the physical device identifier of the target I / O device from the replaced target access request.

[0130] In this implementation, the device proxy component 103 acts as a "gateway" or "routing center" on the first host, centrally managing the mapping and routing decisions for all cross-host devices. This makes the mapping logic and request translation logic highly centralized, facilitating maintenance and debugging. The device service component 201 on the target host receives access requests containing physical device identifiers, without needing to distinguish whether the access request originates locally or remotely. This completely decouples the processing logic of the target host from the virtualization logic of the first host, allowing the target host to process access requests as if they were local requests, simplifying the design of the target host.

[0131] Implementation Method 2: In the embodiment where the device driver proxy component 104 in the first host machine 10 allocates a virtual device identifier to the target IO device, the device driver proxy component 104 can maintain the correspondence between the target host machine's identifier, the physical device identifier, and the virtual device identifier after allocating the virtual device identifier to the target IO device. In this embodiment, the device driver proxy component 104 can obtain the device identifier of the IO device to be accessed from the access request intercepted by the device driver 106. This device identifier is the aforementioned virtual device identifier. Further, the device driver proxy component 104 can determine the physical device identifier corresponding to the virtual device identifier and the target host machine's identifier based on the maintained correspondence between the target host machine's identifier, the physical device identifier, and the virtual device identifier. The target host machine's identifier indicates that the host machine where the IO device to be accessed is located is the target host machine; the physical device identifier indicates that the IO device to be accessed is located on the target host machine.

[0132] Furthermore, the device proxy component 103 can replace the virtual device identifier in the target access request with a physical device identifier to obtain the target access request. The device proxy component 103 can send the target access request to the device service component 201 in the target host. The device service component 201 can obtain the physical device identifier of the target I / O device from the target access request.

[0133] In this implementation, the mapping lookup and request translation occur in the kernel-mode device driver proxy component, which can leverage the kernel's efficient data structures and direct memory access to speed up processing and improve the efficiency of subsequent accesses.

[0134] Implementation Method 3: In the embodiment where the device driver proxy component 104 in the first host machine 10 allocates a virtual device identifier to the target I / O device, the device driver proxy component 104 may, after allocating the virtual device identifier to the target I / O device, establish a correspondence between the identifier of the first host machine, the physical device identifier, and the virtual device identifier, and send this correspondence to the device proxy component 103. The device proxy component 103 may forward this correspondence to the device service component 201 in the target host machine.

[0135] In this embodiment, the device driver proxy component 104 can intercept the first access request as the target access request corresponding to the access operation, and send the target access request to the device proxy component 103, which then forwards the target access request to the device service component 201. Correspondingly, the device driver proxy component 104 can determine the physical device identifier corresponding to the first host identifier and the virtual device identifier based on the maintained correspondence between the first host identifier, the physical device identifier, and the virtual device identifier, thus obtaining the physical device identifier of the target I / O device. The first host identifier indicates which host the target access request originates from.

[0136] In this embodiment, the device proxy component and the device driver proxy component in the first host machine complete the request interception and forwarding operations without performing mapping lookup and request conversion, which can reduce the processing latency on the request forwarding path and has high forwarding efficiency.

[0137] After determining the physical device identifier of the target I / O device, the device service component 201, such as Figure 4 As shown in steps 5 and 6, the device driver 202 on the target host machine can be invoked to access the target I / O device based on the physical device identifier, and the target access result can be obtained.

[0138] Specifically, the device service component 201 can locate and position the target I / O device in the bus topology of the target host based on the physical device identifier. Specifically, the target I / O device corresponding to the physical device identifier can be determined in the bus topology of the target host through the standard PCIe configuration space access mechanism.

[0139] Furthermore, the device service component 201 transmits the specific operation instructions and carried data or parameters (such as memory address, data length, etc.) contained in the target access request to the device driver responsible for managing the target I / O device. The device driver executes the access operation on the target I / O device according to the operation instructions and the data or parameters carried in the target access request. For example, if the target access request is a read request, then the operation instructions contained in the target access request are read instructions, and the carried data may be the starting address of the memory to be read and the data length. Accordingly, the device driver can read the corresponding data according to the starting address and the data length. As another example, if the target access request is a read request, then the operation instructions contained in the target access request are read instructions, and the carried data may be the starting address of the memory to be read and the target data to be written. Accordingly, the device driver can write the target data into the target I / O device starting from the starting address.

[0140] After obtaining the target access result, the device service component 201 can return the target access result to the virtual machine 101 on the first host machine. Specifically, as shown below... Figure 4 As shown in step 7, the device service component 201 can return the target access result to the device agent component 103. For example... Figure 4 As shown in steps 7 and 9, the device proxy component 103 can return the target access result to the device driver 106 in the virtual machine 101 through the device driver proxy component 104, and as follows: Figure 4 As shown in step 10, the device driver 106 returns the access result to the application in the virtual machine.

[0141] In this embodiment, the device proxy component and device driver proxy component on the first host machine and the device service component on the target host machine cooperate with each other to enable the virtual machine on the first host machine to access the IO device on the target host machine across hosts. This allows for more flexible allocation and use of hardware resources, reduces idle or wasted hardware resources, and helps improve resource utilization.

[0142] The target I / O device can also generate interrupts, which requires the virtual machine in the first host machine to be able to handle interrupts from the target I / O device. To achieve interrupt handling for the target I / O device, in some embodiments of this application, such as... Figure 5As shown in step 1, the interrupt management unit 204 in the target host 20 can send an interrupt request to the device service component 201 in response to an interrupt event of the target I / O device. Specifically, after sending the physical device identifier of the target I / O device to the device proxy component 103 in the first host, the device service component 201 can configure the physical device identifier of the target I / O device in the interrupt management unit. This physical device identifier is used by the interrupt management unit to determine whether to send the interrupt request to the device service component 201 or to the device driver 202. Based on the pre-configured physical device identifier in the interrupt management unit, the interrupt management unit 204 can obtain the physical device identifier carried in the interrupt request and determine whether the pre-configured physical device identifier contains the physical device identifier carried in the interrupt request. If the determination result is yes, the interrupt request is sent to the device service component 201. If the determination result is no, the interrupt request is sent to the device driver 202 in the target host 20. The device driver 202 in the target host 20 then directly performs interrupt processing based on the interrupt request.

[0143] like Figure 5 As shown in step 2, after receiving the interrupt request, the device service component 201 can forward the interrupt request to the device agent component 103. Specifically, the device service component 201 can determine the identifier of the host machine (i.e., the identifier of the first host machine) corresponding to the physical device identifier carried in the interrupt request, based on the physical device identifier carried in the interrupt request and the maintained correspondence between the identifier of the first host machine, the virtual device identifier, and the physical device identifier. The identifier of the host machine corresponding to the physical device identifier carried in the interrupt request is used to determine which specific host machine the interrupt request should be forwarded to.

[0144] After determining the identifier of the first host machine, the device service component 201 can forward the interrupt request to the device agent component 103. The device agent component 103 maintains a correspondence between physical device identifiers, target host machine identifiers, and target interrupt numbers. The device agent component 103 can obtain the physical device identifier and the target host machine identifier from the interrupt request. The host machine identifier carried in the interrupt request indicates the source of the interrupt request, i.e., which host machine it originates from. Further, the device agent component 103 can determine the target interrupt number of the target I / O device in the first host machine based on the physical device identifier and the target host machine identifier carried in the interrupt request. Specifically, the device agent component 103 can determine the virtual device identifier corresponding to the physical device identifier and the target host machine identifier carried in the interrupt request based on the correspondence between the physical device identifier, the target host machine identifier, and the virtual device identifier. Further, the device agent component 103 can query the interrupt mapping table maintained by the IOMMU (i.e., the mapping relationship between target interrupt numbers and virtual device identifiers) to obtain the target interrupt number corresponding to the virtual device identifier.

[0145] Furthermore, such as Figure 5 As shown in step 4, the device agent component 103 can send the target interrupt number to the interrupt management unit 105 in the first host machine 10. For example... Figure 5 As shown in step 5, the interrupt management unit 105 in the first host machine 10 can perform interrupt processing based on the target interrupt number.

[0146] When configuring the interrupt remapping table of the IOMMU on the first host, the VMM can also configure the mapping relationship between virtual device identifiers and physical processor cores. Based on this mapping relationship, the interrupt management unit 105 can determine the processor core corresponding to the virtual device identifier and provide the target interrupt number to the processor core. The processor core can instrument the interrupt vector table according to the target interrupt number to determine the interrupt service routine (ISR) corresponding to the target interrupt number; and call the interrupt service routine to perform interrupt handling, thereby realizing interrupt handling for the target I / O device.

[0147] This embodiment enables interrupt handling of I / O devices across hosts by having the device agent component in the first host interact with the device service component in the target host, thus providing support for allocating I / O devices to virtual machines across hosts and managing I / O devices across hosts.

[0148] In addition to the cloud service system provided in the foregoing embodiments, this application also provides an IO device management method, which enables cross-host allocation, access, and interrupt handling of IO devices. The IO device management method provided in this application is described below by way of example. Figure 6a , Figure 6b and Figure 7 The process of allocating I / O devices is illustrated from the perspectives of the first host that needs to allocate I / O devices across host machines and the target host that provides I / O devices to virtual machines in the first host machine.

[0149] Figure 6a This is a flowchart illustrating the I / O device management method provided in an embodiment of this application. The method is applicable to a first host machine. The first host machine hosts virtual machines. This method is primarily used for I / O device allocation, that is, allocating I / O devices across hosts for virtual machines within the first host machine. Figure 6a As shown, the method mainly includes:

[0150] 61. In response to a cross-host allocation event for an I / O device, request the target host to allocate an I / O device for the virtual machine.

[0151] 62. Receive the first physical device identifier and the first configuration information of the first I / O device on the target host machine, returned by the target host machine.

[0152] 63. Based on the first physical device identifier, obtain the first virtual device identifier of the first I / O device in the first host machine.

[0153] 64. Send the first virtual device identifier and the first configuration information to the virtual machine to assign the first I / O device to the virtual machine.

[0154] In this embodiment, to allocate I / O devices to virtual machines across host machines, the first host machine can monitor cross-host allocation events for I / O devices. Specifically, the VMM in the first host machine can be used to monitor cross-host allocation events for I / O devices. For details on the specific implementation of cross-host allocation events, please refer to the relevant content in the foregoing system embodiments. Figure 6a As shown in step 61, in the event of a cross-host allocation event occurring to a virtual machine on the first host, the target host may be requested to allocate an I / O device on the target host to the virtual machine in response to the cross-host allocation event. In some embodiments, in the event of a cross-host allocation event occurring to a virtual machine on the first host, an I / O device request (defined as a first I / O device request) may be sent to the target host in response to the cross-host allocation event. The first I / O device request may include: the type of I / O device, the performance requirements of the I / O device, and the identifier of the target host. The first I / O device request is used to request the target host to allocate an I / O device that meets the type and performance requirements of the I / O device.

[0155] Specifically, a device agent component is added to the first host machine. The first host machine also includes a virtual machine manager. Based on the virtual machine manager and the device agent component, step 61 above can be implemented as follows: Figure 6b Steps 601 and 602. Among them, Figure 6b It is mainly used for I / O device allocation, that is, allocating I / O devices for virtual machines in the first host machine across hosts. For example... Figure 6b As shown, the method mainly includes:

[0156] 601. Utilize the virtual machine manager to respond to cross-host allocation events for I / O devices and send the first I / O device request to the device agent component.

[0157] 602. Use the device proxy component to send the first IO device request to the target host machine, so that the target host machine can respond to the first IO device request, determine the first IO device from at least one IO device on the target host machine, and return the first physical device identifier and the first configuration information of the first IO device.

[0158] 603. Using the device proxy component, obtain the first virtual device identifier of the first I / O device in the first host machine based on the first physical device identifier.

[0159] 604. The device agent component is used to send the first virtual device identifier and the first configuration information to the virtual machine, so that the virtual machine can initialize and configure the resources of the first IO device according to the first virtual device identifier and the first configuration information, so as to allocate the first IO device to the virtual machine.

[0160] Accordingly, a device service component can be added to the target host. The main process of the target host allocating I / O devices across hosts for virtual machines in the first host is as follows: Figure 7 As shown, the main steps include:

[0161] 701. Use the device service component to obtain the first IO device request of the first host machine.

[0162] 702. In response to a first IO device request, the device service component determines the first IO device from at least one IO device on the target host.

[0163] 703. The device service component is used to return the first physical device identifier and the first configuration information of the first IO device to the first host machine; wherein, the first physical device identifier is used for the first host machine to obtain the first virtual device identifier of the first IO device in the first host machine; and the first IO device is assigned to a virtual machine in the first host machine based on the first virtual device identifier and the first configuration information; the first virtual device identifier and the first physical device identifier have the same encoding method.

[0164] In step 602, the device proxy component can be used to send the IO device request (defined as the first IO device request) to the device service component in the target host. For example... Figure 7 As shown in step 701, on the target host side, a device service component can be used to receive a first IO device request, and in step 702, the device service component responds to the IO device request by determining the target IO device (i.e., the first IO device) from at least one IO device on the target host. The target IO device can be a physical IO device or a virtual device obtained by virtualizing a physical IO device using SR-IOV technology, i.e., a virtual function (VF). For the specific implementation of determining the first IO device from at least one IO device on the target host using the device service component, please refer to the relevant content of the aforementioned system embodiment, which will not be repeated here.

[0165] After identifying the first I / O device, the device service component can also be used to obtain the physical device identifier (defined as the first physical device identifier) ​​and the configuration information (defined as the first configuration information) of the first I / O device. For details on how the device service component can also obtain the device identifier and configuration information of the first I / O device, please refer to the aforementioned system embodiment, specifically the section on how the device service component can also obtain the device identifier and configuration information of the target I / O device.

[0166] Furthermore, such as Figure 7 As shown in step 703, the device service component can be used to return the first physical device identifier and configuration information of the first IO device to the first host. After returning the first physical device identifier of the first IO device to the first host, the first IO device can also be marked as occupied to prevent duplicate allocation of the first IO device and reduce usage conflicts of the first IO device.

[0167] Accordingly, for the first host machine, in step 62, the first physical device identifier and configuration information of the first I / O device returned by the target host machine can be received. Specifically, the first physical device identifier and configuration information of the first I / O device can be received using a device proxy component. Further, in step 63, the virtual device identifier (defined as the first virtual device identifier) ​​of the first I / O device in the first host machine can be obtained based on the first physical device identifier of the first I / O device. The first virtual device identifier has the same encoding method as the first physical device identifier, allowing the virtual machine to see a "real" I / O device with a standard device identifier. The operating system and device driver do not need to be modified and will discover, enumerate, configure, and initialize this virtual device through the standard configuration space access mechanism, just like a physical I / O device. On the other hand, using the first virtual device identifier to represent the first I / O device in the first host machine, instead of using the real device identifier (i.e., the first physical device identifier) ​​of the first I / O device, can prevent device identifier conflicts of I / O devices. Specifically, in step 603, the virtual device identifier (defined as the first virtual device identifier) ​​of the first I / O device in the first host machine can be obtained using a device proxy component based on the first physical device identifier of the first I / O device.

[0168] In this application embodiment, the specific implementation method of obtaining the first virtual device identifier of the first I / O device in the first host machine using the device proxy component is not limited. In some embodiments, the device proxy component can be used to generate a first virtual device identifier for the first I / O device with the same encoding method as the first physical device identifier, based on the encoding method of the first physical device identifier. The encoding method of the first virtual device identifier is the same as that of the device identifier. For specific implementation methods, please refer to the relevant content on the generation of the virtual device identifier of the target I / O device by the device proxy component in the foregoing system embodiment.

[0169] In other embodiments, the first host machine may be equipped with a device driver proxy component. This device driver proxy component is a software module, and may be a kernel module, running within the kernel of the first host machine. Accordingly, the device proxy component can register a virtual I / O device in the device driver proxy component based on the first physical device identifier. Correspondingly, in response to the registration of the virtual I / O device, the device driver proxy component can assign a first virtual device identifier to the virtual I / O device, thereby registering the virtual I / O device in the device driver proxy component 104. The first virtual device identifier assigned to the virtual I / O device is the device identifier of the first I / O device on the first host machine. For a detailed explanation of how the device driver proxy component assigns a first virtual device identifier to the virtual I / O device, please refer to the relevant content regarding the allocation of virtual device identifiers by the device driver proxy component in the aforementioned system embodiments.

[0170] Furthermore, the device driver proxy component can be used to send the first virtual device identifier to the device proxy component. The device proxy component can receive the first virtual device identifier returned by the device driver proxy component, thereby obtaining the first virtual device identifier.

[0171] In this embodiment, since the device driver proxy component running in the kernel can directly access and manage hardware resources, such as the PCI configuration space and memory-mapped I / O regions, it can more efficiently query the device identifiers already allocated in the current system and generate a conflict-free first virtual device identifier based on this information. Therefore, using the device driver proxy component running in the kernel to generate the first virtual device identifier allows direct querying of the allocated device identifiers maintained by the kernel, without the need for context switching between kernel mode and user mode, thus improving the generation efficiency of the first virtual device identifier.

[0172] In some embodiments, interrupt handling for the first I / O device is also required. Accordingly, a device proxy component can request an interrupt number for the first I / O device from the interrupt management unit in the first host machine based on the first virtual device identifier. In response to the interrupt number request, the interrupt management unit can allocate a target interrupt number to the first virtual device identifier and return the target interrupt number to the device proxy component. This target interrupt number can ultimately be assigned to the first I / O device. Afterwards, the device proxy component can send the target interrupt number to the VMM. The VMM can configure the mapping relationship between the target interrupt number and the virtual interrupt number in the virtual machine in the IOMMU, thereby assigning the target interrupt number to the first I / O device. In this embodiment, assigning an interrupt number to the first I / O device in the first host machine supports interrupt handling for the first I / O device by the virtual machine in the first host machine.

[0173] After obtaining the first virtual device identifier, in step 64, the first virtual device identifier and the first configuration information of the first I / O device can be sent to the virtual machine. Specifically, as in step 604, the device proxy component can be used to send the first virtual device identifier and the first configuration information of the first I / O device to the virtual machine. Specifically, the device proxy component sends the first virtual device identifier and the first configuration information of the first I / O device to the VMM, and the VMM sends the first virtual device identifier and the first configuration information of the first I / O device to the virtual machine. The virtual machine can initialize and configure the resources of the first I / O device according to the first virtual device identifier and the first configuration information of the first I / O device, thereby realizing the allocation of the first I / O device to the virtual machine, that is, realizing the cross-host allocation of the I / O device. For the specific implementation method of the virtual machine initializing and configuring the resources of the first I / O device, please refer to the relevant content of the virtual machine initializing and configuring the resources of the target I / O device in the aforementioned system embodiment.

[0174] In the various method embodiments of this application, the first I / O device can be regarded as the target I / O device in the aforementioned system embodiments, and the physical device identifier (i.e., the first physical device identifier) ​​of the first I / O device in the target host machine can be regarded as the physical device identifier of the aforementioned target I / O device. The virtual device identifier (i.e., the first virtual device identifier) ​​of the first I / O device in the first host machine can be regarded as the virtual device identifier of the aforementioned target I / O device. For the technical effects of the method embodiments, please refer to the relevant content of the aforementioned system embodiments, which will not be repeated here.

[0175] After the first I / O device is assigned to the virtual machine, upper-layer applications within the virtual machine (such as network services, file systems, etc.) can access and use this cross-host assigned first I / O device as if it were a local physical I / O device. The following is an illustrative example of how the virtual machine accesses the target I / O device.

[0176] Figure 8 This is a flowchart illustrating another method for managing I / O devices provided in an embodiment of this application. The method is applicable to a first host machine. Virtual machines in the first host machine are allocated a first I / O device on the target host machine across host machines. The first host machine includes: a device proxy component and a device driver proxy component running in the kernel of the first host machine. For example... Figure 8 As shown, the method mainly includes the following steps:

[0177] 801. When an application in a virtual machine initiates an access operation to the first I / O device based on the first virtual device identifier, the device driver proxy component is used to send the target access request corresponding to the access operation to the device proxy component; the first virtual device identifier is the device identifier of the first I / O device in the first host machine.

[0178] 802. Use the device proxy component to send the access request to the target host machine; wherein, the first virtual device identifier is used by the target host machine to determine the first physical device identifier of the first IO device; and access the first IO device based on the first physical device identifier to obtain the first access result.

[0179] 803. Use the device proxy component to obtain the first access result returned by the device service component, and send the first access result to the application in the virtual machine through the device driver proxy component.

[0180] Figure 9 This is a flowchart illustrating a method for managing another I / O device provided in an embodiment of this application. This method is applicable to a target host machine. The first I / O device on the target host machine is assigned to a virtual machine within the first host machine. The target host machine includes: a device service component. For example... Figure 9 As shown, the method mainly includes the following steps:

[0181] 901. Use the device service component to obtain the target access request for the first IO device sent by the first host.

[0182] 902. In response to a target access request, the device service component determines the first physical device identifier of the first I / O device; the first physical device identifier refers to the device identifier of the first I / O device on the target host.

[0183] 903. Using the device service component, the first I / O device is accessed based on the first physical device identifier and the access requirements reflected in the access request, so as to obtain the first access result.

[0184] 904. Use the device service component to return the first access result to the first host machine.

[0185] When an application on a virtual machine accesses an I / O device, it can initiate an access request to the device driver within the virtual machine for the I / O device to be accessed. This access request may include the device identifier of the I / O device to be accessed. A device driver proxy component can be used to monitor the access request received by the device driver (defined as the first access request). If the device identifier carried in the first access request is the aforementioned virtual device identifier, then it is determined that the access operation initiated by the application on the virtual machine is an access operation for the target I / O device. Since the device driver in the virtual machine runs in kernel mode, using a kernel-mode device driver proxy component to monitor the access requests received by the device driver is easy to implement.

[0186] Furthermore, when the device driver proxy component detects that an application in the virtual machine initiates an access operation to the target I / O device based on the aforementioned virtual device identifier, that is, when the device driver proxy component detects that the first access request received by the device driver carries the virtual device identifier, such as Figure 8 As shown in step 801, the target access request corresponding to the access operation can be sent to the device proxy component using the device driver proxy component. Further, in step 802, the device proxy component can send the target access request to the target host machine, specifically to the device service component within the target host machine. Correspondingly, in step 901, the device service component can receive the target access request, and in step 902, in response to the target access request, the device service component determines the first physical device identifier of the first IO device. For a detailed implementation of determining the first physical device identifier of the first IO device using the device service component in response to the target access request, please refer to the relevant content of implementation methods 1-3 in the aforementioned system embodiments, which will not be repeated here.

[0187] Furthermore, after determining the physical device identifier of the first I / O device using the device service component, in step 903, the device service component can access the first I / O device based on the first physical device identifier and the access requirements reflected in the access request to obtain a first access result. For the specific implementation of accessing the first I / O device using the device service component based on the first physical device identifier and the access requirements reflected in the access request, please refer to the relevant content of the foregoing system embodiments, which will not be repeated here.

[0188] After the device service component obtains the first access result, in step 904, the device service component can be used to return the first access result to the virtual machine on the first host machine. Specifically, the device service component can be used to return the first access result to the device agent component in the first host machine. Correspondingly, in step 803, the device agent component can be used to return the first access result to the application in the virtual machine through the device driver agent component.

[0189] In this embodiment, the device proxy component and device driver proxy component on the first host machine and the device service component on the target host machine cooperate with each other to enable the virtual machine on the first host machine to access the IO device on the target host machine across hosts. This allows for more flexible allocation and use of hardware resources, reduces idle or wasted hardware resources, and helps improve resource utilization.

[0190] The first I / O device allocated by the target host to the virtual machine in the first host will also generate an interrupt. This requires the first host to be able to handle the interrupt of the first I / O device. The corresponding interrupt handling process is illustrated below.

[0191] Figure 10 This is a flowchart illustrating another I / O device management method provided in this application embodiment. This I / O device management method is mainly applied to interrupt handling of I / O devices. This method is primarily applied to a first host machine where virtual machines are deployed. The virtual machine is allocated a first I / O device on the target host machine. The first host machine includes a device agent component. The method mainly includes the following steps:

[0192] 1001. Use the device proxy component to obtain the first interrupt request of the first IO device forwarded by the target host.

[0193] 1002. Using the device proxy component, obtain the first physical device identifier of the first I / O device and the identifier of the target host machine from the first interrupt request; the first physical device identifier refers to the device identifier of the first I / O device in the target host machine.

[0194] 1003. Using the device proxy component, determine the first virtual device identifier of the first IO device based on the first physical device identifier of the first IO device and the identifier of the target host machine; the first virtual device identifier is the device identifier of the first IO device in the first host machine.

[0195] 1004. Using the device agent component, query the mapping relationship between the target interrupt number and the first virtual device identifier maintained by the IOMMU in the first host machine based on the first virtual device identifier, so as to obtain the target interrupt number of the first IO device in the first host machine.

[0196] 1005. Use the device proxy component to send the target interrupt number to the interrupt management unit in the first host machine, so that the interrupt management unit in the first host machine can perform interrupt processing based on the target interrupt number.

[0197] Figure 11 This is a flowchart illustrating another I / O device management method provided in this application embodiment. This I / O device management method is mainly applied to interrupt handling of I / O devices. This method is primarily applied to the target host machine. The first I / O device on the target host machine is assigned to a virtual machine on the first host machine. The target host machine includes: a device service component and an interrupt management unit running in the kernel of the target host machine. The method mainly includes the following steps:

[0198] 1101. In response to an interrupt event of the first I / O device, the interrupt management unit sends a first interrupt request corresponding to the interrupt event to the device service component. The first interrupt request includes: a first physical device identifier and an identifier of the target host. The first physical device identifier refers to the device identifier of the first I / O device on the target host.

[0199] 1102. The device service component is used to send the first interrupt request to the first host machine. The first physical device identifier and the target host machine identifier are used by the first host machine to determine the target interrupt number of the first I / O device in the first host machine, and to perform interrupt processing based on the target interrupt number.

[0200] In this embodiment, in step 1101, the interrupt management unit in the target host can respond to the interrupt event of the first IO device by sending an interrupt request (defined as the first interrupt request) to the device service component.

[0201] In step 1102, the device service component can be used to forward the interrupt request to the first host machine, specifically, to the device agent component within the first host machine. Specifically, the device service component can determine the identifier of the host machine corresponding to the physical device identifier carried in the interrupt request (i.e., the identifier of the first host machine) based on the physical device identifier carried in the interrupt request and the maintained correspondence between the identifier of the first host machine, virtual device identifiers, and physical device identifiers. The identifier of the host machine corresponding to the physical device identifier carried in the interrupt request is used to determine which specific host machine the interrupt request should be forwarded to.

[0202] After determining the identifier of the first host machine, the device service component can forward the interrupt request to the device proxy component. Accordingly, in step 1001, the device proxy component can obtain the first interrupt request for the first I / O device forwarded by the target host machine. The device proxy component maintains a correspondence between physical device identifiers, the identifier of the target host machine, and the target interrupt number. Based on this, in step 1002, the device proxy component can obtain the first physical device identifier and the identifier of the target host machine from the first interrupt request. The host machine identifier carried in the first interrupt request is used to characterize the source of the interrupt request, i.e., which host machine it originates from. Further, in step 1003, the device proxy component can determine the target interrupt number of the first I / O device in the first host machine based on the first physical device identifier and the identifier of the target host machine carried in the first interrupt request. Specifically, the device proxy component can determine the virtual device identifier corresponding to the physical device identifier and the identifier of the target host machine carried in the interrupt request based on the correspondence between the physical device identifier, the identifier of the target host machine, and the virtual device identifier. Furthermore, in step 1004, the device agent component can be used to query the interrupt mapping table maintained by the IOMMU (i.e., the mapping relationship between the target interrupt number and the first virtual device identifier) ​​to obtain the target interrupt number corresponding to the first virtual device identifier.

[0203] Furthermore, in step 1005, the device proxy component sends the target interrupt number to the interrupt management unit in the first host machine. The interrupt management unit in the first host machine can perform interrupt processing based on the target interrupt number; for details of its implementation, please refer to the relevant content of the aforementioned system embodiment.

[0204] This embodiment enables interrupt handling of I / O devices across hosts by having the device agent component in the first host interact with the device service component in the target host, thus providing support for allocating I / O devices to virtual machines across hosts and managing I / O devices across hosts.

[0205] The same host machine can be implemented independently as a host machine that requires cross-host I / O device allocation, or it can be implemented independently as a host machine that provides I / O devices for virtual machines on other hosts. The same host machine can also be implemented both as a host machine that requires cross-host I / O device allocation and as a host machine that provides I / O devices for virtual machines on other hosts. Correspondingly, the aforementioned first host machine can also provide I / O devices for virtual machines on other hosts. The first host machine can be any host machine. The following is an exemplary description of the I / O device management method when the first host machine provides I / O devices for virtual machines on other hosts.

[0206] Accordingly, the first host may further include a device service component. In an embodiment where the first host provides I / O devices for virtual machines on other hosts, the device service component therein can be used to obtain I / O device requests (defined as second I / O requests) from the second host. In this embodiment, the second host is a host that needs to use I / O devices on the first host across hosts. Further, in response to the second I / O device request, the device service component can determine the second I / O device from at least one I / O device on the first host. For a specific implementation, refer to the aforementioned system embodiment, where the device service component in the target host determines the relevant content of the target I / O device from at least one I / O device on the target host. Further, the first host can use the device service component to return the second physical device identifier and the second configuration information of the second I / O device to the second host. Based on the second physical device identifier, the second host obtains the second virtual device identifier of the second I / O device in the second host; and based on the second virtual device identifier, allocates the second I / O device to a virtual machine in the second host; the second virtual device identifier has the same encoding method as the second physical device identifier. For details on how the second host machine obtains the second virtual device identifier, please refer to the relevant content on the first host machine obtaining the virtual device identifier of the target IO device in the aforementioned system embodiment.

[0207] In some embodiments, the first host machine may also utilize a device service component in the first host machine to obtain an access request (defined as a second access request) sent by the second host machine for the second I / O device, and utilize the device service component to respond to the second access request and determine the second physical device identifier of the second I / O device. Then, the device service component may utilize the second physical device identifier and the access requirements of the second access request to access the second I / O device to obtain an access result (defined as a second access result); the device service component may then utilize the second access result to return it to the second host machine.

[0208] In some embodiments, the first host may also utilize its interrupt management unit in response to an interrupt event of the second I / O device to send a second interrupt request to the device service component in the first host. The second interrupt request includes: a second physical device identifier of the second I / O device and an identifier of the first host. Further, the device service component in the first host may be used to send the second interrupt request to the second host. The second host can determine the interrupt number of the second I / O device in the second host based on the second physical device identifier and the identifier of the first host carried in the second interrupt request, and perform interrupt processing based on the interrupt number of the second I / O device in the second host, thereby realizing cross-host I / O device interrupt processing. For specific implementations of interrupt processing by the second host, please refer to the relevant content on interrupt processing by the first host in the foregoing system embodiments.

[0209] 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 801 and 802 can be device A; or the execution subject of step 801 can be device A, and the execution subject of step 802 can be device B; and so on.

[0210] Furthermore, some processes described in the above embodiments and accompanying drawings include multiple operations that appear in a specific order. However, it should be clearly understood that these operations may not be executed in the order they appear herein, or they may be executed in parallel. The operation numbers, such as 801, 802, etc., are merely used to distinguish different operations and do not represent any execution order. In addition, these processes may include more or fewer operations, and these operations may be executed sequentially or in parallel.

[0211] Accordingly, embodiments of this application also provide a computer-readable storage medium storing computer instructions, which, when executed by one or more processors, cause one or more processors to perform the steps in the IO device management methods provided in the foregoing embodiments.

[0212] Computer-readable storage media include volatile or non-volatile or a combination thereof, and may be removable or non-removable. Examples of computer-readable 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 (EPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), flash memory or other memory technologies, compact disc read-only memory (CD-ROM), digital video disc (DVD) or other optical storage, magnetic tape, disk storage or other magnetic storage devices, or any other non-transfer medium.

[0213] This application also provides a computer program product, including a computer program that, when executed by one or more processors, causes the one or more processors to perform the steps in the IO device management methods provided in the foregoing embodiments.

[0214] In the embodiments of this application, the specific implementation form of the computer program product is not limited. In some embodiments, the computer program product may be implemented as an application (APP), a mini-program, a computer-side client, a program module, a plug-in, an installation package, a software development kit (SDK), an image file of an optical disc, a plug-in, or software in the form of Software as a Service (SaaS), etc., but is not limited to these.

[0215] The computer program product should understand that each or a combination of the above-described method flow can be implemented by a computer program or instructions. Furthermore, these computer programs or instructions can be applied to the processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing device, enabling the processor of the general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing device to function as an apparatus for implementing the corresponding functions in the above-described method embodiments.

[0216] Figure 12 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 12 As shown, the electronic device includes a memory 12a and a processor 12b. The memory 12a is used to store computer programs and can be configured to store various other data to support operation on a computing platform. Examples of this data include instructions for any application or method used to operate on the electronic device, data structures, contact data, phone book data, messages, pictures, videos, etc.

[0217] Processor 12b is coupled to memory 12a and is used to execute computer programs to perform the steps in the I / O device management methods provided in the foregoing embodiments. Specific implementation details of each step can be found in the relevant descriptions of the foregoing embodiments, and will not be repeated here.

[0218] In some alternative implementations, such as Figure 12 As shown, the electronic device may also include optional components such as a communication component 12c, a power supply component 12d, a display component 12e, and an audio component 12f. Figure 12 The diagram only shows some components and does not mean that the electronic device must contain them. Figure 12 The inclusion of all components does not imply that an electronic device can only include... Figure 12 The components shown.

[0219] in addition, Figure 12 The components within the dashed box are optional, not mandatory, and their specific requirements depend on the form factor of the electronic device. The electronic device in this embodiment can be a desktop computer, laptop computer, mobile phone, or IoT device; it can also be a traditional server, cloud server, or server cluster, or other server equipment.

[0220] In this embodiment, the memory is used to store computer programs and can be configured to store various other data to support operation on its host device. The processor can execute the computer programs stored in the memory to implement corresponding control logic. 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), electrically erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0221] In the embodiments of this application, the processor can be any hardware processing device capable of executing the above-described method logic. Optionally, the processor can be a central processing unit (CPU), a graphics processing unit (GPU), or a microcontroller unit (MCU); it can also be a programmable device such as a field-programmable gate array (FPGA), a programmable array logic (PAL), a general array logic (GAL), or a complex programmable logic device (CPLD); or it can be an advanced RISC machine (ARM) or a system on chip (SoC), etc., but is not limited thereto.

[0222] In this embodiment, the communication component is configured to facilitate wired or wireless communication between its host device and other devices. The device hosting the communication component can access wireless networks based on communication standards, such as 2G or 3G, 4G, 5G, or combinations thereof. In one exemplary embodiment, the communication component receives broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel.

[0223] In embodiments of this application, the display component may include a liquid crystal display (LCD) and a touch panel (TP). If the display component includes a touch panel, the display component can be implemented as a touchscreen to receive input signals from a 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.

[0224] In this embodiment, a power supply component is configured to provide power to various components of the device in which it resides. The power supply component may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to the device in which the power supply component resides.

[0225] In embodiments of this application, the audio component can be configured to output and / or input audio signals. For example, the audio component includes a microphone (MIC), which is configured to receive external audio signals when the device containing the audio component is in an operating mode, such as call mode, recording mode, and 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. For example, in devices with voice interaction capabilities, voice interaction with the user can be achieved through the audio component.

[0226] It should be noted that the terms "first" and "second" in this article 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.

[0227] 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 the aforementioned element.

[0228] The above description is merely an embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. An IO device management method, suitable for a first host machine in which a virtual machine is deployed, characterized in that, The method comprises: in response to a cross-host allocation event of an input / output (IO) device, requesting a target host to allocate an IO device to a virtual machine; receiving a first physical device identifier of a first IO device on the target host and first configuration information of the first IO device returned by the target host; based on the first physical device identifier, obtaining a first virtual device identifier of the first IO device in the first host; the first virtual device identifier and the first physical device identifier have the same encoding mode; sending the first virtual device identifier and the first configuration information to the virtual machine to allocate the first IO device to the virtual machine.

2. The method of claim 1, wherein, The first host comprises a virtual machine manager and a device agent component; and the method of requesting the target host to allocate an IO device on the target host to the virtual machine in response to a cross-host allocation event of an input / output (IO) device comprises: using the virtual machine manager to send a first IO device request corresponding to the cross-host allocation event to the device agent component in response to the cross-host allocation event; using the device agent component to send the first IO device request to the target host to request the target host to allocate an IO device on the target host to the virtual machine.

3. The method of claim 2, wherein, The first host further comprises a device driver agent component deployed in the kernel of the first host; and the method of obtaining a first virtual device identifier of the first IO device in the first host based on the first physical device identifier comprises: using the device agent component to register a virtual IO device in the device driver agent component based on the first physical device identifier; using the device driver agent component to allocate the first virtual device identifier to the virtual IO device in response to the registration of the virtual IO device; using the device driver agent component to send the first virtual device identifier to the device agent component.

4. The method of claim 3, wherein, The method of using the device driver agent component to allocate the first virtual device identifier to the virtual IO device in response to the registration of the virtual IO device comprises: using the device driver agent component to select an unallocated device identifier from device identifiers maintained by the kernel; using the device driver agent component to allocate the unallocated device identifier as the first virtual device identifier to the virtual IO device.

5. The method according to any one of claims 2-4, characterized in that, The first host further comprises an interrupt management unit; and the method further comprises: after the device agent component obtains the first virtual device identifier, using the device agent component to apply for an interrupt number from the interrupt management unit according to the first virtual device identifier, so that the interrupt management unit allocates a target interrupt number to the first virtual device identifier in response to the application for the interrupt number and returns the target interrupt number; The device agent component is configured to send the target interrupt number to the virtual machine manager, so that the virtual machine manager configures a mapping relationship between the target interrupt number and the first virtual device identifier in an input / output memory management unit (IOMMU) to assign the target interrupt number to the first IO device.

6. The method according to any one of claims 2-4, characterized in that, The first host further comprises a device driver agent component running in the kernel; and the method further comprises: In a case where an application in the virtual machine initiates an access operation on the first IO device based on the first virtual device identifier, the device driver agent component is configured to send a target access request corresponding to the access operation to the device agent component; The device agent component is configured to send the target access request to the target host; wherein the first virtual device identifier is used by the target host to determine a first physical device identifier of the first IO device, and access the first IO device based on the first physical device identifier to obtain a first access result; The device agent component is configured to obtain the first access result returned by the target host, and the device driver agent component is configured to send the first access result to the application in the virtual machine.

7. The method of claim 6, wherein, The method further comprises: The device driver agent component is configured to monitor a first access request received by a device driver in the virtual machine; If the first access request comprises the first virtual device identifier, it is determined that an application in the virtual machine initiates an access operation on the first IO device based on the first virtual device identifier.

8. The method of claim 6, wherein, Before the device agent component sends the target access request corresponding to the access operation to the device agent component, the method further comprises: The device driver agent component is configured to obtain a first virtual device identifier carried by a first access request received by a device driver in the virtual machine; The device driver agent component is configured to determine an identifier of a target host corresponding to the first virtual device identifier and the first physical device identifier according to a first correspondence relationship between the first virtual device identifier and the first physical device identifier of the target host; The device driver agent component is configured to generate the target access request according to the first physical device identifier and the identifier of the target host; the target access request comprises the first physical device identifier and the identifier of the target host.

9. The method of claim 6, wherein, The method further comprises: The device driver agent component is configured to send a second correspondence relationship between the identifier of the first host, the first virtual device identifier, and the first physical device identifier to the device agent component, so that the device agent component forwards the second correspondence relationship to the target host; The device driver agent component is configured to send the target access request corresponding to the access operation to the target host; and the method further comprises: The device driver agent component is configured to determine the first access request received by the device driver in the virtual machine as the target access request, and send the target access request to the target host; and The target access request includes the first virtual device identifier and the identification of the first host machine, and is used for the target host machine to determine the first physical device identifier based on the first virtual device identifier, the identification of the first host machine and the second correspondence.

10. The method of claim 5, wherein, The method further includes: acquiring, by the device proxy component, a first interrupt request of the first IO device forwarded by the target host machine; acquiring, by the device proxy component from the first interrupt request, the first physical device identifier of the first IO device and the identification of the target host machine; determining, by the device proxy component, the first virtual device identifier according to the first physical device identifier and the identification of the target host machine; querying, by the device proxy component, the mapping relationship according to the first virtual device identifier to obtain a target interrupt number of the first IO device in the first host machine; sending, by the device proxy component, the target interrupt number to an interrupt management unit in the first host machine, so that the interrupt management unit in the first host machine performs interrupt processing based on the target interrupt number.

11. The method according to any one of claims 2-4, characterized in that, The first host machine further includes a device service component, and the method further includes: acquiring, by the device service component, a second IO device request of a second host machine; determining, by the device service component in response to the second IO device request, a second IO device from at least one IO device on the first host machine; returning, by the device service component, a second physical device identifier of the second IO device and second configuration information of the second IO device to the second host machine; The second physical device identifier is used for the second host machine to determine a second virtual device identifier of the second IO device in the second host machine; the second host machine further allocates the second IO device to a virtual machine in the second host machine based on the second virtual device identifier and the second configuration information; the second virtual device identifier and the second physical device identifier have the same encoding mode.

12. The method of claim 11, wherein, The method further includes: acquiring, by the device service component, a second access request for the second IO device sent by the second host machine; determining, by the device service component in response to the second access request, a second physical device identifier of the second IO device; accessing, by the device service component, the second IO device according to the second physical device identifier and an access demand reflected by the second access request to obtain an access result; returning, by the device service component, the access result to the second host machine.

13. The method of claim 11, wherein, The method further includes: sending, by the interrupt management unit in the first host machine in response to an interrupt event of the second IO device, a second interrupt request corresponding to the interrupt event of the second IO device to the device service component; sending, by the device service component, the second interrupt request to the second host computer; wherein the second interrupt request comprises the second physical device identifier and an identifier of the first host computer; and the second physical device identifier and the identifier of the first host computer are used by the second host computer to determine an interrupt number of the second IO device in the second host computer.

14. An IO device management method, characterized by, a first host computer in which a virtual machine is deployed; the virtual machine is assigned a first IO device on a target host computer; the first host computer comprises a device agent component and a device driver agent component running in a kernel of the first host computer; and the method comprises: in a case where an application in the virtual machine initiates an access operation on the first IO device based on a first virtual device identifier, sending, by the device driver agent component, a target access request corresponding to the access operation to the device agent component; the first virtual device identifier is a device identifier of the first IO device in the first host computer; sending, by the device agent component, the target access request to the target host computer; wherein the first virtual device identifier is used by the target host computer to determine a first physical device identifier of the first IO device in the target host computer, and to access the first IO device based on the first physical device identifier to obtain a first access result; obtaining, by the device agent component, the first access result returned by the target host computer, and sending, by the device driver agent component, the first access result to the application in the virtual machine.

15. An IO device management method, suitable for a first host machine in which a virtual machine is deployed, the method comprising: the virtual machine is assigned a first IO device on a target host computer; the first host computer comprises a device agent component; and the method comprises: obtaining, by the device agent component, a first interrupt request of the first IO device forwarded by the target host computer; obtaining, by the device agent component, a first physical device identifier of the first IO device and an identifier of the target host computer from the first interrupt request; the first physical device identifier is a device identifier of the first IO device in the target host computer; determining, by the device agent component, a first virtual device identifier of the first IO device according to the first physical device identifier of the first IO device and the identifier of the target host computer; the first virtual device identifier is a device identifier of the first IO device in the first host computer; querying, by the device agent component, a mapping relationship between a target interrupt number and the first virtual device identifier maintained by an IOMMU in the first host computer according to the first virtual device identifier, to obtain the target interrupt number of the first IO device in the first host computer; sending, by the device agent component, the target interrupt number of the first IO device in the first host computer to an interrupt management unit in the first host computer, for the interrupt management unit in the first host computer to perform interrupt processing based on the target interrupt number of the first IO device in the first host computer.

16. An IO device management method, suitable for a target host, comprising: The first IO device on the target host machine is allocated to a virtual machine on the first host machine; The target host machine comprises a device service component; the method comprises: acquiring, by the device service component, a first IO device request of the first host machine; determining, by the device service component, a first IO device from at least one IO device on the target host machine in response to the first IO device request; returning, by the device service component, a first physical device identifier of the first IO device and first configuration information of the first IO device to the first host machine; The first physical device identifier is used for the first host machine to acquire a first virtual device identifier of the first IO device in the first host machine; and the first IO device is allocated to a virtual machine in the first host machine based on the first virtual device identifier and the first configuration information; the first virtual device identifier and the first physical device identifier have the same encoding mode.

17. The method of claim 16, wherein, The determining, by the device service component, a first IO device from at least one IO device on the target host machine in response to the first IO device request comprises: acquiring, from the first IO device request, a target type of a requested IO device and performance requirements of the requested IO device; determining, from at least one IO device on the target host machine, a currently idle first IO device according to the target type and the performance requirements; the type of the first IO device is the target type and the performance parameter meets the performance requirements.

18. The method of claim 16 or 17, wherein, The method further comprises: acquiring, by the device service component, a target access request for the first IO device sent by the first host machine; determining, by the device service component, a first physical device identifier of the first IO device in response to the target access request; performing, by the device service component, access to the first IO device according to the first physical device identifier and access requirements reflected by the target access request to obtain an access result; returning, by the device service component, the access result to the first host machine.

19. The method of claim 18, wherein, The determining, by the device service component, a first physical device identifier of the first IO device in response to the target access request comprises: acquiring, by the device service component, a first physical device identifier of the first IO device from the target access request; Alternatively, acquiring, by the device service component, a first virtual device identifier and an identifier of the first host machine from the target access request; the first virtual device identifier is a device identifier of the first IO device in the first host machine; determining, by the device service component, a first physical device identifier of the first IO device according to the first virtual device identifier, the identifier of the first host machine and a maintained correspondence between the identifier of the first host machine and the first virtual device identifier and the first physical device identifier.

20. The method of claim 16 or 17, wherein, The target host machine further comprises an interrupt management unit running in a kernel; the method further comprises: The interrupt management unit is configured to send a first interrupt request corresponding to the interrupt event of the first IO device to the device service component in response to the interrupt event of the first IO device; the first interrupt request comprises the first physical device identifier and the identifier of the target host; The device service component is configured to send the first interrupt request to the first host, so that the first host determines a target interrupt number of the first IO device in the first host according to the first physical device identifier and the identifier of the target host, and performs interrupt processing based on the target interrupt number.

21. An IO device management method, applicable to a target host, characterized in that, The first IO device on the target host is allocated to a virtual machine on the first host; The target host comprises a device service component; the method comprises: The device service component is configured to obtain a target access request of the first IO device sent by the first host; the target access request comprises a first virtual device identifier; the first virtual device identifier refers to a device identifier of the first IO device in the first host; The device service component is configured to determine a first physical device identifier of the first IO device according to the first virtual device identifier in response to the target access request; the first physical device identifier refers to a device identifier of the first IO device on the target host; the first virtual device identifier and the first physical device identifier have the same coding mode; The device service component is configured to access the first IO device according to the first physical device identifier and an access demand reflected by the target access request, to obtain an access result; The device service component is configured to return the access result to the first host.

22. An IO device management method, applicable to a target host, characterized in that, The first IO device on the target host is allocated to a virtual machine on the first host; The target host comprises a device service component; the method comprises: The device service component is configured to obtain a target access request of the first IO device sent by the first host; the target access request comprises a first physical device identifier; the first physical device identifier is determined by the first host according to a first virtual device identifier; the first virtual device identifier refers to a device identifier of the first IO device in the first host; the first physical device identifier refers to a device identifier of the first IO device on the target host; the first virtual device identifier and the first physical device identifier have the same coding mode; The device service component is configured to obtain the first physical device identifier from the target access request in response to the target access request; The device service component is configured to access the first IO device according to the first physical device identifier and an access demand reflected by the target access request, to obtain an access result; The device service component is configured to return the access result to the first host.

23. An IO device management method, applicable to a target host, characterized in that, The first IO device on the target host is allocated to a virtual machine on the first host; The target host machine comprises a device service component and an interrupt management unit running in a kernel of the target host machine; and the method comprises: sending, by the interrupt management unit, a first interrupt request to the device service component in response to an interrupt event of the first IO device; the first interrupt request comprising a first physical device identifier and an identifier of the target host machine; the first physical device identifier being a device identifier of the first IO device on the target host machine; sending, by the device service component, the first interrupt request to the first host machine; wherein the first physical device identifier and the identifier of the target host machine are used by the first host machine to determine a first virtual device identifier of the first IO device in the first host machine; wherein the first host machine further queries, according to the first virtual device identifier, a mapping relationship between a target interrupt number and the first virtual device identifier maintained by an IOMMU in the first host machine, to obtain the target interrupt number of the first IO device in the first host machine, and performs interrupt processing based on the target interrupt number of the first IO device in the first host machine.

24. A cloud service system, characterized by comprising: a plurality of host machines; the plurality of host machines being communicatively connected; a first host machine in the plurality of host machines having a virtual machine deployed therein; at least one second host machine in the plurality of host machines having at least one input / output (IO) device; the first host machine comprising a virtual machine manager and a device agent component; the virtual machine manager, in response to a cross-host allocation event of an IO device, sending an IO device request to the device agent component, so that the device agent component sends the IO device request to a device service component in a target host machine; the at least one second host machine comprising the target host machine; the device service component, in response to the IO device request, determining a target IO device from the at least one IO device on the target host machine, and obtaining configuration information of the target IO device; and returning a physical device identifier of the target IO device and the configuration information to the device agent component; the device agent component, based on the physical device identifier, obtaining a virtual device identifier of the target IO device in the first host machine; and sending the virtual device identifier and the configuration information to the virtual machine; the virtual device identifier and the physical device identifier having the same encoding manner; the virtual machine, according to the virtual device identifier and the configuration information, initializing and configuring resources of the target IO device, so as to allocate the target IO device to the virtual machine.

25. An electronic device, comprising: comprising: a memory and a processor; wherein the memory is configured to store a computer program; the processor is coupled to the memory and is configured to execute the computer program to perform the steps in the method of any one of claims 1-23.

26. A computer readable storage medium having stored thereon computer instructions, wherein, the computer instructions, when executed by one or more processors, cause the one or more processors to perform the steps in the method of any one of claims 1-23.

27. A computer program product, characterised in that, A computer program product comprising a computer program that, when executed using one or more processors, causes the one or more processors to perform the steps of the method of any of claims 1-23.

Images