JP5960186B2 - Virtual channel construction system, virtual channel construction method, and virtual channel construction program - Google Patents

Description

  The present invention relates to a system for constructing a dedicated virtual communication path with an external process in which a guest OS operating in a virtual machine exists outside the own virtual machine and a method for controlling the virtual communication path in a host operating system capable of operating a virtual machine.

  A hypervisor environment configured with Linux (registered trademark) and KVM (kernel-based virtual machine) is well known as a technology for configuring a virtual machine. In this environment, a host OS in which a KVM module is incorporated (an OS installed on a physical server is called a host OS) operates as a hypervisor in a kernel space (in a memory area different from a user space called), and this environment , A virtual machine operates in the user space, and a guest OS (an OS installed on the virtual machine is called a guest OS) operates in the virtual machine.

  Unlike a physical server on which a host OS operates, a virtual machine on which a guest OS operates is configured such that all hardware including a network device (typically represented by an Ethernet card device) performs interrupt processing from the hardware to the guest OS. Since notifications and processing that should be originally performed by physical hardware such as register control necessary for writing from the guest OS to the hardware are simulated in software, the performance is generally lower than that of the host OS environment. is there.

  In this performance degradation, technology that reduces imitation of hardware and improves communication performance and versatility through a high-speed and uniform interface, especially from the guest OS to the host OS and external processes that exist outside the virtual machine. As an example, a device abstraction technology called Virtual, that is, a para-virtualization technology has been developed, and has already been incorporated into many general-purpose OSs such as Linux (registered trademark) and FreeBSD (registered trademark) and is currently used.

<How Virtio works>
In relation to data input / output such as console, file input / output, and network communication, Virtual defines data exchange by a queue designed by a ring buffer and queue operation as a transport for unidirectional transfer of transfer data. By using the virtual queue specifications, the number and size of queues suitable for each device are prepared when the guest OS is started, so that communication between the guest OS and the outside of the virtual machine can be performed by hardware emulation. It can be realized only by an operation by a queue without performing it. Detailed specifications are described in Non-Patent Document 1.

  Specifically, a virtual device exists as a PCI device for the console, file input / output, and network communication in the virtual machine (console is called virtual-console, file input / output is called virtual-blk, and network is called virtual-net). The device and the driver of the corresponding OS are defined in the virtual queue), and when the guest OS starts up, two data transfer endpoints (transmission / reception endpoints) between the guest OS and the other party are created, and the data transmission / reception parent-child relationship is established To construct. In many cases, the parent-child relationship is configured by the virtual machine side (child side) and the guest OS (parent side).

  As shown in FIG. 1, the child side exists as the configuration information of the device in the virtual machine, and requests the parent side the size of each data area, the number of required combinations of endpoints, and the type of device. In accordance with the request from the child side, the parent side allocates and secures a memory for a shared buffer queue for storing and transferring necessary data and returns the address address to the child side so that the child side can access it. The operations of the shared buffer queue required for data transfer are all common in the Virti, and are executed as agreed on both the parent side and the child side (the operation of the Virio queue will be described later) For reference). It is also assumed that the size of the shared buffer queue is agreed upon (that is, it is determined for each device). As a result, it is possible to operate a queue shared by both the parent side and the child side only by transmitting the address to the child side.

  Since the shared buffer queue prepared in the Virtual is prepared for a single direction, for example, a virtual network device called a virtual-net device includes three ring buffers for transmission, reception, and control. The communication between the parent and the child is realized by writing to the shared buffer queue and the buffer update notification, writing to the ring buffer, and notifying the other party. When the other party receives the notification, it confirms how much new data is stored in which shared buffer queue by using the common operation of Virtual, and takes out a new buffer area. This establishes data transfer from the parent to the child or from the child to the parent.

  As described above, by sharing the ring buffer for exchanging data with each other and the operation method for each ring buffer (common in Virti) between the parent and child, communication between the guest OS and the outside that does not require hardware emulation is possible. Realize. As a result, data transmission / reception between the guest OS and the outside can be realized at higher speed than conventional hardware emulation.

<Virtual Queue Operation>
(Configuration of shared buffer queue)
A shared buffer queue shared by the parent side (example: guest OS) and the child side (example: virtual machine) will be described. The shared buffer queue is as described in Non-Patent Document 1, but will be described in this section because it presupposes operations related to queue configuration and queue operation when describing the operation (example) of the present invention. . As described above, the shared buffer queue is used in a single direction from the parent side to the child side or from the child side to the parent side, and includes the following elements as shown in FIG. The data transfer queue has two queues for transmission and reception (as in the specification of virtual-net).

Descriptor pointer string Pointer for referring to each descriptor that stores transfer data. The descriptor is composed of four reference addresses of transfer data, its length, a transfer flag (the description is omitted because it is not particularly important in the present invention), and a descriptor pointer when there is subsequent data (FIG. 2). .

-Avail ring In an avail ring, it consists of four elements, a header, an avail index (availidx), an avail ring string, and a used_event. The header is omitted because it is not particularly important in the present invention. The avail ring sequence is composed of ring buffers in which indexes are assigned in order (in the figure, indexes are assigned from the number 0), and the descriptor numbers prepared and prepared by the guest OS side are assigned to the buffers according to the order of the indexes. be written. In the avail index, the guest OS describes the final index of the avail ring column that is currently consumed. Since used_event is not particularly important for the present invention, it is omitted.

Used ring The used ring includes four elements: a header, a used index (usedidx), a used ring sequence, and an available_event. The header is omitted because it is not particularly important in the present invention. Each used ring column is composed of a ring buffer in which indexes are assigned in order, and descriptor numbers taken out by the virtual machine in the order of the index from the avail ring column prepared by the guest OS are sequentially written in the ring. In the used index, the virtual machine describes the final index of the used ring sequence that has been consumed. Since “avail_event” is not particularly important for the present invention, it is omitted.

・ Last_avail_idx
This index value is a value held on the child side, and becomes an avail index value of an avail ring that is finally extracted and collected. The child side can know the number of updated avail rings by comparing the avail_idx updated by the parent side with the last_avail_idx.

・ Last_used_idx
This index value is a value held by the parent side and is a used index value of the used ring that is finally extracted and collected. By comparing the used_idx updated by the child side with the last_used_idx, the parent side can know the number of updated used rings.

(Data transfer from parent side (eg guest OS) to child side (eg virtual machine))
Data transmission from the parent side to the child side uses a queue dedicated to transmission. In the initial state, the descriptor, the available ring sequence, and the used ring sequence are initialized as shown in FIG. When transferring one piece of data to the virtual machine side, the guest OS writes the descriptor number (S-1) secured at the head of the avail ring as shown in FIG. S is the size of the ring row. The descriptor S-1 is filled with transfer data by the guest OS. Then, the guest OS advances availidx to 0. Thereafter, the guest OS sends an avail ring update notification to the virtual machine side.

  In FIG. 5, the virtual machine receives the update notification and checks the avail ring string. At this time, last_avail_idx is managed on the virtual machine side in order to check the number of rings written by the guest OS to the avail ring string. The last_avail_idx is an initial value, and the virtual machine recognizes that one piece of data is included in the avail ring by comparing the availidx and the last_avail_idx. The virtual machine finds the descriptor number from the ring with index 0 (S-1), and refers to the descriptor S-1 to collect the transfer data written by the guest OS. After collecting the data from the avail ring, the used ring row is updated as follows for the collected amount.

  Each time the virtual machine collects one from the avail ring, it writes the descriptor number written in the avail ring to the used ring while incrementing the value of usedidx. After writing, usedidx is incremented by one. When the virtual machine finishes updating the used ring queue, it updates last_avail_idx to 0 and notifies the guest OS using the used ring update notification.

  In FIG. 6, the guest OS receives a notification from the virtual machine, releases the data area referred to by the descriptor number described in the used ring number 0 from usedidx and last_used_idx managed by the guest OS, and changes last_used_idx to 0. To do.

  As described above, data transfer is realized while circularly using the avail ring sequence and the used ring sequence as ring buffers.

(Data transfer from child side (example: virtual machine) to parent side (example: guest OS))
Data transfer from the child side to the parent side uses a reception-only queue. Unlike the initial state of transfer from the parent side to the child side, when transmitting from the child side to the parent side, as many reserved descriptors as possible are prepared in the available avail ring string.

  In FIG. 7, when a receive-only queue is prepared, all descriptors are written to the avail ring queue, and availidx is advanced to S-1.

  In FIG. 8, when the virtual machine transfers data to the guest OS, it is taken out from the available avail ring queue. For example, when transferring one piece of data, since last_avail_idx is initialized, the avail ring 0 is referred to and the transfer data is written using the descriptor S-1. Last_avail_idx is updated to 0. After that, since usedidx is initialized, the descriptor number S-1 used for the used ring 0 is described, and after the usedidx is updated to 0, a used ring update notification is transmitted to the guest OS.

  In FIG. 9, the guest OS receives a used ring update notification from the virtual machine, and collects the data area referred to by the descriptor number described in the used ring number 0 from usedidx and last_used_idx managed by the guest OS as transfer data. Release and change last_used_idx to 0.

  As described above, data transfer from the virtual machine to the guest OS is realized while circularly using the avail ring sequence and the used ring sequence as ring buffers in a state where the descriptor is secured in advance on the guest OS side.

  As described above, the transfer from the guest OS to the virtual machine side (transmission when viewed from the guest OS) and the transfer from the virtual machine side to the guest OS side (reception when viewed from the guest OS) have been described. FIG. 10 shows a summary of these.

<Communication method between guest OS using Virtual and outside of own virtual machine>
When the guest OS in the virtual machine communicates with the outside, the child side needs to connect to the outside, and the child side needs to transmit and receive data as a relay role between the outside and the parent side. For example, communication between a guest OS and a host OS is one example. Here, when the outside is a host OS, there are two patterns as existing communication methods.

In the first method (hereinafter referred to as external communication method 1), a child-side endpoint is constructed in a virtual machine, communication between the guest OS and the virtual machine, and a communication endpoint provided by the host OS (usually tap / By connecting a device called a “tun device” in the virtual machine, the following connection is established, and communication from the guest OS to the host OS is realized.
(Reference 1) [Connections to be built]

At this time, since the guest OS operates in a memory area called a user space having a different authority from a memory area called a kernel space where the tap driver and the host OS operate, communication from the guest OS to the host OS is performed at least once. Memory copy occurs (FIG. 12).

  In the second method (hereinafter referred to as external communication method 2), there is a technique called vhost-net as means for solving this. In vhost-net, the parent-side configuration information (the size of the shared buffer queue, the number of queues, the identifier, the head address information for accessing the ring buffer, etc.) once built in the virtual machine is stored in the vhost- internal host OS. This is a technique that allows a shared buffer queue operation to be directly performed between a guest OS and a host OS by copying to a net driver and constructing information on the child side endpoints inside the host. As a result, copying can be performed only 0 times, and compared with the external communication method 1, data transfer can be realized at a higher speed compared to the external communication method 1 because the number of times of copying is one less than that of the virtual-net.

http: // ozlabs. org / ~ rusty / virtio-spec / virtio-0.9.5. pdf (searched on March 10, 2014) http: // www. intel. co. jp / content / www / jp / ja / communications / communications-packet-processing-brief. html (retrieved on March 10, 2014)

  In Virtual, it was considered as a transport abstraction technology for constructing a virtual communication path in the same physical server that connects a guest OS and a virtual machine (or a host OS existing ahead). However, when considering communication with the outside, it is necessary to consider the connection between the virtual machine and the outside.

  In the existing system, an external communication system 1 and an external communication system 2 have been developed and are based on communication with the host OS. In this case, in order to improve data transfer performance, a problem is to reduce the number of copies in order to make communication via the host OS as fast as possible. In order to deal with this problem, as described above, a technique for realizing a real zero copy called vhost-net is considered.

  In recent years, in order to improve the throughput of communication applications by software implementation, bypass high-speed technology (for example, Intel DPDK in Non-Patent Document 2) that does not pass through the host OS has been considered, and the configuration in the physical host has been conventionally relayed. In many cases, what is implemented on the host OS side, such as a virtual switch having a function, is implemented in an external process and operates in the same process together with the virtual machine. However, vhost-net does not consider inter-process communication, and, as before, using a tap device causes a real copy to occur at least once (Problem 1) (see FIG. 13). ).

  As described above, in the case of bypassing the host OS, communication between the virtual machine and external processes increases, and at the same time, maintenance and errors do not affect each connection destination, and use cases such as switching and restarting Always occurs. However, vhost-net is designed for the purpose of sharing only the queue operation between the guest OS and the host OS, and operates as a module on the host OS, so that a fault system such as a module error or a module is deleted. Is not provided on both the communication device side of the virtual machine and the host OS module side of the vhost-net (Problem 2) (see FIG. 13).

  Therefore, in order to solve the above two problems, the present invention can improve the throughput of communication between a virtual machine and an external process in the bypass high-speed technology, and has a virtual communication path construction having a function for dealing with a failure type event. It is an object to provide a system, a virtual communication path construction method, and a virtual communication path construction program.

  In order to achieve the above object, the present invention has a function of directly connecting an external process side and a virtual machine side via a virtual communication path, detecting a connection partner state, and reconnecting according to the partner state. It was.

Specifically, the virtual communication path construction system according to the present invention is:
A physical machine having a virtual machine and a host OS capable of operating an external process formed outside the virtual machine;
A communication path constructing means for constructing a virtual communication path for directly connecting the virtual machine and the external process to the guest OS operating in the virtual machine;
Is provided.

Specifically, the virtual communication path construction method according to the present invention is:
A virtual machine forming procedure for forming the virtual machine and the external process on a physical machine having a virtual machine and a host OS capable of operating an external process formed outside the virtual machine;
A virtual communication path construction procedure for constructing a virtual communication path for directly connecting the virtual machine and the external process to the guest OS operating in the virtual machine is performed.

  In the present invention, since the external process side and the virtual machine side can be directly connected, the number of times of memory copy and context switch switching can be reduced compared to the external communication methods 1 and 2, and high-speed data transfer is realized. be able to. Therefore, the present invention can provide a virtual communication path construction system and a virtual communication path construction method capable of improving the throughput of communication between a virtual machine and an external process in the bypass acceleration technology.

The communication path construction means of the virtual communication path construction system according to the present invention is:
For the shared buffer queue formed for data transfer between the virtual machine and the guest OS, the data transfer destination of the shared buffer queue is extended to the external process by a memory operation, and the virtual communication path is constructed. And a shared buffer queue expansion protocol function for realizing a procedure related to communication between the guest OS and the external process.

The virtual communication path construction procedure of the virtual communication path construction method according to the present invention is:
For the shared buffer queue formed for data transfer between the virtual machine and the guest OS, the data transfer destination of the shared buffer queue is extended to the external process by a memory operation, and the virtual communication path is constructed. And a shared buffer queue extending step for realizing a procedure related to communication between the guest OS and the external process.

  The present invention realizes data transfer between a guest OS and an external process by a memory operation of the shared buffer queue, similarly to data transfer realized by a shared buffer queue between the virtual device and the guest OS.

The communication path construction means of the virtual communication path construction system according to the present invention is:
A connection state detection function for detecting the state of the virtual communication path;
A connection status notification function for notifying the status of the virtual communication path to the processing logic on the guest OS and the external process, respectively;
A reconnection function that periodically reconnects to the communication destination when each of the communication devices is disconnected,
It further has these.

The virtual communication path construction procedure of the virtual communication path construction method according to the present invention is:
A connection state detection step for detecting the state of the virtual communication path;
A connection state notification step of notifying the guest OS and the processing logic on the external process, respectively, of the state of the virtual communication path;
A reconnection step of periodically reconnecting to the communication destination when each of the communication devices is disconnected;
It further has these.

  Furthermore, according to the present invention, the communication devices of the virtual machine and the external process each detect the change in the state of the other party's connection, and notify the inside thereof of the guest OS and the processing logic inside the external process. Opportunities can be created to deal with events such as failures and maintenance. Further, according to the present invention, when a virtual machine or an external process falls into a disconnected state, the state can be correctly grasped, and the operation can be switched to the operation of switching the connection partner using that as a trigger. Therefore, the present invention can provide a virtual communication path construction system and a virtual communication path construction method having a function to cope with a failure-type event in the bypass high-speed technology.

  The virtual communication path construction program according to the present invention provides a virtual communication path according to any one of claims 4 to 6 in a physical machine having a virtual machine and a host OS capable of operating an external process formed outside the virtual machine. Realize the construction method.

  The virtual communication path construction method can be realized by operating the virtual communication path construction program on a physical machine having a virtual machine and a host OS capable of operating an external process formed outside the virtual machine.

  The present invention relates to a virtual communication path construction system, a virtual communication path construction method, and a virtual communication path that can improve the throughput of communication between a virtual machine and an external process in the bypass high-speed technology, and have a function to cope with a failure-type event A construction program can be provided.

It is a figure explaining the structure of the transmission / reception end point of a Virtual-net device. <A> is an end point on the parent side, creates a ring buffer memory area, teaches the address to the child side, and allows the parent and child to access the data. <B> is an end point on the child side, and requests the size and number of ring buffers necessary for the parent side. When the guest OS starts up, the driver prepares the parent side according to the request. On the child side, an address for accessing the ring buffer memory area prepared by the parent side is notified from the parent side. It is a figure explaining the structure of a Virtual queue. It is a figure explaining operation of a Virtual queue at the time of data transfer from a guest to a virtual machine. It is a figure explaining operation of a Virtual queue at the time of data transfer from a guest to a virtual machine. It is a figure explaining operation of a Virtual queue at the time of data transfer from a guest to a virtual machine. It is a figure explaining operation of a Virtual queue at the time of data transfer from a guest to a virtual machine. It is a figure explaining operation of a Virtual queue at the time of data transfer from a virtual machine to a guest OS. It is a figure explaining operation of a Virtual queue at the time of data transfer from a virtual machine to a guest OS. It is a figure explaining operation of a Virtual queue at the time of data transfer from a virtual machine to a guest OS. It is a figure explaining operation and notification (when a connection destination is a tap device) of a Virtual queue. It is a figure explaining the external communication system 1 using a TAP device. It is a figure explaining the external communication system 2 using a vhost-net driver. It is a figure explaining the communication between a virtual machine and external processes using vhost-net. It is a figure explaining the new function and composition outline in the virtual channel construction system concerning the present invention. It is a figure explaining the starting sequence of the virtual machine and guest OS in the virtual communication path construction method which concerns on this invention. It is a figure explaining the specific block diagram of the virtual communication path construction system which concerns on this invention. It is a figure explaining the management data in the shared buffer queue management part for transmission / reception in the virtual queue device of the external process. In the example of this figure, there is one transmission buffer queue and one reception buffer queue. Each size is omitted but default 256. It is a figure explaining the control message sequence and format of signaling of the protocol for shared buffer queue expansion. It is a figure explaining the control message reception flowchart of an external process (server side). It is a figure explaining starting of an external process and a state sequence. It is a figure explaining queue operation and notification (when a connection destination is an external process). It is a figure explaining queue operation and notification (when a connection destination is an external process). It is a figure explaining the operation pattern and state transition pattern of a guest OS, a virtual machine, and an external process. It is a figure explaining the connection using basic authentication. It is a figure explaining the connection using digest authentication. It is a figure explaining the connection using SSL authentication. It is a figure explaining the model of the virtual BRAS network node using NFV and SDN to which the present invention is applied.

  Embodiments of the present invention will be described with reference to the accompanying drawings. The embodiments described below are examples of the present invention, and the present invention is not limited to the following embodiments. In the present specification and drawings, the same reference numerals denote the same components.

<Outline of the present invention>
The “virtual communication path construction system and virtual communication path construction method” according to the present invention is a communication path construction system between a guest OS and an external process and a control method thereof. The present invention is directed to adding new functions to communication devices (communication interfaces) respectively included in a virtual machine and an external process (see FIG. 14).

  The present invention directly connects the virtual machine and the external process to a physical machine having a virtual machine and a host OS capable of operating an external process formed outside the virtual machine, and a guest OS operating in the virtual machine. A virtual communication path construction system comprising: a communication path construction means for constructing a virtual communication path to be connected. Then, the communication path construction unit extends the data transfer destination of the shared buffer queue to the external process by a memory operation for the shared buffer queue formed for data transfer between the virtual machine and the guest OS. And a shared buffer queue expansion protocol function for constructing the virtual communication path and realizing a procedure related to communication between the guest OS and the external process.

  By executing a virtual communication path construction program on the physical machine, the virtual machine and the physical machine having a host OS capable of operating an external process formed outside the virtual machine and the virtual machine on the physical machine Realizing a virtual machine formation procedure for forming an external process and a virtual communication path construction procedure for causing a guest OS operating in the virtual machine to construct a virtual communication path for directly connecting the virtual machine and the external process it can. At this time, in the virtual communication path construction procedure, with respect to the shared buffer queue formed for data transfer between the virtual machine and the guest OS, the data transfer destination of the shared buffer queue is transferred to the external process by a memory operation. The virtual communication path is expanded to construct a shared buffer queue extending step for realizing a procedure related to communication between the guest OS and the external process.

  Specifically, the data transfer by the shared buffer queue for data transfer between the guest OS and the virtual machine is extended to the external process that is the communication destination of the virtual machine, and the memory operation of the shared buffer queue between the virtual machine and the external process is performed. Data transmission / reception is realized.

The communication path construction means includes
A connection state detection function for detecting the state of the virtual communication path;
A connection status notification function for notifying the status of the virtual communication path to the processing logic on the guest OS and the external process, respectively;
A reconnection function that periodically reconnects to the communication destination when each of the communication devices is disconnected,
It has further.

The virtual channel construction procedure is:
A connection state detection step for detecting the state of the virtual communication path;
A connection state notification step of notifying the guest OS and the processing logic on the external process, respectively, of the state of the virtual communication path;
A reconnection step of periodically reconnecting to the communication destination when each of the communication devices is disconnected;
It has further.

In the connection using the shared buffer queue, even if the virtual machine and external process are stopped independently for reasons such as failure or maintenance, the operation of the connection partner (virtual machine or external process) is not affected. Each communication device (communication interface) used by the virtual machine and the external process has the following functions (so as not to hang up).
(A) Communication connection establishment procedure, queue operation mode exchange procedure, buffer queue update notification procedure, connection buffer detection protocol function for realizing connection termination procedure (b) Connection state detection function during communication establishment (c) Communication Established connection status notification function Here, the connection status notification function is a function for notifying the interface up status to the inside of the virtual machine or the external process when communication is established, and when communication is disconnected (or done) This is a function to notify the status of interface down.
(D) Reconnect function that periodically connects to the communication destination again in the disconnected state

Further, the present invention can be extended as follows.
・ Connection protocol between external process and virtual machine ・ Other buffer method ・ I / O method that can be realized by shared buffer queue such as file I / O and console I / O other than network

  Specific examples will be described below.

<Example 1>
The first embodiment is premised on the operation of the shared buffer queue defined in the already-described description between the parent side and the child side.

(1) Connection configuration diagram of virtual machine and external process The configuration of the present invention will be described with reference to FIG.
[Configuration 1]
The virtual channel construction system of the present embodiment is
[Connection state management unit 1] 11, [Reception data update notification unit 1] 12, [Reception data buffer queue setting unit 1] 13, [Device operation / feature setting unit 1] 14, [Transmission data buffer queue setting unit 1] 15, a virtual communication device composed of [transmission data update notification unit 1] 16 and [device type registration unit 1] 17 is expressed, and access to the virtual communication device on the guest OS side and sharing created on the guest OS side [Communication device interface unit] 10 for transmitting buffer queue information to the virtual device side;
[Communication device interface unit] 10 [Reception data buffer queue setting unit 1] 13, [Device operation / feature setting unit 1] 14 and [Transmission data buffer queue setting unit 1] 15 [Transmission / reception shared buffer queue manager 1] 20 for managing the type, size, and number of buffer queues for transmission and reception,
[Basic setting processing unit 1] 30 for processing a startup option when the virtual machine is started,
[Connection state notification function unit 1] 41, [Connection state detection function unit 1] 42, [Connection / communication processing basic unit 1] 43, [Shared buffer queue extension protocol processing unit 1] 44 and [Basic setting management unit 1] ] [Communication part (client)] 40 consisting of 45;
[Communication device 1] 100 (referred to as a virtual-net-ipc device) on the virtual machine side having a function of connecting to a connection destination specified by a file descriptor specified by a start option, and [Connection Status management unit 2] 51, [Reception data output unit 2] 52, [Reception data notification unit 2] 53, [Device operation / feature setting unit 2] 54, [Transmission data input unit 2] 55, [Transmission data notification unit] 2] 56 and [device type registration unit 2] 57, which provide a communication interface to an external process,
In the shared buffer queue created by the guest OS comprising the [Reception shared buffer queue processing unit 2] 61, [Transmission / reception shared buffer queue management unit 2] 62 and [Transmission shared buffer queue processing unit 2] 63 A shared buffer queue operation unit 60 that allows memory access and operation of the shared buffer queue;
[Basic setting processing unit 2] 70 for processing a start option when starting an external process;
[Connection state notification function unit 2] 81, [Connection state detection function unit 2] 82, [Connection / communication processing basic unit 2] 83, [Shared buffer queue extension protocol processing unit 2] 84, and [Basic setting management unit 2] ] [Communication unit (server)] 80 consisting of 85;
[Communication device] 200 on the external process side having a function of connecting to the connection destination specified by the file descriptor specified by the activation option.
Consists of.

[Configuration 2]
[Transmission / Reception Shared Buffer Queue Management Unit 1] 20 is connected to the guest OS by [Reception Data Buffer Queue Setting Unit 1] 13, [Device Operation / Feature Setting Unit 1] 14, and [Transmission Data Buffer Queue Setting Unit 1]. By providing 15, the shared buffer queue information can be acquired from the guest OS and the information can be managed.

[Configuration 3]
[Communication device interface unit] 10 provides [Connection state management unit 1] 11 to the guest OS, [Connection / communication processing basic unit 1] 43, [Connection state detection function unit 1] 42, and [Connection state notification function] Unit 1] 41 cooperates with the guest OS to enable the interface state to be recognized as on / off.

[Configuration 4]
[Transmission / Reception Shared Buffer Queue Manager 1] 20 and [Shared Buffer Queue Extension Protocol Processor 1] 44 cooperate to provide an external process with shared buffer queue information, an initialization sequence, a setting sequence, and an update. A protocol capable of executing a notification sequence and an end sequence is provided. Each sequence will be described later.

[Configuration 5]
When the operation of the [communication device interface unit] 10 is interrupted, the [reception data update notification unit 1] 12, the [transmission data update notification unit 1] 16, and the [shared buffer queue extension protocol processing unit 1] 4420 are linked. Then, the buffer queue contents are notified to the external process according to the update notification sequence.

[Configuration 6]
When the operation of the [communication device interface unit] 10 is no interrupt (polling mode), the [communication device 1] 100 does not use the [reception data update notification unit 1] 12 and the [transmission data update notification unit 1] 16. Furthermore, when the device driver side of the virtual machine operates in the polling mode, transfer data (both transmission and reception) can be exchanged with an external process.

[Configuration 7]
[Transmission / Reception Shared Buffer Queue Management Unit 1] maps the type / number / size information of the shared buffer queue to be managed to the version number and shares it between the virtual machine and the external process based on the version information It is possible to share buffer queue configuration information.

[Configuration 8]
The [device type registration unit 1] 17 can register [basic setting processing unit 1] that processes various option information when the virtual machine is activated and device information corresponding to the shared buffer queue type from the information. [Basic setting management unit 1] 4530 can manage all the option information.

[Configuration 10]
The [communication device 1] 100 sends the data transfer mode (with interrupt / without interrupt (polling mode)) and device feature information acquired from the virtual machine through the [transmit / receive shared buffer queue manager 2] 62 [ By providing the information to the device operation / feature setting unit 2] 54, the operation mode and feature information of the shared buffer queue are notified to the external process. As a result, the external process can recognize the virtual communication path between the guest OS and the external process.

[Configuration 11]
In the case of an operation with an interrupt, when receiving transfer data from the virtual machine, the [shared buffer queue expansion protocol processing unit 2] 84 processes the update notification notified in the update notification sequence, and [reception shared buffer] The queue processing unit 2] 61 transfers the transfer data to the [Reception interface], and notifies the [Reception data notification unit 2] 53 that the transfer data exists.

[Configuration 12]
In the case of an operation without interruption (polling mode), when receiving transfer data from the virtual machine, [Reception Shared Buffer Queue Processing Unit 2] 61 does not use [Reception Data Notification Unit 2] 53, [Received data output unit 2] The shared buffer queue processing is performed in accordance with the data acquisition request from 52, and the transfer data is received in the polling mode.

[Configuration 13]
When the transfer data is transmitted from the external process to the virtual machine in the operation with the interrupt, the [transmission data input unit 2] 55 receives the transfer data, and the [transmission shared buffer queue processing unit 2] 63 receives the shared buffer queue. After executing the processing, the [shared buffer queue extension protocol processing unit 2] 84 transmits an update notification to the virtual machine side, and if a transmission data reception completion notification is required, it passes through the [transmission data notification unit 2] 56. , Notify the processing logic.

[Configuration 14]
When the transfer data from the virtual machine is transmitted from an external process in the case of an operation without interruption (polling mode), the [transmission data input unit 2] is executed from the processing logic without using the [transmission data notification unit 2] 56. [Transmission shared buffer queue processing unit 2] 63 performs shared buffer queue processing on the transfer data input to 55, and [Shared buffer queue extension protocol processing unit 2] 84 transfers the transfer data to the virtual machine in the polling mode. To the side.

[Configuration 15]
In the external process, the [connection / communication processing basic unit 2] 83, the [connection state detection function unit 2] 82, and the [connection state notification function unit 2] 81 cooperate to provide an interface state to the processing logic of the external process. It has a function that can recognize the on / off state.

[Configuration 16]
[Transmission / Reception Shared Buffer Queue Management Unit 2] 62 and [Shared Buffer Queue Extension Protocol Processing Unit 2] 84 cooperate with each other to virtually perform the initialization sequence, the setting sequence, the update notification sequence, and the end sequence. A protocol capable of acquiring shared buffer queue information provided from a machine is provided.

[Configuration 17]
[Transmission / Reception Shared Buffer Queue Management Unit 2] 62 manages the version information of the shared buffer queue received from the virtual machine by decomposing and mapping it into the type / number / size information of the buffer queue, and managing the version information. The shared buffer queue configuration information is shared between the virtual machine and the external process.

[Configuration 18]
[Basic setting processing unit 2] 70 processes various option information when the external process is activated. [Device type registration unit 2] 57 can register device information corresponding to the shared buffer queue type from the information. [Basic setting management unit 2] 85 can manage all option information.

  Next, the operation of the virtual communication path construction system will be described with reference to the flowchart of FIG. 15 and the description of each functional unit of FIG.

(2) Method for Connecting Virtual Machine and External Process The present invention provides a virtual-net-ipc device as a communication device as means for realizing data transfer by sharing a shared buffer queue between a virtual machine and an external process. And the virtual queue device are connected using IPC (Inter Process Communication).

  In IPC, there are a wide variety of mounting methods. In the first embodiment, a socket (or a UNIX (registered trademark) domain socket) supported by many OSs is used. A socket establishes a connection using a file descriptor.

The virtual machine side operates as a client. As a virtual machine, the virtual machine device is connected to the external process as a virtual network device identifier as a virtual network device identifier, a file descriptor used for connection to the external process (here, socketpath), and the external process. And a reconnection interval (in this case, “interval”), and a combination of four arguments of node IDs for uniquely recognizing a combination of a virtual machine and an external process (S101 in FIG. 15). The client node name is optional.
(Reference 2) [Virtual machine startup arguments]

  After startup, the [basic setting processing unit 1] checks both the identifier of the virtual-net device and the socket path descriptor (file path). If both are set, [device type registration unit 1] 17 Is registered as a virtual-net device. On the other hand, it is registered in [basic setting management unit 1] 45 as a virtual-net-ipc device having an external connection destination as a socket (S102 in FIG. 15). All activation options are registered in the [basic setting management unit 1] 45.

  If the guest OS is not activated, the guest OS is activated (S121 in FIG. 15). The guest OS secures an area for the shared buffer queue in the physical machine memory (S122 in FIG. 15). The guest OS exchanges the information of the shared buffer queue and the function (feature) of the communication device with the virtual machine (S123 in FIG. 15), and completes the activation (S124 in FIG. 15).

  After the virtual machine is started, until the connection with the external process is established and the setting described later is correctly completed, the interface remains down in the [connection state management unit 1] 11 that notifies the guest OS of the state of the virtual device. It is.

  The virtual machine is registered as a virtual-net device in the [device type registration unit 1] 17 at startup, so that the guest OS recognizes it as a virtual-net device. The corresponding virtual-net driver is activated (but operates as a virtual-net-ipc device as a virtual machine communication device) (S102 in FIG. 15)).

  After registration in [device type registration unit 1] 17 is completed, the file path indicated by the socket path set in [basic setting management unit 1] 45 is set in [connection / communication processing basic unit 1] 43, and the connection destination is set. By registering (S103 in FIG. 15), connection is attempted (S104 in FIG. 15).

  When the external process cannot be connected (“No” in S105 in FIG. 15), it waits for the time specified by the virtual machine activation option (S114 in FIG. 15) and tries to connect again (S104 in FIG. 15).

  If the external process is in a connectable state (“Yes” in S105 in FIG. 15), the connection is established by the [connection / communication processing basic unit 1] 43 via a direct socket according to socketpath. Thereafter, with the external process, the sequence as shown in FIG. 18 is executed according to the phase (S106 in FIG. 15). In the message exchange between the virtual-net-ipc device of the virtual machine and the virtual queue device of the external process, the control message format shown in FIG. 18 is used.

  The [shared buffer queue extension protocol processing unit 1] 44 receives the node ID and client node name (option) from the [basic setting management unit 1] 45, and the buffer queue from the [transmission / reception shared buffer queue management unit 1]. An initialization message is configured from the version number indicating the configuration of the above, and is transmitted from the virtual machine side to the external process side via the [connection / communication processing basic unit 1] 43 (S106 in FIG. 15)).

Hereinafter, the virtual-net-ipc device on the virtual machine side is also called a client, and the virtual queue device on the external process side is also called a server.
(Reference 3) [Initialization message]

  The server makes a transition to a state in which a control message (initialization message) from the client can be received, and starts receiving the control message (S201 and S202 in FIG. 19).

  On the server side, like the client, the control message is processed by the [shared buffer queue extension protocol processing unit 2] 84 via the [connection / communication processing basic unit 2] 83, and the message type is the initialization message. The version number and the node ID are confirmed (S203 in FIG. 19).

  As will be described later, since the node ID is managed by the [basic setting management unit 2] 85 via the [basic setting processing unit 2] at the time of startup, the external process also has the node ID possessed by the virtual queue device of the external process. The supported version numbers are compared (S107 in FIG. 15 and S203 in FIG. 19).

  If the two information of the node ID and version number match (“Yes” in S107 in FIG. 15 and “Yes” in S203 in FIG. 19), the state transits to the setting message and end message reception state (S108 in FIG. 15). And S204 in FIG. 19). On the other hand, if the two pieces of information of the node ID and the version number do not match (“No” in S107 of FIG. 15, “No” in S203 of FIG. 19), the connection is not established (S211 of FIG. 19). The side transitions to the reconnection state (S114 in FIG. 15). For reconnection, confirm the cinterval value managed by the [basic setting management unit 1] 45, and repeatedly try reconnection at the time interval of the value (if cinterval is set to 0 or a negative value, reconnection is performed. Does not repeat).

  When the initialization message processing ends normally (S108 in FIG. 15), the virtual machine side proceeds to a phase for sending a setting message. Further, the external process side proceeds to a phase of receiving a control message that is a setting message.

  In the setting message, in addition to the information used in the initialization message, address information for accessing the shared buffer queue provided from the guest OS is required. Therefore, it is confirmed whether or not the guest OS is activated (S109 in FIG. 15). Specifically, the [shared buffer queue extension protocol processing unit 1] 44 sets the type, head address, number, and size of the shared buffer queue set by the guest OS in the [transmission / reception shared buffer queue management unit 1]. Queries whether is set.

If the item is not set (“No” in S109 in FIG. 15), it is determined that the guest OS is not activated, and the shared buffer queue of the transmission / reception shared buffer queue management unit 1 is determined. Wait for the setting completion notification (S110, S110 in FIG. 15). If the setting of the item has been completed (“Yes” in S109 in FIG. 15), the shared buffer queue start address information from the guest OS can be acquired. The information is added to the setting message, and the setting message is transmitted to the external process (server side) with the following contents (S112 in FIG. 15).
(Reference 4) [Setting message]

  Information on the number and size of the reception buffer queue is registered from the guest OS side via the [Reception data buffer queue setting unit 1] 13 from the guest OS side. [Device operation / feature setting unit 1] 14 through the device feature and device operation mode (with or without interruption), and [Transmission data buffer queue setting unit 1] 15 through the number and size of transmission buffer queues. , Respectively.

  When the server receives the setting message (S205 in FIG. 19), the [connection / communication processing basic unit 2] 83 passes through the [shared buffer queue extension protocol processing unit 2] 84 via the [connection / communication processing basic unit 2] 83 in the same manner as the initialization message. The version number, node ID, and message type are confirmed (S206 and S207 in FIG. 19).

  If the node ID and the version number of the received control message do not match (“No” in S206 of FIG. 19), the connection is disconnected (S211 of FIG. 19). If the node ID and the version number of the received control message match (“Yes” in S206 in FIG. 19), it is confirmed whether or not the control message is a setting message (S207 in FIG. 19).

  When the control message is a setting message (“Yes” in S207 in FIG. 19), the address information of the shared buffer queue, the feature information of the virtual-net-ipc device, and the operation mode are confirmed (S209 in FIG. 19). If the value is set and the interrupt is enabled or disabled for the operation mode, the setting is completed (S210 in FIG. 19).

  These pieces of information are managed by the [transmission / reception shared buffer queue management unit 2] 62 on the server side. At this time, a buffer queue type (virtual queue) corresponding to the version number, a buffer queue head address, the number and size information of transmission buffer queues, and the number and size information of reception buffer queues are decomposed and registered (FIG. 17). This version information will be described later in (3).

  When the message type is not a setting message and is not an end message (“No” in S207 of FIG. 19, “No” in S208), address information of the shared buffer queue, feature information of the virtual-net-ipc device, and operation mode Is not included (“No” in S209 of FIG. 19), the reception of a setting message is awaited (S204 of FIG. 19). If the message type is an end message in S208 of FIG. 19, the connection is disconnected.

  Using these pieces of information, the [sending / receiving shared buffer queue manager 2] 62 uses memory mapping to access the shared buffer queue of the guest OS on the virtual machine, and internally manages the shared buffer queue. As transmission variables, address information is mapped to transmission buffer queue variables and reception buffer queue variables, respectively (FIG. 17).

  The virtual machine side receives the response of the result of the setting message (FIGS. 18 and 19), and the [shared buffer queue extension protocol processing unit 1] 44 [connection state management function] 1 via the [connection state notification function unit 1] 41 Part 1] 11 to register the link-up state. Thereby, the guest OS recognizes the link-up of the communication device (virtio-net-ipc device) (S113 in FIG. 15). Note that when checking the link-up state (S125 in FIG. 15), the guest OS waits until the virtual machine performs link-up registration if there is no link-up registration (S127 and S128 in FIG. 15).

  Similarly, after the setting is completed on the external process side, the [shared buffer queue expansion protocol processing unit 2] 84 registers the link-up state via the [connection state notification function unit 2] 81. As a result, the state of the communication device (virtqueue device) is switched from the link-down state to the link-up state, and the processing logic of the external process is switched to a state where data communication is possible. The setting on the external process side will be described in (7) described later.

(3) Interpretation of version number The version number is expressed by a combination of “buffer queue type”, “number of queues”, and “each queue size”. The number of queues is the same for both transmission and reception, and the queue sizes are also the same.

For example, assume that the queue type is 4 bits, the queue number is 12 bits, the queue size is 16 bits, and 4 bits of “0001” are assigned to the vital queue type. In this case, as shown in FIG. 17, when the default virtue queue is configured, since there is one transmission / reception queue and the size is 256, the version number is expressed as follows.
(Reference 5) [Version number]

(4) Message Type Dependent Data Field In the control message format of FIG. 18, the message type dependent data field is used with the following values in the setting message and the update notification message. The feature information will be described later in (5).
(Reference 6) [Message type dependent data field]

(5) Feature information of virtual-net-ipc device and consensus process of operation mode Feature information is supported by functions such as checksum offload supported by virtual-net driver of guest OS and virtual-net-ipc device. Functions are negotiated when the guest OS is started, and what is agreed upon is established as final feature information. This feature information is the same as the spec of Virio, and is therefore omitted (see Non-Patent Document 1 for details).

  This feature information agreement is acceptable as long as the guest OS, virtual machine, and external process can be executed at the same time. However, since the agreement between the guest OS and the virtual machine takes precedence, the agreement between the guest OS and the virtual machine is initially agreed. The three-party agreement process is skipped by converting the converted information into version information and unilaterally forcing it to an external process. Thus, it is assumed that the external process side supports all features.

  On the other hand, the operation mode can be set to enable / disable the avail ring update notification from the parent side to the child side and enable / disable the used ring update notification from the child side to the parent side. When the update notification is off, it indicates that the other party operates in the polling mode and collects transfer data spontaneously without an update notification. The virtual machine's virtual-net-ipc device, the guest OS's virtual-net driver, and the external process's virtual queue device support both modes. This update notification occurs in the two sections of guest OS and virtual machine, virtual machine and external process, but the virtual-net-ipc device, the virtual-net driver, and the virtual queue device are compatible with both modes. Setting is possible. However, in the present invention, the operation mode negotiated and agreed between the guest OS and the virtual machine is directly transmitted to the external process. That is, the same operation is performed in both sections.

(6) Method for Disconnecting Virtual Machine from External Process In (2) above, after the connection between the virtual machine and the external process, [Shared Buffer Queue Extension Protocol Processing Unit 1] 44 on the virtual machine side or [ Disconnection is sent from the shared buffer queue extension protocol processing unit 2] 84 to the other party via the [connection / communication processing basic unit 1] 43 and the [connection / communication processing basic unit 2] 83, respectively. Realize. At this time, the external process confirms the version number and the node ID in the same manner as the initialization message and setting message in FIG. 19 (S206 in FIG. 19). If they match, the connection is terminated (S207 and S208 in FIG. 19, S115 in FIG. 15, and S312 in FIG. 20).

  When the virtual machine side transitions to the disconnected state, if the virtual machine side is operating, connection is attempted again (S104 in FIG. 15). However, if the virtual machine itself is terminated, naturally reconnection is not performed.

  The same applies to the external process side. If the external process is operating, the connection wait state is entered (S303 in FIG. 20), but if the external process itself is terminated, the reconnection wait state is not entered, and the process is terminated.

(7) External Process Startup Sequence The external process starts up using a virtualqueue device as an interface as a communication device (FIG. 16).

  The virtual queue device has the operation function of the shared buffer queue on the child side as shown in FIG. 16, [Reception Shared Buffer Queue Processing Unit 2] 61, [Transmission / Reception Shared Buffer Queue Management Unit 2] 62, and [Transmission Shared]. The buffer queue processing unit 2] 63 has an operation mode that supports the interrupt mode and the polling mode as described above.

  The startup sequence of the external process is as shown in FIG. The activation of the external process is independent of the virtual machine or guest OS. The external process completes the activation in accordance with the activation instruction (S310, S311 in FIG. 20) and starts linkup with the communication device.

When an external process is activated, a virtual queue device identifier and socketpath as a connection destination are passed as in the case of activation of a virtual machine, and further, a node ID for recognizing a connection pair is passed (S301 in FIG. 20). The server node name is optional.
(Reference 7) [External process startup options]

  When the external process is designated with these startup option information, the [basic setting processing unit 2] described on the external process side in FIG. 16 identifies these parameters and registers them in the [basic setting management unit 2] 85. Then, the device type is registered in [device type registration unit 2] 57 so that the device type can be recognized from the processing logic on the external process side (S302 in FIG. 20).

  Next, [basic setting processing unit 2] sets the file path indicated by socketpath in [connection / communication processing basic unit 2] 83, and [connection / communication processing basic unit 2] 83 waits for a connection from the virtual machine side. It starts in a state (S303 in FIG. 20). In this state, the interface remains down in the [connection state management unit 2] 51 that can be confirmed by the processing logic of the external process.

  As shown in S304 of FIG. 20, when there is a connection from the virtual machine, the [shared buffer queue extension protocol processing unit 2] 84 identifies the initial message via the [connection / communication processing basic unit 2] 83, and the message It is confirmed that the type is an initialization message and the node ID is the same as the node ID managed by the [basic setting management unit 2] 85 and is a supported version (S305 in FIG. 20).

  If the condition is not satisfied, the server side transitions to a reconnection state (“No” in S305 of FIG. 20). If the condition is satisfied, the initialization message process ends normally and the connection is established (S306 in FIG. 20). The virtual machine side shifts to a phase for sending a setting message, and the external process shifts to a setting message reception phase (S204 in FIG. 19).

  Thereafter, it waits for a setting message from the virtual machine side (S307 and S308 in FIG. 20). Similarly, in the setting message, the message type, the node ID, and the version number are confirmed. If they match, the version number, the shared buffer queue address information, and the feature information of the virtual-net-ipc device are included in the setting message. When the operation mode is confirmed, a value is set, and the interrupt is enabled or disabled for the operation mode, the setting is completed (S210 in FIG. 19 and S309 in FIG. 20). These setting contents are set / registered from [Shared Buffer Queue Extension Protocol Processing Unit 2] 84 to [Transmission / Reception Shared Buffer Queue Management Unit 2] 62.

  Thereafter, the [transmission / reception shared buffer queue management unit 2] 62 confirms the registered contents, and manages the shared buffer queue as shown in FIG. 17 from the version number and the address information of the shared buffer queue. Create with various variables. Since this content has already been described in (2) above, a detailed description is omitted.

  When the shared buffer queue management information is created in [transmission / reception shared buffer queue management unit 2] 62, it is linked up to [connection state management unit 2] 51 through [connection state notification function unit 2] 81 Register the state.

  In response, the external process recognizes that the communication device has become available.

(8) Data transmission / reception from the guest OS to the external process after connecting the virtual machine to the external process (Operation of shared buffer queue)
Since the operation of the shared buffer queue is based on “virtio”, it is exactly the same as that described in the <Operation of Virtual Queue> in the prior art. According to the present invention, it can be considered that the implementer on the child side of the queue operation has switched from the communication device on the virtual machine to the virtualqueue device on the external process illustrated in FIG.

  However, since the shared buffer queue update notification when the operation mode is interrupted passes through the socket between the virtual-net-ipc device and the virtualqueue device, one procedure is added to the normal operation of the shared buffer queue. In other words, when the interrupt is valid in the operation mode, as shown in FIG. 18, a shared buffer queue update notification is sent between the virtual machine side and the external process side (FIG. 21).

  On the other hand, when the operation mode is disabled, the update notification shown in FIG. 18 does not occur. The virtual-net-ipc device and the virtualqueue device operate in a polling mode, and when there is a queue update, the transfer data of the queue that has been updated spontaneously is collected (FIG. 22).

<Processing in interrupt mode>
(When sending from a guest OS to an external process through a virtual machine)
This will be described with reference to FIGS. 16 and 21. FIG.

1. 1. The descriptor is loaded on avail. The guest OS puts the transmission data on the avail and puts it in the descriptor. Notification to virtual machine The guest OS notifies the communication device of the virtual machine. That is, the [shared buffer queue expansion protocol processing unit 1] 44 of the virtual-net-ipc device grasps that there is an update through the [transmission data update notification unit 1] 16.
3. Notification to external process The virtual-net-ipc device notifies the external process. That is, the [shared buffer queue expansion protocol processing unit 1] 44 transmits an update notification message for the availability of the transmission queue to the virtual queue device of the external process.
4). The external process receives the update notification, confirms the availability, and collects the descriptor. (A) In the [shared buffer queue extension protocol processing unit 2] 84 of the virtualqueue device, it is determined that the reception queue is updated in the update message. know.
(B) The [shared buffer queue expansion protocol processing unit 2] 84 notifies the [reception shared buffer queue processing unit 2] 61 of the update notification.
(C) [Reception shared buffer queue processing unit 2] 61 collects the updated descriptor and notifies [Reception data notification unit 2] 53 of the reception.
(D) Data can be acquired from the processing logic through the [Received data output unit 2] 52. The collected descriptor is stacked in the “used shared buffer queue processing unit 2” 61 and informs the “shared buffer queue expansion protocol processing unit 2” 84 that the descriptor that has been used is stacked.
6). Notification of used update [Shared buffer queue expansion protocol processing unit 2] 84 transmits an update message to the virtual-net-ipc device on the virtual machine side.
7). Notification of used update to guest OS [Shared buffer queue extension protocol processing unit 1] 44 of the virtual-net-ipc device receives the update message and notifies [transmission data update notification unit 1] 16 of the used update.
8). Collecting descriptors loaded by external processes from used The guest OS receives an update notification through [transmission data update notification unit 1] 16 and collects descriptors loaded by external processes from used.

(When sending from an external process to the guest OS)
This will be described with reference to FIGS.

1. (a) In the initial state, the virtual machine side prepares a descriptor for an external process to pack transmission data. That is, the guest OS uses the [Reception Data Buffer Queue Setting Unit 1] 13 and the [Transmission Data Buffer Queue Setting Unit 1] 15 to [Transmission / Reception Shared Buffer Queue Management Unit 1] of the virtual-net-ipc device. It has been completed before notifying the number and size information of the shared buffer queue.
(B) Hereinafter, after the initial state, the descriptors collected in the procedure 9 are to be stacked on the avail.
2. Notification to virtual machine (a) Does not occur in the initial state.
(B) After the initial state, the guest OS notifies the [shared buffer queue extension protocol processing unit 1] 44 of the update through the [received data update notification unit 1] 12.
3. Notification to External Process [Shared Buffer Queue Extension Protocol Processing Unit 1] 44 transmits an update notification message for the availability of the reception queue to the virtual queue device of the external process.
4). Collect the descriptor that can be used from avail. (a) Send transmission data from the processing logic of the external process to [transmission data input unit 2] 55 of [transmission interface].
(B) [Transmission shared buffer queue processing unit 2] 63 receives queue information used by the external process for transmission from [Transmission / reception shared buffer queue management unit 2] 62 (reception queue when viewed from the virtual machine). And prepare a descriptor.
5. The transfer data is accumulated in the descriptor [the transmission shared buffer queue processing unit 2] 63 packs the transfer data in the descriptor.
6). The collected descriptor is stacked in the “used shared buffer queue processing unit 2” 63 and informs the “shared buffer queue expansion protocol processing unit 2” 84 that the used descriptor has been loaded.
7). Notification of used update [Shared buffer queue expansion protocol processing unit 2] 84 transmits an update message to the virtual-net-ipc device on the virtual machine side.
8). Notification of used update to guest OS.
The [shared buffer queue expansion protocol processing unit 1] 44 of the virtual-net-ipc device receives the update message and notifies the [reception data update notification unit 1] 12 of the used update.
9. Collecting descriptors loaded by external processes from used (a) The guest OS receives an update notification by [Received data update notification unit 1] 12 and extracts the descriptors loaded by external processes from used.
(B) Since the descriptor contains transfer data, the data is acquired and the descriptor is released (collected).

<Processing in polling mode (no interrupt)>
Since the guest OS and the external process each operate in the polling mode, the update message is not relayed via the virtual-net-ipc device and the virtualqueue device.

(When sending from a guest OS to an external process through a virtual machine)
This will be described with reference to FIGS. 16 and 22.

1. 1. The descriptor is loaded on avail. The guest OS puts the transmission data on the avail and puts it in the descriptor. Confirm avail and collect descriptor [Reception shared buffer queue processing unit 2] 61 confirms the update of avail in the polling mode. When there is an update, the descriptor is collected and held so that the transfer data can be acquired through the [Received data output unit 2] 52.
3. The collected descriptor is stacked in the “used shared buffer queue processing unit 2” 61 and the descriptor collected in the “used” shared buffer queue expansion protocol processing unit 2 84 is stacked.
4). Collecting descriptors loaded by external process from used Guest OS checks the status of used in polling mode, and if used is updated, collects descriptors loaded by external process.

(When sending from an external process to the guest OS)
This will be described with reference to FIGS. 16 and 22.
1. (a) In the initial state, the virtual machine side prepares a descriptor for an external process to pack transmission data. That is, the guest OS uses the [Reception Data Buffer Queue Setting Unit 1] 13 and the [Transmission Data Buffer Queue Setting Unit 1] 15 to [Transmission / Reception Shared Buffer Queue Management Unit 1] of the virtual-net-ipc device. It has been completed before notifying the number and size information of the shared buffer queue.
(B) Hereinafter, after the initial state, the descriptor collected in the procedure 5 is to be stacked on the avail.
2. Collect the descriptor that can be used from avail. (a) Send transmission data from the processing logic of the external process to [transmission data input unit 2] 55 of [transmission interface].
(B) [Transmission shared buffer queue processing unit 2] 63 receives queue information used by the external process for transmission from [Transmission / reception shared buffer queue management unit 2] 62 (reception queue when viewed from the virtual machine). And prepare a descriptor.
3. The transfer data is accumulated in the descriptor [the shared buffer queue manager for transmission 2] packs the transfer data in the descriptor.
4). The collected descriptor is stacked in the “used shared buffer queue processing unit 2” 63 and the recovered descriptor is stacked in the “used”.
5. Collecting descriptors loaded by external process from used (a) Guest OS operates in polling mode, confirms used without update notification, and if updated, fetches descriptor loaded by external process.
(B) Since the descriptor contains transfer data, the data is acquired and the descriptor is released (collected).

(9) Virtual Machine and Guest OS Startup Sequence As shown in FIG. 15, when the virtual machine is started, the guest OS is started, and the virtual-net driver is started, the feature information is virtual-net-ipc. After negotiating with the device and setting the operation mode to each other, the guest OS creates a shared buffer queue for transmission and reception, and the number, size, and top address information of the shared buffer queue are stored in the virtual-net-ipc device. Notice.

  As described in the above (2), the notification is made by the guest OS being an interface with the virtual-net-ipc device, [Reception data buffer queue setting unit 1] 13, [Device operation / feature setting unit 1] 14, This is realized by notifying and setting the [transmission / reception shared buffer queue management unit 1] through the [transmission data buffer queue setting unit 1] 15.

  As described above, the operation and sequence when a normal operation is assumed have been described. However, as shown in FIG. 23, it is necessary to have a notification mechanism in which external processes, virtual machines, and guest OSs do not cause problems in their operation independently in the state transition patterns (D1 to D9). The method will be described in the following sections.

-State transition pattern (D1)
The state transition pattern (D1) deals with state transitions in which only the virtual machine is started and stopped. In this pattern, it is necessary to consider abnormal termination of the virtual machine, but there is no external process or guest OS to connect to, so there is no influence. Therefore, in this case, it is not necessary to consider the influence on the operation.

-State transition pattern (D2)
In this case, there are two state transitions when the virtual machine is activated and the guest OS is stopped, and when the virtual machine is activated and the guest OS is activated. In this state, it is necessary to take measures when the guest OS is abnormally terminated. Specifically, this is a case where the memory area of the shared buffer queue secured by the guest OS is abnormally terminated without being released. In this case, the memory area remains without being released, but this problem is a problem common to all the virtual devices realized by the shared shared buffer queue including the existing virtual-net device. Further, since the external process is not started, there is no need to consider from the viewpoint of affecting the operation.

-State transition pattern (D3)
In this pattern, the virtual machine and the guest OS are running, and the external process transitions between a stopped state and an operating state. In this case, a case where the external process is abnormally terminated is handled. In this case, since the IPC is used, the virtual machine side can detect the IPC end notification, and the end process can be performed on the virtual machine side. In other words, (i) the termination is detected on the virtual machine side, (ii) the link down is notified from the virtual machine side to the guest OS, and (iii) the guest OS recognizes the link down, so that the guest OS is affected by an external process. It can be handled as normal link-down processing. As another problem, there remains a problem that the shared buffer queue is not initialized when the external process ends abnormally. This is a problem common to all the Vio devices.

・ State transition pattern (D4)
In this pattern, the virtual machine and guest OS are stopped, and only the abnormal termination of the external process is targeted. In this state, abnormal termination on the external process side has no effect because the other party does not exist.

・ State transition pattern (D5)
In this pattern, a case will be described in which a virtual machine is abnormally terminated with respect to a state transition in which a virtual machine is started and stopped while an external process is started and a virtual queue device is in a connection waiting state as a server. If the virtual machine terminates abnormally, the connection between the virtual queue device of the external process and the virtual-net-ipc device on the virtual machine side is simply disconnected, and it is before the information of the shared buffer queue is exchanged. Since the virtual queue device of the external process enters the waiting state again after the termination, the abnormal termination operation of the virtual machine does not particularly affect the operation of the external process.

-State transition pattern (D6)
In this pattern, a case will be described in which the guest OS is abnormally terminated while the external process and the virtual machine are activated and the guest OS is activated and terminated. If the guest OS provided information about the shared buffer queue secured by the guest OS to the virtual-net-ipc device on the virtual machine side before abnormal termination, the guest OS is not released even if the memory area used by the shared buffer queue is not released. Will end abnormally, and the external process will write to the shared buffer queue without knowing the abnormal end. This problem is common to all the virtual devices implemented with the shared buffer queue of the virtual including the existing virtual-net device.

State transition pattern (D7)
This pattern deals with a case where an external process transitions between a stopped state and an activated state in a state where only the virtual machine is activated (a state in which the virtual-net-ipc device is repeatedly connected). In this case, the connection by the IPC has only been completed on the external process side and the virtual machine side, and the information on the shared buffer queue has not been exchanged. The machine side only transitions to the reconnection state again, and does not affect the state of the virtual machine.

・ State transition pattern (D8)
In this pattern, a case where both the virtual machine and the guest OS are activated and abnormally ends is handled. In this state, the external process to be affected is not started, so it naturally does not affect the operation. Therefore, it is not necessary to consider the influence of operation in this state transition.

-State transition pattern (D9)
This pattern handles a case where the virtual machine and the guest OS are abnormally terminated at the same time while all of the virtual machine, the guest OS, and the external process are activated. In this case, since the virtual-net-ipc device of the virtual machine and the virtual queue device of the external process are connected by IPC, the external process side can detect abnormal termination and can detect and stop the shared buffer queue operation. Therefore, it is possible to notify the external process side of the status change normally as a link down notification to the external process. Thereby, it is possible to appropriately process even in the abnormal end.

-Other state transitions In the case where all of the virtual machines, the guest OS, and the external processes are operating abnormally, all the operations are terminated, so that no cases that affect each other occur. Therefore, there is no need to consider other state transitions.

<Example 2>
In the first embodiment, the connection using the IPC using the Unix domain socket is taken up. In IPC, there are pipes, message queues, and INET sockets as IPC methods by specifying file paths in addition to Unix domain sockets. In the present invention, connection methods can be switched by setting the connection type in the start option. is there.

  As described above, the connection means differs depending on each of these mounting methods. However, after establishing the connection using the specified connection means, the connection means relates to the shared buffer queue exchanged between the virtual machine including the initialization message and the external process. All procedures include the control message format and sequence (FIG. 18), and are exactly the same as those described in the first embodiment.

  However, since the options given at the time of activation differ depending on the respective connection means, only the parts different from the first embodiment in the second embodiment are described as follows (the procedure for the other means is the same as the first embodiment). Therefore, it is omitted.)

外部プロセス側も同様のファイル記述子を指定することで接続できるようにする。
（参９）［外部プロセスの起動オプション］

それ以外のオプションについては実施例１と同じである。 <Connecting means: pipe>
When a pipe is used as a connection means, the activation option on the virtual machine side is activated by designating a file descriptor as fifopath instead of socketpath as follows.
(Reference 8) [Virtual machine startup arguments]

The external process side can be connected by specifying the same file descriptor.
(Reference 9) [External process startup options]

Other options are the same as those in the first embodiment.

外部プロセス側も同様のファイル記述子を指定することで接続できるようにする。
（参１１）［外部プロセスの起動オプション］

それ以外のオプションについては実施例１と同じである。 <Connection means: Message queue>
When a message queue is used as a connection means, the activation option on the virtual machine side is activated by designating a file descriptor as msgqpath instead of socketpath as follows.
(Reference 10) [Virtual machine startup arguments]

The external process side can be connected by specifying the same file descriptor.
(Reference 11) [External process startup options]

Other options are the same as those in the first embodiment.

外部プロセス側も同様のファイル記述子を指定することで接続できるようにする。
（参１３）［外部プロセスの起動オプション］

それ以外のオプションについては実施例１と同じである。 <Connection: INET socket>
When the INET socket is used as a connection means, the activation option on the virtual machine side is activated by specifying an IP address and a port number instead of a socket path as follows. At this time, TCP or UDP is designated as the layer 4 protocol.
(Ref 12) [Virtual machine startup arguments]

The external process side can be connected by specifying the same file descriptor.
(Reference 13) [External process startup options]

Other options are the same as those in the first embodiment.

<Example 3>
In the first embodiment, the method of extending the shared buffer queue of the guest OS from the virtual machine to the external process in the same physical host has been described. In IPC, it is possible to apply a case where one-to-one connection is made by combining secure connection methods instead of sockets. A connection method using basic authentication, password authentication, or SSL (Secure Sockets Layer) can be applied. As a result, the authentication function between the virtual machine and the external process can be realized by common key or public key authentication, and the message content to be exchanged can be encrypted, and the shared buffer queue can be operated securely. Become.

(Case using basic authentication)
In the case of using the basic authentication, in the first embodiment, the user / password is specified instead of the node ID as the authentication information for external process connection as an option when starting the virtual machine. These users / passwords are managed by [basic setting management unit 1] 45 in FIG. On the other hand, the user / password information for permitting authentication on the external process side is managed by the [basic setting management unit 2] 85 in FIG.

  In this case, these options are exchanged with the external process before the initialization message, and when the basic authentication ends normally, the process proceeds to the initialization phase. The state transition until the connection between the virtual machine and the external process is established is as shown in FIG. In FIG. 24, various message formats of authentication request response, user / password, and authentication OK in the basic authentication phase are in accordance with FIG. 18, and authentication request response, user / password, and authentication OK for message type and basic authentication, respectively. Is described and messages are exchanged. Other overall state transitions and the like are the same as in the first embodiment, and are therefore omitted.

(Digest authentication)
In the case of using digest authentication, the “user / password” portion of basic authentication is replaced with a digest (FIG. 25). Various message formats follow FIG. 18 as in the basic authentication. In addition, all other state transitions and the like are the same as in the first embodiment, and are therefore omitted.

(SSL authentication)
In the case of using SSL authentication, the client side has a certificate for server authentication, and designates the file path of the server certificate as an option when starting the virtual machine. The file path information of these server certificates is managed by [basic setting management unit 1] 45 in FIG. The external process side specifies an option as to whether or not to perform SSL authentication at startup.

  Thereby, the connection is realized by executing SSL authentication between the server and the client (FIG. 26). Until the connection by SSL leading to the initialization phase, the message format follows SSL. In addition, all other state transitions and the like are the same as in the first embodiment, and are therefore omitted.

<Example 4>
In the first embodiment, as described in (3), information correspondence of the buffer queue configuration (type, number, size) is shown using the version number. As a result, the multi-buffer queue can be shared between the virtual machine and the external process as a buffer queue for transmission and reception by using the version number.

  In this case, in the message type dependent field of the update message, it is possible to notify the connection partner by setting the bit of the updated buffer queue to 1 and setting the queue without update to 0 as follows. .

For example, when four buffer queues are used for transmission and reception, respectively, the message type field is composed of a total of 8 bits, 4 bits for transmission and 4 bits for reception. For example, when the 0th and 1st queues for transmission are updated, the message type dependent fields are as follows.
11000000 = (4 bits for transmission) (4 bits for reception)
Except for these update messages, the configuration is the same as that of the first embodiment, and the detailed procedure of the fourth embodiment is omitted.

<Example 5>
In the fourth embodiment, one connection is used in the multi-buffer queue. By associating buffer queues for transmission and reception with one connection and establishing connections for the number of multi-queues, parallelization is desired and performance improvement can be expected. Specifically, a multi-buffer queue and buffer queue sharing method with multi-connection functions can be realized by specifying and starting file descriptors for the number of virtual machines and external processes. .

  The specific embodiment has only a plurality of connections and is exactly the same as that of the first embodiment, so the details are omitted.

<Example 6>
In the first embodiment, the method of confirming to the external process based on the specification of the virtual queue as the queue between the guest OS and the virtual machine has been described. In general, the queue operation can be applied to other queue structures as long as the parent side and the child side agree on the structure (buffer queue configuration and operation method). In the first embodiment, when a virtual machine and an external process are connected, information on the buffer queue type, the number of buffer queues, and the buffer queue size is exchanged according to the version number ((3) of the first embodiment).

  Therefore, only the queue update notification function and the operation mode are exchanged, and in addition to the example of the first embodiment, the queue type information is added to the setting message, and the queue can be expanded to an arbitrary queue.

  In the state transition patterns D2 and D6, the problem that the memory is not released due to the fact that the re-initialization on the driver side caused by the virtual queue is not implemented by assuming the virtual queue has been described. This problem can also be solved by applying to a shared buffer queue having a function of re-initializing the Virtual queue at the time of link down or link up with another queue described in the present embodiment.

<Example 7>
In the above embodiments, the virtual machine communication device (virtual-net-ipc) is used as the client, and the external process communication device (virtqueue device) is used as the server. In addition, the present invention can be realized. In this case, the processing of the server and the client is the reverse pattern to the embodiment described so far, but the other state transitions are exactly the same as those described in the embodiment 1, and therefore the details are omitted.

<Effects produced by the present invention>
(I) Since the external process side and the virtual machine side can be directly connected, the number of times of memory copy and context switch switching can be reduced compared to the external communication methods 1 and 2, and high-speed data transfer can be realized. Can do.

(Ii) Each communication device of the virtual machine and external process detects a change in the state of each other's connection partner, and notifies itself to the inside of the guest OS and the processing logic inside the external process. Create an opportunity to deal with events such as maintenance (failure handling depends on the guest OS and processing inside the external process). As a result, the virtual machine (and guest OS) and the external process can be operated independently including an abnormal termination event. In other words, even if the virtual machine is restarted or the external process is restarted, the connection partner appears to be linked down, so that the operation does not hang up at all.

(Iii) When a virtual machine or an external process falls into a disconnected state, the state can be grasped correctly, so that it is possible to move to the operation of switching the connection partner. The failover function can be realized by reconnecting with another connection partner having the same function as.

(Iv) The present invention proposes message exchange contents between the virtual machine and the external process, and does not limit the connection method. Thereby, it is possible to select and adopt the mounting method according to the platform to be applied.

(V) By using the virtual-net-ipc device and the virtualqueue device of the present invention as a communication interface, a status notification is made with a link between the external process and the virtual machine connected to the guest OS side, and the status is notified to the guest OS side. The guest OS and external processes can perform normal operations without hanging up.

(Vi) In the external communication methods 1 and 2, the communication between the virtual machine and the external process requires a virtual switch for relay in addition to the tap device and the vhost-net driver. Does not require any components.

  Usually, the cycle time for a CPU is much shorter than the access time to a memory such as DRAM. This means that a wait for the CPU to execute the next instruction (referring to the memory area) occurs. As the number of references to the memory area increases, a longer waiting time occurs, resulting in a decrease in throughput. For this reason, if packets are copied to a plurality of memory areas for packet transfer between virtual machines as in the prior art, the performance of network I / O is reduced by this copying operation.

  FIG. 27 shows a model for solving this problem. The model of FIG. 27 is a virtual BRAS (Broadband Remote Access Server) network node using NFV and SDN (OpenFlow) of virtual network technology. The NFV is a network function virtualization, and the SDN is a software control network (Software-Defined Networking).

  Each virtual machine (VM) is an example that functions as an NFV and functions as an Internet connection service, a SIP service such as an IP telephone, and an NSOD (Network Service-Oriented Distributor). NSOD performs DPI (Deep Packet Inspection) and address assignment, and mediates between a service client and a network service. A virtual switch such as Open vsswitch or software-based OpenFlow switch that performs packet transfer in a virtual network is required. In the model of FIG. 27, since the virtual switch and the virtual machine operate in the same memory area, the packet copy operation can be reduced by bypassing the host OS, and the performance of the network I / O can be improved.

  Furthermore, the virtual channel construction system of the present invention can be applied to this BRAS. Since each virtual machine is directly connected via a shared buffer queue between the virtual device and the guest OS and packet transfer is possible, a virtual switch becomes unnecessary. For this reason, the number of packet copies can be further reduced, which can contribute to high-speed data transfer.

[Appendix]
The following is a summary of the features of the present invention (FIGS. 15, 19, 20, and 23).

1. The present invention initializes (establishes connection partner identification, buffer queue size, and type consistency) in order to share buffer queue operations while ensuring independence between the virtual machine and external processes. ), Setting process (buffer queue operation mode, buffer queue start address), buffer queue update notification process (if there is an interrupt), termination process, and modeled the connection state as follows: It is characterized by specifying a protocol.
(A) Since the same buffer is operated between the connection partners, the types and sizes of the buffers must be consistent with each other. In the initialization message, in order to realize this consistency, an information area for exchanging consistency information as version information for each connection is defined in the protocol message.
(B) Similarly, in the setting processing phase, an information area for transmitting the memory information of the buffer queue to the other party is defined in the protocol message.
(C) There are an interrupt mode and a no interrupt mode (polling mode) as methods for handling data input / output. Similarly, in the setting processing phase, the operation mode defining area is defined in the protocol message in order to negotiate this in advance before the connection is completed.
(D) In order to realize the interrupt mode, the message type for notifying the other party of the update notification every time the buffer queue is updated is defined in the protocol.

2. The present invention is characterized in that a non-interrupt mode (polling mode) is supported as an operation mode in the setting phase so that the communication device can perform data transfer in a polling mode without an update notification.

3. The present invention is characterized in that, when a disconnection state is detected in each of a virtual machine and an external process, an indefinite state of operation can be prevented by notifying itself of a link down.

4). The present invention is characterized in that when a disconnected state is established, the state can be reconnected by making a state transition to a reconnection phase.

5. The present invention combines a virtual machine / guest OS, an external process, and two state states of stop and start, and for sharing buffer queue expansion that realizes transition to a reconnectable state in each state transition It is characterized by defining protocol signaling.

10: Communication device interface 20: Transmission / reception shared buffer queue management unit 1
30: Basic setting processing unit 1
40: Communication unit (client)
50: Interface unit 60: Shared buffer queue operation unit 70: Basic setting processing unit 2
80: Communication unit (server)
100: Communication device 1
200: Communication device 2

Claims (3)

A physical machine having a virtual machine and a host OS capable of operating an external process formed outside the virtual machine;
A communication path constructing means for constructing a virtual communication path for directly connecting the virtual machine and the external process to the guest OS operating in the virtual machine;
A virtual communication path construction system comprising :
The communication path construction means includes
For the shared buffer queue formed for data transfer between the virtual machine and the guest OS, the shared buffer queue information acquired from the guest OS by the virtual machine is provided to the external process, so that the shared buffer queue A protocol function for extending the shared buffer queue that extends the data transfer destination to the external process and constructs the virtual communication path, and realizes a procedure related to communication between the guest OS and the external process ;
A connection state detection function for detecting a connection state that communication between the virtual machine and the external process is established or disconnected in the virtual communication path;
A connection status notification function for notifying the connection state to each of the guest OS and processing logic on the external process,
A reconnection function for periodically reconnecting to a communication destination when communication between the virtual machine and the external process is disconnected ;
Virtual communication path construction system characterized by have a. A virtual machine forming procedure for forming the virtual machine and the external process on a physical machine having a virtual machine and a host OS capable of operating an external process formed outside the virtual machine;
A virtual communication path construction method for performing a virtual communication path construction procedure for constructing a virtual communication path for directly connecting the virtual machine and the external process to a guest OS operating in the virtual machine ,
The virtual channel construction procedure is:
For the shared buffer queue formed for data transfer between the virtual machine and the guest OS, the shared buffer queue information acquired from the guest OS by the virtual machine is provided to the external process, thereby providing the shared buffer queue. Extending the data transfer destination to the external process to construct the virtual communication path, and realizing a shared buffer queue extending step for realizing a procedure related to communication between the guest OS and the external process ;
A connection state detection step of detecting a connection state in which communication between the virtual machine and the external process is established or disconnected in the virtual communication path;
A connection state notification step of notifying the connection state to each of the guest OS and processing logic on the external process,
A reconnection step of periodically reconnecting to a communication destination when communication between the virtual machine and the external process is disconnected ;
Virtual communication path construction method, characterized by have a. A virtual communication path construction program for causing a physical machine having a virtual machine and a host OS capable of operating an external process formed outside the virtual machine to realize the virtual communication path construction method according to claim 2 .

Images