TWI790615B - Device pass-through method for virtual machine and server using the same - Google Patents

Abstract

A device pass-through method for a virtual machine (VM) and a server using the same method are provided. The method includes: establishing a host operating system (OS) kernel including a device driver and a socket node corresponding to a hardware device and a VM including a guest OS and a guest kernel, wherein the guest OS includes an application and an analyzer; receiving an I/O request command from the application and transmitting an I/O request packet corresponding to the O request command to the analyzer by the guest kernel; transmitting, by the analyzer, an access packet corresponding to the I/O request command to the socket node corresponding to a virtual function (VF) name according to the VF name in the I/O request packet; accessing, by the socket node, the device driver according to the access packet to drive the hardware device.

Description

Device direct connection method of virtual machine and server thereof

The invention relates to a device-through method of a virtual machine and a server thereof.

The computing device can simulate a computer system through a virtual machine (virtual machine, VM) technology. The virtual machine can access the hardware device through a device pass-through technology to control the hardware device through a host (host) operating system (OS) kernel. Currently, virtual machines can perform device passthrough in various ways. For example, a VirtIO device developed by an independent hardware vendor (IHV) can be installed in a guest kernel of a virtual machine. When the guest operating system of the virtual machine wants to send access instructions to the host operating system, the guest operating system (guest OS) can send access instructions to the host operating system through the VirtIO device to access the hardware device through the host operating system . In addition, the virtual machine can use single root I/O virtualization (SR-IOV) technology to access the hardware device through a virtual function (virtual function, VF). Furthermore, the virtual machine can also use the veth technology to establish a channel between the virtual machine and the host operating system, and transmit access instructions to the host operating system through the channel. However, users who adopt the above methods need to entrust independent hardware manufacturers or independent software vendors (ISVs) to develop software, so users need to pay a fee.

On the other hand, the host operating system kernel can also use software (for example: QEMU or CrosVM) to generate a virtual device (virtual device) for the virtual machine to access. However, the above method will significantly reduce the performance of the computing device.

The invention provides a device direct connection method of a virtual machine and a server thereof, which can optimize the performance of the virtual machine.

A virtual machine server of the present invention includes a processor, a storage medium and a transceiver. The storage medium stores multiple modules. The processor is coupled to the storage medium and the transceiver, and accesses and executes multiple modules, wherein the multiple modules include a host operating system kernel and a virtual machine. The host operating system core is communicatively connected to the hardware device through the transceiver, and includes a device driver corresponding to the hardware device and a socket node. The virtual machine includes a client operating system and a client core, wherein the client operating system includes an application program and an analyzer, wherein the client core receives an I/O request command from the application program, and transmits an I/O request packet corresponding to the I/O request command To the analyzer, wherein the analyzer transmits the access packet corresponding to the I/O request command to the socket node corresponding to the virtual function name according to the virtual function name in the I/O request packet, wherein the socket node accesses the device driver according to the access packet program to drive the hardware device.

In an embodiment of the present invention, the above-mentioned client core includes a VirtIO device, wherein the I/O request packet includes one of a virtual function name and a hardware identification code, and wherein the analyzer responds to the I/O request packet including a hardware identification code and transmits the access packet to the host operating system core through the VirtIO device corresponding to the hardware identification code, wherein the host operating system core accesses the device driver according to the access packet to drive the hardware device.

In an embodiment of the present invention, the above-mentioned host operating system core increases the count value corresponding to the socket node by one in response to the socket node receiving the access packet, wherein the host operating system core outputs the count value through the transceiver.

In an embodiment of the present invention, the above analyzer generates an access packet according to the I/O request packet, wherein the access packet includes an access instruction and a socket node name corresponding to the socket node.

In an embodiment of the present invention, the above-mentioned access packet further includes a virtual machine address corresponding to the virtual machine, wherein the socket node transmits the output of the hardware device to the virtual machine according to the address of the virtual machine in response to driving the hardware device .

In an embodiment of the present invention, the above-mentioned access packet includes a VirtIO device address corresponding to the VirtIO device, wherein the host operating system kernel transmits the output of the hardware device to the VirtIO according to the VirtIO device address in response to driving the hardware device device.

In an embodiment of the present invention, the above-mentioned host operating system kernel detects a hardware device through a transceiver, and creates a device driver and a socket node in response to the detected hardware device.

In an embodiment of the present invention, the above-mentioned host operating system kernel sends a configuration packet to the analyzer in response to detecting the hardware device, wherein the configuration packet includes a hardware identification code corresponding to the hardware device, a socket node corresponding to A socket node address and a socket node name corresponding to the socket node.

In an embodiment of the present invention, the above analyzer generates a mapping table of virtual function names and socket node names according to the configuration packet.

In an embodiment of the present invention, the above analyzer transmits the access packet to the socket node corresponding to the virtual function name according to the mapping table.

In an embodiment of the present invention, the above analyzer and the socket node communicate with each other through a virtual machine socket (vsock) protocol.

A device-through method for a virtual machine of the present invention includes: establishing a host operating system core and a virtual machine, wherein the host operating system core includes a device driver corresponding to a hardware device and a socket node, wherein the virtual machine includes a client operating system and a virtual machine. The client core, wherein the client operating system includes an application program and an analyzer; the client core receives the I/O request command from the application program, and sends an I/O request packet corresponding to the I/O request command to the analyzer; the analyzer according to The virtual function name in the I/O request packet transmits the access packet corresponding to the I/O request command to the socket node corresponding to the virtual function name; and the socket node accesses the device driver according to the access packet to drive the hardware device.

Based on the above, the virtual machine of the present invention can access the hardware device by communicating with the socket node dedicated to the hardware device. Compared with the traditional virtual machine accessing the hardware device through the virtual device, accessing the hardware device through the socket node can avoid the binary translation (binary translation) program, thereby reducing the waste of computing resources.

In order to make the content of the present invention more comprehensible, the following specific embodiments are taken as examples in which the present invention can actually be implemented. In addition, wherever possible, elements/components/steps using the same reference numerals in the drawings and embodiments represent the same or similar parts.

FIG. 1 shows a schematic diagram of a virtual machine server 100 according to an embodiment of the present invention. The server 100 may include a processor 110 , a storage medium 120 and a transceiver 130 .

The processor 110 is, for example, a central processing unit (central processing unit, CPU), or other programmable general purpose or special purpose micro control unit (micro control unit, MCU), microprocessor (microprocessor), digital signal processing Digital signal processor (DSP), programmable controller, application specific integrated circuit (ASIC), graphics processing unit (graphics processing unit, GPU), image signal processor (image signal processor, ISP) ), image processing unit (image processing unit, IPU), arithmetic logic unit (arithmetic logic unit, ALU), complex programmable logic device (complex programmable logic device, CPLD), field programmable logic gate array (field programmable gate array , FPGA) or other similar components or combinations of the above components. The processor 110 can be coupled to the storage medium 120 and the transceiver 130 , and access and execute multiple modules and various application programs stored in the storage medium 120 .

The storage medium 120 is, for example, any type of fixed or removable random access memory (random access memory, RAM), read-only memory (read-only memory, ROM), flash memory (flash memory) , hard disk drive (hard disk drive, HDD), solid state drive (solid state drive, SSD) or similar components or a combination of the above components, and are used to store multiple modules or various application programs executable by the processor 110 .

The transceiver 130 transmits and receives signals in a wireless or wired manner. The transceiver 130 may also perform operations such as low noise amplification, impedance matching, frequency mixing, up or down frequency conversion, filtering, amplification, and the like.

FIG. 2 shows a schematic diagram of multiple modules in the storage medium 120 according to an embodiment of the present invention. The multiple modules in the storage medium 120 may include a host operating system kernel 200 and a virtual machine 300 . The host operating system core 200 can be communicatively connected to the hardware device 400 through the transceiver 130 . The virtual machine 300 can access the hardware device 400 through the host operating system kernel 200 . Although the embodiment of FIG. 2 implements the host operating system kernel 200 and the virtual machine 300 through a single device (ie, the server 100 ), the present invention is not limited thereto. For example, the host operating system kernel 200 and the virtual machine 300 can be respectively implemented by different computing devices that are communicatively connected to each other.

The host operating system kernel 200 may include a socket node 210 corresponding to the hardware device 400 and a device driver 230 . The socket node 210 can access the hardware device 400 through the device driver 230 . The virtual machine 300 is, for example, a kernel-based virtual machine (kernel-based virtual machine, KVM). The virtual machine 300 may include a guest operating system (guest OS) 310 and a guest kernel (guest kernel) 330 . The client operating system 310 may include an application program 311 and an analyzer 313 , wherein the analyzer 313 may include a socket 315 corresponding to the hardware device 400 . The client core 330 may include a VirtIO device 331 .

FIG. 3 shows a flowchart of a device-through method for a virtual machine according to an embodiment of the present invention, wherein the device-through method can be implemented by the server 100 shown in FIG. 1 . In this embodiment, assuming that the application program 311 wants to access the hardware device 400 , the virtual machine 300 can determine to access the hardware device 400 through the virtIO device 331 or the socket 315 according to the device direct method.

Referring to FIG. 2 and FIG. 3, in step S301, the client core 330 may transmit the input/output (I/O) request packet (ie: IRP packet) S2 to the analyzer 313, wherein the I/O request packet S2 corresponds to in the hardware device 400 . The analyzer 313 can obtain the I/O request packet S2 from the client core 330 . Specifically, the application program 311 can receive data through the transceiver 130, and generate an I/O request command (or called "I/O interrupt command") S1 according to the received data, wherein the I/O request command S1 can be Corresponds to the hardware device 400 . The application program 311 can send the I/O request command S1 to the client core 330 , and the client core 330 can send the I/O request packet S2 corresponding to the I/O request command S1 to the analyzer 313 . The I/O request packet S2 may include a virtual function name (VF name) or a hardware identification code (hardware ID, HW ID).

For example, the server 100 can be connected to an external input device (such as a keyboard) through the transceiver 130 . The user can operate the application program 311 through an external input device to send the I/O request command S1 to the client core 330 . For another example, the server 100 can be connected to an external electronic device (eg, a terminal device or a server) through the transceiver 130 . The application program 311 can receive commands from the external electronic device through the transceiver 130 , and transmit the I/O request command S1 to the client core 330 according to the commands.

In step S302, the analyzer 313 can determine whether the I/O request packet S2 contains a hardware identification code. If the I/O request packet S2 includes the hardware identification code, go to step S303. If the I/O request packet S2 does not include the hardware identification code, go to step S308.

The I/O request packet S2 includes a hardware identification code indicating that the virtIO device 331 dedicated to the hardware device 400 exists in the client core 330 . Therefore, if the client core 330 judges that the I/O request command S1 is for accessing the hardware device 400, the client core 330 can encapsulate the hardware identification codes corresponding to the hardware device 400 and the virtIO device 331 in the I /O request packet S2. The client core 330 can instruct the analyzer 313 to use the virtIO device 331 to access the hardware device 400 through the I/O request packet S2. On the other hand, if there is no virtIO device dedicated to the hardware device 400 in the client core 330 (ie: the virtIO device 331 does not belong to the hardware device 400), the client core 330 will not be able to instruct the analyzer 313 to use the virtIO device 331 to access the hardware device 400 .

In step S303 , the analyzer 313 can generate an access packet S3 corresponding to the hardware device 400 according to the I/O request packet S2 , wherein the access packet S3 can include an access command for accessing the hardware device 400 . In step S304, the analyzer 313 may transmit the access packet S3 to the virtIO device 331 corresponding to the hardware identification code.

In one embodiment, if the virtual machine 300 wants to obtain the output of the hardware device 400 after accessing the hardware device 400, the access packet S3 may further include the virtIO device address 33 of the virtIO device 331, wherein the virtIO device address 33 is the memory address of the storage medium 120 . Accordingly, the analyzer 313 can instruct the host operating system kernel 200 to feed back the output of the hardware device 400 to the virtual machine 300 through the virtIO device address 33 by accessing the packet S3 .

In step S305 , the virtIO device 331 can send the access packet S3 to the host operating system kernel 200 . The host operating system core 200 can access the device driver 230 according to the access packet S3 to drive the hardware device 400 . Specifically, the virtIO device 331 can send the access packet S3 to the hardware device address 34 of the hardware device 400 , wherein the hardware device address 34 is the memory address of the storage medium 120 . The device driver 230 can obtain the access packet S3 from the hardware device address 34, and drive the hardware device 400 according to the access packet S3.

In step S306 , the host operating system kernel 200 can determine whether the access packet S3 includes the virtIO device address 33 of the virtIO device 331 . If the access packet S3 includes the virtIO device address 33, go to step S307. If the access packet S3 does not include the virtIO device address 33, the process ends.

In step S307 , the host operating system core 200 can transmit the output S4 of the hardware device 400 to the VirtIO device 331 according to the virtIO device address 33 of the virtIO device 331 . The VirtIO device 331 can further transmit the output S4 of the hardware device 400 to the application program 311 .

In step S308, the analyzer 313 can generate an access packet S5 corresponding to the hardware device 400 according to the I/O request packet S2, wherein the access packet S5 can include an access command for accessing the hardware device 400 and Socket node name corresponding to socket node 210 .

In step S309, the analyzer 313 can transmit the access packet S5 to the socket node 210 corresponding to the name of the virtual function, wherein the analyzer 313 and the socket node 210 can communicate with each other through the VM socket (vsock) protocol communication. Therefore, the virtual machine 300 can transmit the access packet S5 to the host operating system kernel 200 without performing binary translation. Specifically, the analyzer 313 may store a mapping table of virtual function names and socket node names. After obtaining the virtual function name from the I/O request packet S2 , the analyzer 313 can determine that the virtual function name corresponds to the socket node name of the socket node 210 according to the mapping table. Accordingly, the analyzer 313 can transmit the access packet S5 to the socket node address 32 of the socket node 210 through the socket 315 , wherein the socket node address 32 is the memory address of the storage medium 120 . In other words, the analyzer 313 can transmit the access packet S5 to the socket node 210 corresponding to the name of the virtual function according to the mapping table. The method for establishing the mapping table is described in the embodiment of FIG. 4 .

In one embodiment, if the virtual machine 300 wants to obtain the output of the hardware device 400 after accessing the hardware device 400, the access packet S5 may further include the virtual machine address 31 of the virtual machine 300, wherein the virtual machine address 31 is the memory address of the storage medium 120 . Accordingly, the analyzer 313 can instruct the host operating system kernel 200 to feed back the output of the hardware device 400 to the virtual machine 300 through the virtual machine address 31 through the access packet S5 .

In one embodiment, the host operating system kernel 200 may increase the count value corresponding to the socket node 210 by one in response to the socket node 210 receiving the access packet S5. The host operating system core 200 can output the count value of the socket node 210 through the transceiver 130 for user's reference. For example, if the count value of the socket node 210 exceeds the threshold within a certain period of time, the user can determine that the virtual machine 300 often needs to access the hardware device 400 corresponding to the socket node 210 . Accordingly, the user may consider creating a dedicated VirtIO device for the hardware device 400 . The VirtIO device dedicated to the hardware device 400 can improve the efficiency of accessing the hardware device 400 .

In step S310 , the socket node 210 can access the driver program 230 according to the access packet S5 to drive the hardware device 400 .

In step S311 , the host operating system kernel 200 can determine whether the access packet S5 includes the virtual machine address 31 of the virtual machine 300 . If the access packet S5 includes the virtual machine address 31, go to step S312. If the access packet S5 does not contain the virtual machine address 31, the process ends.

In step S312 , the host operating system kernel 200 can transmit the output S6 of the hardware device 400 to the virtual machine 300 according to the virtual machine address 31 of the virtual machine 300 . The application program 311 in the virtual machine 300 can obtain the output S6 of the hardware device 400 .

FIG. 4 is a flowchart of a method for establishing a D2D channel for a hardware device 400 according to an embodiment of the present invention, wherein the method can be implemented by the server 100 shown in FIG. 1 . After the establishment of the D2D channel of the hardware device 400 is completed, the server 100 can execute the method shown in FIG. 3 .

In step S401 , the host operating system core 200 can detect the hardware device 400 through the transceiver 130 .

In step S402 , the host operating system kernel 200 may create (or launch) the device driver 230 corresponding to the hardware device 400 .

In step S403 , the host operating system kernel 200 may establish the socket node 210 corresponding to the hardware device 400 .

In step S404 , the host operating system core 200 may send the configuration packet to the analyzer 313 . The configuration packet may include a hardware identification code corresponding to the hardware device 400 , and may include a socket node name and a socket node address corresponding to the socket node 210 .

In step S405, the analyzer 313 can generate a mapping table of virtual function names and socket node names according to the configuration packet. Specifically, after receiving the configuration packet, the analyzer 313 can establish a virtual function corresponding to the hardware identification code (or hardware device 400) in the configuration packet, and can generate a virtual function name corresponding to the virtual function . The name of the virtual function generated according to the configuration packet corresponds to the name of the socket node in the configuration packet. In other words, there is a mapping between virtual function names and socket node names. Accordingly, the analyzer 313 may establish a mapping table of virtual function names and socket node names according to the mapping relationship. In addition, the analyzer 313 can establish the socket 315 corresponding to the socket node 210 according to the configuration packet.

FIG. 5 shows a flow chart of another D2D method for a virtual machine according to an embodiment of the present invention, wherein the D2D method can be implemented by the server 100 shown in FIG. 1 . In step S501, a host operating system core and a virtual machine are established, wherein the host operating system core includes a device driver corresponding to a hardware device and a socket node, wherein the virtual machine includes a client operating system and a client core, wherein the client operates The system consists of applications and analyzers. In step S502, the client core receives the I/O request command from the application program, and sends the I/O request packet corresponding to the I/O request command to the analyzer. In step S503, the analyzer transmits the access packet corresponding to the I/O request command to the socket node corresponding to the virtual function name according to the virtual function name in the I/O request packet. In step S504, the socket node accesses the device driver according to the access packet to drive the hardware device.

To sum up, the analyzer of the present invention can determine whether to use the VirtIO device to access the host operating system kernel when receiving the I/O request packet. When the analyzer determines that the VirtIO device is not used, the analyzer can access the hardware device by communicating with a socket node dedicated to the hardware device. Compared with the traditional virtual machine accessing the hardware device through the virtual device, accessing the hardware device through the socket node can avoid the occurrence of the binary translation program, thereby reducing the waste of computing resources. In addition, the host operating system kernel of the present invention can count the number of times the socket node is accessed for user reference. Users can decide whether to develop a dedicated VirtIO device for the corresponding hardware device according to the number of times the socket node is accessed. If the access packet includes the address of the virtual machine, the host operating system kernel can return the output of the hardware device to the virtual machine according to the address of the virtual machine. On the other hand, when the host operating system core detects a new hardware device, the host operating system core can transmit the relevant information of the new hardware device to the analyzer. The analyzer can access the hardware device according to the relevant information.

100: server 110: Processor 120: storage media 130: Transceiver 200: host operating system core 210: socket node 230:Device Driver 300: virtual machine 310: client operating system 31: virtual machine address 311: Application 313: Analyzer 315: socket 32: socket node address 33: virtIO device address 330: client core 34: Hardware device address 400: hardware device S1: Input and output request command S2: Input and output request packets S3, S5: access packets S4, S6: output S301, S302, S303, S304, S305, S306, S307, S308, S309, S310, S311, S312, S401, S402, S403, S404, S405, S501, S502, S503, S504: steps

FIG. 1 is a schematic diagram of a virtual machine server according to an embodiment of the present invention. FIG. 2 is a schematic diagram illustrating a plurality of modules in a storage medium according to an embodiment of the present invention. FIG. 3 is a flow chart of a device-through method for a virtual machine according to an embodiment of the present invention. FIG. 4 is a flowchart illustrating a method for establishing a D2D channel for a hardware device according to an embodiment of the present invention. FIG. 5 is a flow chart illustrating another device-through method for a virtual machine according to an embodiment of the present invention.

S501, S502, S503, S504: steps

Claims (12)

A server for a virtual machine, including: a transceiver; a storage medium, storing multiple modules; and a processor, coupled to the storage medium and the transceiver, and accessing and executing the multiple modules, wherein The plurality of modules include: a host operating system core, communicatively connected to a hardware device through the transceiver, and including a device driver corresponding to the hardware device and a socket node; and a virtual machine, including a client operating A system and a client core, wherein the client operating system includes an application program and an analyzer, wherein the client core receives input and output request commands from the application program, and transmits input and output corresponding to the input and output request commands request packets to the parser, wherein the parser transmits an access packet corresponding to the I/O request instruction to the virtual function name corresponding to the I/O request packet in response to the I/O request packet containing a virtual function name A socket node, wherein the socket node accesses the device driver according to the access packet to drive the hardware device. The server as described in claim 1, wherein the client core includes a VirtIO device, wherein the input/output request packet includes one of the virtual function name and a hardware identification code, wherein the analyzer responds to The input and output please The request packet includes the hardware identification code and the access packet is sent to the host operating system kernel through the VirtIO device corresponding to the hardware identification code, wherein the host operating system kernel is based on the access The packet accesses the device driver to drive the hardware device. The server of claim 1, wherein the host operating system core increments a count value corresponding to the socket node by one in response to the socket node receiving the access packet, wherein the host operating system core The count value is output by the transceiver. The server according to claim 1, wherein the analyzer generates the access packet according to the input/output request packet, wherein the access packet includes an access instruction and a socket node name corresponding to the socket node . The server according to claim 4, wherein the access packet further includes a virtual machine address corresponding to the virtual machine, wherein the socket node responds to driving the hardware device according to the virtual machine address The address transfers the output of the hardware device to the virtual machine. The server of claim 2, wherein the access packet includes a VirtIO device address corresponding to the VirtIO device, wherein the host operating system kernel responds to driving the hardware device according to the VirtIO device The address transfers the output of the hardware device to the VirtIO device. The server of claim 1, wherein the host operating system core detects the hardware device through the transceiver, and creates the device driver and the device driver in response to detecting the hardware device. socket node. The server of claim 7, wherein the host operating system kernel transmits a configuration packet to the analyzer in response to detecting the hardware device, wherein the configuration packet includes a configuration corresponding to the hardware device A hardware identification code, a socket node address corresponding to the socket node, and a socket node name corresponding to the socket node. The server according to claim 8, wherein the analyzer generates a mapping table of the virtual function name and the socket node name according to the configuration packet. The server according to claim 9, wherein the analyzer transmits the access packet to the socket node corresponding to the virtual function name according to the mapping table. The server according to claim 1, wherein the analyzer and the socket node communicate with each other through a virtual machine socket (vsock) protocol. A device direct method for a virtual machine, comprising: establishing a host operating system core and a virtual machine, wherein the host operating system core includes a device driver corresponding to a hardware device and a socket node, wherein the virtual machine includes a client operating system and a client core, wherein the client operating system includes an application program and an analyzer; the client core receives an input-output request command from the application program, and transmits an input-output request corresponding to the input-output request command packet to said parser; packet containing virtual function name by said parser in response to said I/O request Said that the access packet corresponding to the input and output request command is transmitted to the socket node corresponding to the name of the virtual function; and the device driver is accessed by the socket node according to the access packet to drive The hardware device.

Images