JP2010003257A - Virtual machine system and method for sharing network device - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To enable a plurality of guest OS to share a network device without inviting overhead due to copying of data of a buffer. <P>SOLUTION: A VMM (Virtual Machine Manager) 20 constructs a shared memory 32 by using a shared memory area 120 secured by a memory 12 of a physical computer 1. A buffer used for data transfer through a network device 13 is arranged in the shared memory 32. When a guest OS on which network drivers 310-1 to 310-3 themselves operate is a master guest OS, the network drivers make a guest OS of a destination receive received data stored in the buffer in accordance with a reception completion interrupt from the network device 13, and make the network device 13 transmit transmission data stored in the buffer to a network 2 in accordance with a transmission request from the master guest OS or a transmission request interrupt from a guest OS other than the master guest OS. <P>COPYRIGHT: (C)2010,JPO&INPIT

Description

  The present invention relates to a virtual computer system in which a plurality of guest OSs operate in a virtual computer execution environment provided by a virtual computer manager that operates on a physical computer including a CPU and a memory. A virtual machine system and a network device sharing method suitable for sharing from a guest OS

  In recent years, in computer systems such as personal computers, research and development using virtual machine (VM) technology has been performed. In addition, commercial application programs for realizing virtual computer systems are actually widely used. There is also a virtual machine system that uses a virtual machine support mechanism configured with hardware (HW) for a long time in the mainframe.

  In general, a computer (physical computer, real computer) such as a personal computer is configured by a HW (real HW) including a CPU (real CPU) and a memory (real memory). A virtual machine manager (VMM), which is a hypervisor OS (operating system), operates on a physical computer (physical environment) configured by the real HW. As described below, a plurality of guest OSs operate under the virtual machine environment provided by the VMM (see Patent Document 1).

  The VMM manages physical resources such as a real CPU, a real memory, and various real input / output devices (such as disk drives) attached to the physical computer, and virtualizes them to construct a virtual machine (VM). In other words, the VMM allocates the real CPU, real memory, and real input / output devices of the physical computer as virtual CPUs, virtual memories, and virtual input / output devices of a plurality of virtual machines in terms of time and space (area). An environment (virtual machine environment) in which the plurality of virtual machines can operate simultaneously is constructed.

  A guest OS is loaded on each of the plurality of virtual machines (the virtual machine environment in which the virtual machines operate). The guest OS loaded on each virtual machine is executed by the virtual CPU in the virtual machine. That is, the guest OS operates in each virtual computer (virtual computer environment in which it operates). As described above, the VMM allocates physical resources such as a real CPU, a real memory, and a real input / output device to each guest OS, thereby providing an environment in which each guest OS can operate simultaneously and managing the virtual machine system. .

  A network device (real network device) is known as one of the real input / output devices. Further, the following mechanisms are conventionally known as a mechanism for the guest OS to use a network device.

The first is a mechanism (first mechanism) in which the VMM completely manages the real network device by constructing the virtual network device and providing it to the virtual machine environment. The second is one guest OS. This is a mechanism (second mechanism) in which a real network device is managed as a master, and communication between another guest OS and the outside is performed via the master guest OS.

The third is a mechanism (third mechanism) in which the guest OS directly manages an actual network device by its own device driver.
JP 2006-039763 A

  However, the first to third mechanisms have the following problems.

  The problem with the first mechanism is that a driver must be implemented in the VMM to provide a virtual network device. The problem of the first mechanism is also that the VMM becomes complicated and the cost of implementation increases. In addition, the problem of the first mechanism is that, depending on the situation, the operating environment of the VMM will not function due to the failure of the network device, and in addition, the virtual machine environment that should not be affected will not function. As a result, the reliability of the VMM itself is also lowered.

  The problem with the second mechanism is that data in a buffer (DMA buffer area) used for data transfer via a network device needs to be copied between the virtual memory spaces of the master guest OS and other guest OSs. The overhead is incurred and sufficient throughput cannot be obtained. Another problem of the second mechanism is that if the master guest OS becomes inoperable, other guest OSs cannot communicate.

  The problem of the third mechanism is due to the fact that the device driver is not created considering that other guest OSs use the same network device. In other words, the problem with the third mechanism is that the device driver operates in each of a plurality of guest OSs (the third mechanism that operates in), so there is no mechanism for exclusion between the plurality of guest OSes, and there is a network with a plurality of guest OSs. It is difficult to share devices. Therefore, in general, one network device can use only one guest OS. The VMM must have a function for determining which guest OS is to manage (show) the network device.

  The present invention has been made in view of the above circumstances, and an object of the present invention is to allow a plurality of guest OSs to share a network device without incurring overhead due to copying of data in a buffer used for data transfer via the network device. A virtual computer system and a network device sharing method are provided.

  According to one aspect of the present invention, a virtual machine system in which a plurality of guest OSs operate in a virtual machine execution environment provided by a virtual machine manager that operates on a physical machine including a CPU, a memory, and a network device is provided. . This virtual machine system is a plurality of network device drivers respectively operating on the plurality of guest OSs, and when the guest OS operating on itself is a master guest OS having a master right, an interrupt from the network device is issued. A shared memory constructed by the virtual machine manager using a plurality of network device drivers to be processed and a shared memory area secured in the memory, and accessible from the plurality of guest OSs and the plurality of network device drivers. A shared memory that temporarily stores received data received from the network by the network device and has a buffer secured for temporarily storing transmission data transferred from any of the plurality of guest OSs, Said When the guest OS on which the network device driver operates is the master guest OS, each of the network device drivers responds to a reception completion interrupt from the network device for notifying that the received data is stored in the buffer. If the reception processing means for receiving the received data by the guest OS that is the destination of the received data and the guest OS on which the received OS operates are the master guest OS, a transmission request from the master guest OS or the master guest OS Transmission processing means for transmitting the transmission data stored in the buffer to the network by the network device in response to a transmission request interrupt from a guest OS other than the above.

  According to the present invention, each guest OS that is constructed using a shared memory area secured in a memory while applying a mechanism for sharing a network device by cooperation between the master guest OS and other guest OSs, and By arranging a buffer for temporarily storing data transmitted / received via a network device in a shared memory accessible from each network device driver, each guest OS is not incurred in overhead due to copying of data in the buffer. Can share network devices.

Embodiments of the present invention will be described below with reference to the drawings.
FIG. 1 is a block diagram showing a configuration of a virtual machine system according to an embodiment of the present invention. The virtual computer system shown in FIG. 1 is realized using a physical computer (real computer) 1. The physical computer 1 includes hardware (HW) 10 that is used to provide a virtual computer environment. The HW 10 includes a CPU (real CPU) 11, a memory (real memory) 12, and a network device (real network device) 13 which are HW resources (physical resources). In FIG. 1, input / output devices other than the network device 13 attached to the physical computer 1, such as disk drives, are omitted.

  The network device 13 is connected to the network 2 outside the physical computer 1. The network device 13 performs communication between the physical computer 1 and an external physical device via the network 2.

  A virtual machine manager (VMM) 20 operates on the physical computer 1 (the HW 10). The VMM 20 manages the virtual machine system and constructs an environment (virtual machine environment) in which the virtual machine operates. More specifically, the VMM 20 controls physical resources (hardware resources) such as various input / output devices including the CPU 11, the memory 12, and the network device 13 that constitute the HW 10 of the physical computer 1. A virtual machine environment (virtual machine execution environment) in which a plurality of virtual machines, for example, three virtual machines 30-1, 30-2, 30-3 operate by managing the temporal and regional allocation of physical resources Build up.

  On the virtual machines 30-1, 30-2, and 30-3, guest OSs 31-1 (# 1), 31-2 (# 2), and 31-3 (# 3) operate, respectively. More specifically, the guest OSs 31-1 to 31-3 are loaded into the virtual machines 30-1 to 30-3, respectively, and executed by the virtual CPUs in the virtual machines 30-1 to 30-3. The The guest OSs 31-1, 31-2, 31-3 have unique identifiers (guest OS identifiers). In this embodiment, the guest OS identifiers of the guest OSs 31-1, 31-2, and 31-3 are 1, 2, and 3, respectively.

  The VMM 20 also constructs a shared memory 32 that can be accessed (referenced / written) from guest OSs 31-1 to 31-3 (drivers 310-1 to 310-3 described later). The shared memory 32 is a virtualized memory constructed by using a part (shared memory area) 32 of the storage area of the memory 12 included in the HW 10. The VMM 20 provides an interface (inter-guest OS interrupt distribution interface) for generating an interrupt for notification between the guest OSs 31-1 to 31-3 to the guest OSs 31-1 to 31-3.

  Network device drivers (hereinafter abbreviated as drivers) 310-1, 310-2, 310-3 are added to the guest OSs 31-1, 31-2, 31-3, respectively. The drivers 310-1 to 310-3 are device drivers for enabling the guest OSs 31-1 to 31-3 to use the network device 13, and the drivers 310-1 to 310-3 are used as part of the guest OSs 31-1 to 31-3. It operates on the guest OS 31-1 to 31-3. That is, the guest OSs 31-1 to 31-3 include drivers 310-1 to 310-3, respectively.

  Each of the guest OSs 31-1 to 31-3 has a function of becoming a master (master guest OS). The drivers 310-1 to 310-3 themselves operate as masters when the guest OSs 31-1 to 31-3 operate as masters. In the present embodiment, the drivers 310-1, 310-2, 310-3 have equivalent functions. However, some functions not directly related to the present invention may be different between the drivers 310-1 to 310-3. For example, the master function may be limited by any of the drivers 310-1 to 310-3.

  The driver 310-i (i = 1, 2, 3) has two types of interrupt handlers, an HW (hardware) interrupt handler 311 and an SW (software) interrupt handler 312. The HW interrupt handler 311 processes an interrupt (HW interrupt) generated by the network device 13. The SW interrupt handler 312 processes an interrupt (interrupt for notification between the guest OSs 31-1 to 31-3) generated by the inter-guest OS interrupt distribution interface.

  The driver 310-i further includes an open processing unit 313, a close processing unit 314, a transmission processing unit 315, a reception processing unit 316, an error interrupt processing unit 317, a master right transfer processing unit 318, and a guest OS exclusion process. Part 319. The master right transfer processing unit 318 includes a master right delegation processing unit 318a and a master right acquisition processing unit 318b. The functions of these processing units will be described later.

  FIG. 2 shows an example of area allocation in the shared memory 32 shown in FIG. The shared memory 32 includes a physical register map area 321, a special processing status area 322, a guest OS information area 323, and a DMA buffer area 324. The shared memory 32 also includes a transmission descriptor chain area 325, a reception descriptor chain area 326, and another shared information area 327.

  The physical register map area 321 is an area in which a group of physical registers belonging to the network device 13 is mapped. The group of physical registers mapped by the physical register map area 321 includes registers that need to be set in the initialization process, and interrupt factor registers. The physical register is accessed by accessing the physical register map area 321.

  The special process status area 322 is used to store a status indicating whether a special process (special process) to be performed by the driver 310-i has occurred. In the present embodiment, the special process whose status is managed using the special process status area 322 includes a process for initializing the shared memory 32, a physical disconnection of the network (corresponding to disconnection of the network cable, etc.), a network physical Connection process. These special processes are processes that can be performed by each driver 310-i using information in the shared memory 32, and are processes that do not cause a problem even if they are executed repeatedly by each driver 310-i. . In the present embodiment, the special process status area 322 stores a bit map indicating, in a bit state, whether or not the process is generated for each predetermined special process. The driver 310-i may refer to a bit corresponding to the special process in the special process status area 322 (bitmap stored in the special process status area 322) in order to confirm whether or not a special process has occurred.

  The guest OS information area 323 is used to store information on all guest OSs using the network device 13 and master guest OS information. The guest OS information (guest OS information) includes a guest OS identifier, SW interrupt number, and SW interrupt factor information.

The guest OS identifier indicates the identifier of the guest OS that is currently using the network device 13.
The SW interrupt number indicates the guest OS of the interrupt delivery destination when an interrupt is generated from another guest OS to the guest OS indicated by the guest OS identifier by the inter-guest OS notification function (inter-guest OS interrupt delivery interface). The SW interrupt handler 312 is shown.

  The SW interrupt factor information is information indicating the notification contents when the interrupt is generated. The SW interrupt factor information is composed of, for example, a bitmap. The distribution-destination guest OS refers to the bitmap-type SW interrupt factor information (the state of each bit) transmitted from the inter-guest OS interrupt distribution interface of the distribution-source guest OS (guest OS indicated by the guest OS identifier) To determine the notification contents.

The guest OS information further includes time stamp, communication count statistical information, guest OS priority, and network address as additional information.
The time stamp indicates the last operation time of the guest OS indicated by the guest OS identifier.

  The communication count statistical information is statistical information indicating the most recent communication count. In the present embodiment, the number of descriptors used by the guest OS during one descriptor chain cycle is used for the communication count statistical information. The descriptor chain cycle will be described later.

  The guest OS priority indicates the execution priority of the guest OS indicated by the guest OS identifier. That is, the guest OS priority is a value used as a selection criterion (index) when the VMM 20 selects a guest OS to be dispatched. In this embodiment, the CPU 11 (CPU time) is preferentially assigned to the guest OS having a larger guest OS priority value.

  The network address is a network address such as an IP (Internet Protocol) address assigned to the guest OS indicated by the guest OS identifier for communication via the network 2.

  The master guest OS information indicates a guest OS (master guest OS) operating as a master (that is, having a master right). Here, the guest OS identifier of the master guest OS is used as the master guest OS information.

  For convenience, the guest OS information area 323 shown in FIG. 2 shows a state in which only the guest OS information of the guest OS whose guest OS identifier is “1” (that is, the guest OS 31-1) is stored. ing. However, it is assumed that the guest OS information area 323 also stores guest OS information of other guest OSs 31-2 and 31-3 sharing the network device 13.

  The DMA buffer area 324 is an area for a data buffer (hereinafter referred to as a DMA buffer) 324a used by the network device 13 for DMA (Direct Memory Access) transfer of transmission / reception data.

  The transmission descriptor chain area 325 is used to store the transmission descriptor chain 325a. The transmission descriptor chain 325a has a descriptor management structure for managing a transmission descriptor based on an area (link) to the DMA buffer 324a and the HW specification. Each transmission descriptor included in the transmission descriptor chain 325a is used cyclically in the order linked in the chain. A cycle that makes a round of the transmission descriptor chain 325a is called a descriptor chain cycle.

  FIG. 3 shows an example of the transmission descriptor chain 325a. In the example of FIG. 3, the transmission descriptor chain 325a includes transmission descriptors 325-1 to 325-10. In this embodiment, the transmission descriptors 325-1 to 325-10 are linked by a ring-shaped chain. The transmission descriptor 325-j (j = 1 to 10) includes a status portion 3251, a pointer portion 3252, and a used guest OS information portion (not shown).

  The pointer unit 3252 stores a pointer that points to an area in the DMA buffer 324a where data to be transmitted is set (stored). The used guest OS information section stores information (for example, a guest OS identifier) indicating which guest OS is referencing (using) the transmission descriptor 325-j including the used guest OS information section.

  The status part 3251 indicates the status of the transmission descriptor 325-j. There are four statuses that the transmission descriptor 325-j can take, for example, “empty”, “not ready”, “ready”, and “dma”.

“Empty” indicates that the transmission descriptor 325-j is in an unused state.
“Not ready” indicates that the transmission descriptor 325-j is scheduled to be used for data transmission (reserved for use) but has not yet been set for data to be transmitted.

  “Ready” indicates that the transmission descriptor 325-j is scheduled to be used for data transmission and the setting of data to be transmitted has been completed.

  “Dma” indicates that DMA transfer for transmission of data designated by the pointer portion 3252 of the transmission descriptor 325-j is being executed.

The transmission descriptor chain 325a is managed by three types of pointers: a transmitting head pointer, a pre-transmission head pointer, and an empty head pointer. These pointers can be
This indicates a transmission descriptor in the positional relationship of the order indicated by an inequality sign such as the leading pointer during transmission ≦ the leading pointer before transmission ≦ the empty leading pointer (the larger is the traveling direction).

  Only a transmission descriptor having a status of “dma” exists between the position indicated by the leading pointer during transmission and immediately before the position indicated by the leading pointer before transmission. In the example of FIG. 3, transmission descriptors 325-3 and 325-4 correspond to this.

  A transmission descriptor with a status of “ready” and a transmission descriptor with a status of “not ready” may coexist from the position indicated by the pre-transmission head pointer to immediately before the position indicated by the empty head pointer. In the example of FIG. 3, transmission descriptors 325-5 to 325-9 correspond to this.

Only the transmission descriptor with the status “empty” exists beyond the empty head pointer. In the example of FIG. 3, transmission descriptors 325-10, 325-1, and 325-2 correspond to this.
These three types of pointers are operated by the network device 13.

  Referring back to FIG. 2, the receive descriptor chain area 326 is used to store the receive descriptor chain. The reception descriptor chain has a descriptor management structure for managing the reception descriptor based on the area (link to) the DMA buffer 324a and the HW specification. Each reception descriptor included in the reception descriptor chain is cyclically used in the order linked by the chain, similarly to each transmission descriptor included in the transmission descriptor chain 325a. A cycle that makes a round of the reception descriptor chain is also called a descriptor chain cycle.

  FIG. 4 shows an example of the reception descriptor chain. In the example of FIG. 4, the reception descriptor chain includes reception descriptors 326-1 to 326-10. In the present embodiment, the reception descriptors 326-1 to 326-10 are linked by a ring-shaped chain. Similarly to the transmission descriptor 325-j, the reception descriptor 326-j (j = 1 to 10) includes a status part 3261, a pointer part 3262, and a guest OS information part (not shown).

  The pointer unit 3262 stores a pointer indicating an area in the DMA buffer 324a in which data to be received is set. The used guest OS information section stores information (guest OS identifier) indicating which guest OS is using the received descriptor 326-j including the used guest OS information section.

  The status part 3261 indicates the status of the reception descriptor 326-j. The statuses that the reception descriptor 326-j can take are, for example, three types, “empty”, “received”, and “dma”.

“Empty” indicates that the reception descriptor 326-j is in an unused state.
“Received” indicates that data has already been received in the area in the DMA buffer 324a specified by the pointer portion 3262 of the reception descriptor 326-j, but the guest OS has not recognized that fact.

  “Dma” indicates that a DMA transfer for temporarily storing received data in an area in the DMA buffer 324a designated by the pointer portion 3262 of the reception descriptor 326-j is being executed.

The reception descriptor chain is managed by three types of pointers: a reception start pointer, a DMA start pointer, and an empty start pointer. These pointers can be
This indicates a reception descriptor that is in the positional relationship of the order indicated by an inequality sign such as a receiving top pointer ≦ a DMA starting pointer ≦ an empty head pointer (the larger one is the traveling direction). From the position pointed to by the leading pointer during reception to immediately before the position pointed to by the leading pointer during DMA, a reception descriptor with a status of “received” and a reception descriptor with an “empty” are mixed. In the example of FIG. 4, reception descriptors 326-3 and 326-4 correspond to this.

  Only a reception descriptor with a status of “dma” exists between the position indicated by the leading pointer in DMA and immediately before the position indicated by the empty leading pointer. In the example of FIG. 4, reception descriptors 326-5 and 326-6 correspond to this.

Only a reception descriptor with a status of “empty” exists beyond the empty head pointer. In the example of FIG. 4, the reception descriptors 326-7 to 326-10, 326-1, and 326-2 correspond to this.
These three types of pointers are operated by the network device 13.

  The other shared information area 327 is used to store information that should be shared among the drivers 310-i of each guest OS 31-i (i = 1, 2, 3), for example, information that needs to be used in special processing. .

  Next, features of the virtual computer system having the above-described configuration will be described.

  First, in the virtual machine system of FIG. 1, the drivers 310-1 to 310-3 operate on the guest OSs 31-1 to 31-3 sharing the network device 13, respectively. One of the drivers 310-1 to 310-3 operates as a master, and handles major parts of management of the network device 13 such as DMA processing and processing for an interrupt from the network device 13 for DMA processing.

  The virtual computer system of FIG. 1 is characterized by the information necessary for the drivers 310-1 to 310-3 operating on the guest OSs 31-1 to 31-3 and the guest OSs 31-1 to 31-3, respectively. A necessary part of the unique guest OS information can be cross-referenced. In order to enable this cross reference, the shared memory 32 provided by the VMM 20 to the guest OSs 31-1 to 31-3 is used. The drivers 310-1 to 310-3 of the guest OSs 31-1 to 31-3 each access the shared memory 32.

  The shared memory 32 is a virtualized memory constructed using the shared memory area 120 secured in the memory 12 included in the HW 10. Therefore, access to the shared memory 32 is physically realized by accessing the shared memory area 120 in the memory 12.

  In the present embodiment, the DMA buffer 324 a is also arranged in the shared memory 32. As a result, the DMA buffer 324a can also be directly referenced (accessed) from each of the guest OSs 31-1 to 31-3, and the overhead associated with data copying, which has been a big problem in the past, can be reduced as described later. .

  In the present embodiment, a mechanism is provided that allows the guest guest OS to be changed, that is, a mechanism that allows other guest OSs to continue using the network device 13 even if the master guest OS stops functioning. . In the present embodiment, a mechanism for supporting efficient use of the network device 13 is also provided.

  Hereinafter, operations centering on the driver of the guest OS in the virtual machine system having the above-described features will be sequentially described by taking “open (open) processing”, “transmission processing”, “reception processing”, and “error interrupt processing” as examples. To do.

[Open processing]
First, regarding the procedure of “open processing (open processing of driver)” executed when the driver (open processing unit 313) of the guest OS starts using the network device 13, the driver is the driver 310 of the guest OS 31-1. An example of the case of -1 will be described with reference to the flowchart of FIG.

  Assume that an “open request” is given from the guest OS 31-1 to the driver 310-1 of the guest OS 31-1. Then, the driver 310-1 searches for the area of the shared memory 32 and determines whether the area of the shared memory 32 exists (step S1).

  If the determination in step S1 is Yes, the driver 310-1 proceeds to step S8, assuming that the area of the shared memory 32 has been secured by a request from the driver of another guest OS that is the master.

  On the other hand, if the determination in step S1 is No, the driver 310-1 requests the VMM 20 to secure the area of the shared memory 32 (step S2). That is, the driver 310-1 causes the VMM 20 to secure a part of the storage area of the memory 12 included in the HW 10 as the shared memory area 120, thereby constructing the shared memory 32 (virtual shared memory memory). .

  Next, the driver 310-1 performs an initialization process for initializing the shared memory 32 (step S3). This initialization processing includes allocation of areas 321 to 327 in the shared memory 32 and processing of mapping a group of physical registers (a group of physical registers belonging to the network device 13) to the physical register map area 321. The initialization process includes a process of recording a status indicating that the initialization process is in progress in the special process status area 322. Here, a bit indicating whether the initialization process is in progress is turned on. Thereafter, the driver 310-1 records the progress of the initialization process at, for example, predetermined timings.

  The driver 310-1 initializes the network device 13 (step S4). Next, the driver 310-1 sets the distribution destination of the interrupt (HW interrupt) from the network device 13 to itself (step S5).

  Next, the driver 310-1 writes the guest OS information of the guest OS 31-1 including itself (in which it operates) in the guest OS information area 323 of the shared memory 32 (step S6). That is, the driver 310-1 writes the guest OS information of the guest OS 31-1 including the guest OS identifier of the guest OS 31-1, the SW interrupt number used by the SW interrupt handler 312, and the like in the guest OS information area 323. In step S6, the driver 310-1 registers in the guest OS information area 323 master guest OS information indicating that the master guest OS is the guest OS 31-1. Then, the driver 310-1 records the completion of the initialization process in the special process status area 322 of the shared memory 32 (step S7), and ends the “open process”.

  On the other hand, if the determination in step S1 is Yes, the driver 310-1 refers to the special processing status area 322 of the shared memory 32 constructed by a request from the driver of another guest OS that is the master, and The progress of the initialization process (steps S2 to S7) by the driver of the guest OS is confirmed, and if the initialization process continues, the process waits until the initialization process ends (step S8). When the initialization process ends, the driver 310-1 writes guest OS information (own guest OS information) unique to the guest OS 31-1 into the guest OS information area 323 of the shared memory 32 (step S9). The “open process” is terminated.

[Transmission process]
Next, regarding the procedure of “transmission processing” executed when the driver of the guest OS (the transmission processing unit 315) transmits the packet to the network 2 through the network device 13, the driver is the driver 310- of the guest OS 31-1. The case of 1 will be described as an example with reference to the flowchart of FIG. DMA is used for transferring packet data to the network device 13 to be executed in the “transmission process”.

  Now, it is assumed that a “transmission request” is given from the guest OS 31-1 to the driver 310-1 of the guest OS 31-1. Then, the driver 310-1 transmits as many transmission descriptors 325-j (FIG. 3) as necessary for transmission from the transmission descriptor chain 325a in the transmission descriptor chain area 325 of the shared memory 32, starting with the transmission descriptor indicated by the empty head pointer. In the example, the transmission descriptor 325-j includes the transmission descriptor 325-10) (step S11).

  Next, the driver 310-1 changes the status of the secured transmission descriptor 325-j (the status indicated by the status information set in the status part 3251) from “empty” to “not ready”, and also secures the secured transmission descriptor. The empty head pointer is updated by the number of 325-j (step S12). That is, the driver 310-1 moves the position indicated by the empty head pointer by the number of transmission descriptors 325-j secured.

  Next, the driver 310-1 adds information indicating that the reserved transmission descriptor 325-j is being used by the guest OS 31-1 (including the driver 310-1) to the descriptor 325-j. The above steps S11 to S13 need to be executed exclusively between the drivers of each guest OS. For this control, a general exclusive control method conventionally used when using a shared memory can be applied. About this exclusive control, although there are places where the same conditions are necessary in the subsequent procedures, the description is omitted.

  Next, the driver 310-1 prepares the transmission descriptor 325-j as follows in order to transmit the packet requested from the guest OS 31-1 (step S14). First, the driver 310-1 directly accesses the area in the DMA buffer 324a on the shared memory 32 based on the pointer stored in the pointer section 3252 of the transmission descriptor 325-j, thereby changing the data of the packet to be transmitted. Write. The driver 310-1 changes the status of the transmission descriptor 325-j for which writing of data (that is, preparation for transmission) is completed from “not ready” to “ready”.

  In this embodiment, the DMA transfer is managed by the master guest OS. Therefore, the driver 310-1 determines whether the guest OS 31-1 including the driver 310-1 (operating the driver 310-1) is the master guest OS (step S15).

  If the guest OS 31-1 is not the master guest OS (No in step S15), the driver 310-1 notifies the master guest OS (driver) by SW interrupt and requests a DMA transfer for transmission. (Step S16). That is, the driver 310-1 issues a DMA request interrupt for transmission (transmission DMA request interrupt) to the master guest OS (driver). The interrupt delivery destination to the master guest OS (driver) can be known by referring to the guest OS information area 323 of the shared memory 32. When driver 310-1 executes step S16, the transmission process is terminated.

  As described above, in this embodiment, the SW interrupt is used for notification between guest OSes. However, as long as it is a notification means between guest OSes provided by the VMM 20, a means other than the SW interrupt may be used. In this embodiment, SW interrupts are used for notifications between guest OSes for a plurality of uses. Therefore, in this embodiment, the interrupt distribution destination is set for each use, and the virtual interrupt factor register indicating the interrupt factor is arranged in the shared memory 32, so that the type of interrupt factor is the target guest OS. Is supposed to be recognized.

  On the other hand, if it is determined in step S15 that the guest OS 31-1 including the driver 310-1 is the master guest OS, that is, if the guest OS 31-1 that is the transmission request source is the master guest OS (Yes in step S15). Then, the driver 310-1 proceeds to step S17. In addition, the guest OS 31-1 is the master guest OS, and the guest OS 31-1 receives a transmission DMA request interrupt (transmission request interrupt) from the driver of the other guest OS according to the transmission request from the other guest OS. Even in this case, the driver 310-1 proceeds to step S17.

  In step S <b> 17, the driver 310-1 starts DMA processing for the network device 13. Specifically, the driver 310-1 sends a DMA request to the network device 13 by the number of consecutive transmission descriptors whose status is “ready” from the position in the transmission descriptor chain 325a pointed to by the pre-transmission head pointer. Issue. Here, since there is a possibility that a plurality of guest OSs are preparing for transmission by securing transmission descriptors, the status is not changed from the position indicated by the pre-transmission head pointer to immediately before the position indicated by the empty head pointer. There is a possibility that a transmission descriptor of “not ready” and a transmission descriptor of status “ready” are mixed. In step S17, the driver 310-1 changes the status of the transmission descriptor for which DMA processing has been started to “dma”, and advances the pre-transmission head pointer by the number of transmission descriptors for which the DMA processing has started.

  When the DMA transfer executed by the network device 13 in response to the DMA request from the driver 310-1 ends, the DMA transfer ends from the network device 13 to the driver 310-1 (driver 310-1 of the master guest OS 31-1). (DMA end) is notified by the HW interrupt. In response to the DMA-terminated HW interrupt, the driver 310-1 changes the status of the transmission descriptor that has been transmitted starting from the position indicated by the transmission start pointer to “empty”, and the number of transmission descriptors to be changed. The transmission leading pointer is updated by this amount (step S18). In step S18, the driver 310-1 clears the information indicating the guest OS that is referencing (using) the descriptor stored in the used guest OS information section of each transmission descriptor to be changed.

  When the driver 310-1 (the driver 310-1 of the master guest OS 31-1) executes step S18, the driver 310-1 determines whether or not the empty head pointer matches the head pointer before transmission (step S19). If the free head pointer and the pre-transmission head pointer do not match (No in step S19), the driver 310-1 determines that there should be a transmission descriptor for which a DMA request has not been issued. In this case, the driver 310-1 returns to step S17 in order to issue a DMA request to the network device 13 again.

  On the other hand, if the empty head pointer matches the head pointer before transmission (Yes in step S19), the driver 310-1 terminates the transmission process on the assumption that there is no transmission descriptor for which a DMA request has not been issued.

[Receive processing]
Next, regarding the procedure of “reception processing” executed when the driver of the guest OS (the reception processing unit 316) receives the packet through the network device 13, the driver is the driver 310-1 of the guest OS 31-1. An example will be described with reference to the flowchart of FIG.

  When the network device 13 detects a packet to be received from the network 2, the network device 13 performs DMA transfer of the detected packet to the area in the DMA buffer 324 a specified by the pointer portion 3252 of the empty reception descriptor 326-j ( Reception DMA operation) is started (step S21). The order of use of the areas in the DMA buffer 324a can be designated in advance by setting using HW, for example. In the present embodiment, the use order of the areas in the DMA buffer 324a is set to be in the order of the reception descriptor chain.

  Now, it is assumed that the above-described reception DMA operation (step S21) by the network device 13 is completed. That is, the network device 13 receives a packet from the network 2, and DMA-transfers the received packet to an area in the DMA buffer 324a designated by the pointer portion 3252 of the empty reception descriptor 326-j according to the reception descriptor chain. It is assumed that the reception DMA operation (step S21) is completed. In this case, the network device 13 issues a HW interrupt to the master guest OS (step S22). Here, it is assumed that the master guest OS is the guest OS 31-1.

  When the driver 310-1 of the master guest OS 31-1 accepts the HW interrupt from the network device 13, it receives a receive DMA (DMA transfer for temporarily storing received data) from the position of the receive descriptor chain pointed to by the first DMA pointer. The reception descriptor 326-j that has completed is checked (step S23). In step S23, the driver 310-1 updates the status of the reception descriptor 326-j for which the reception DMA has been completed from “empty” to “received”, and also updates the DMA top pointer. In step S23, the driver 310-1 identifies the guest OS that needs the contents of the reception descriptor 326-j (reception data indicated by the reception descriptor 326-j) for which the reception DMA has been completed. That is, the driver 310-1 selects guest OS information including a network address that matches the destination network address included in the received packet from the guest OS information of each guest OS stored in the guest OS information area 323. Then, the guest OS that needs the content of the reception descriptor 326-j is specified from the guest OS identifier included in the selected guest OS information.

  The driver 310-1 sets information indicating which guest OS should refer to the reception descriptor 326-j for which reception DMA has been completed in the used guest OS information section of the reception descriptor 326-j. If the packet received from the network 2 by the network device 13 is a packet to be referred to by a plurality of guest OSs such as a broadcast packet, the information of the plurality of guest OSs is the corresponding reception descriptor 326-j. Is set in the guest OS information section.

  The driver 310-1 of the guest OS 31-1 notifies the guest OS that needs the information of the reception descriptor 326-j of the completion of reception DMA by an SW interrupt (step S24). Here, it is assumed that the guest OSs that have received the SW interrupt from the driver 310-1 are the guest OSs 31-2 and 31-3.

  The drivers 310-2 and 310-3 of the guest OSs 31-2 and 31-3 that have received the SW interrupt from the guest OS 31-1 refer to the reception descriptor 326-j assigned thereto and perform processing necessary for reception. Is performed (step S25). The process necessary for this reception is a process of transferring the data in the area in the DMA buffer 324a pointed to by the pointer section 3262 of the reception descriptor 326-j to a storage area unique to the guest OSs 31-2 and 31-3. Including. When the drivers 310-2 and 310-3 have completed the processing necessary for reception and do not need to refer to the reception descriptor 326-j, information on the guest OSs 31-2 and 31-3 is obtained from the descriptor 326-j, respectively. Is deleted.

  When all the information on the guest OSs 31-2 and 31-3 that should refer to the descriptor 326-j is deleted from the reception descriptor 326-j, the driver 310-1 of the master guest OS 31-1 deletes the descriptor 326-j. The status is updated from “received” to “empty” (step S26). That is, the driver 310-1 sets the status of the descriptor 326-j to “empty” when it is no longer necessary to refer to the descriptor 326-j for all the guest OSs that need to reference the reception descriptor 326-j. Update to In step S26, if the status of the reception descriptor 326-j pointed to by the receiving head pointer is updated to “empty”, the driver 310-1 advances the receiving head pointer by one receiving descriptor.

[Error interrupt processing]
Next, with regard to the procedure of “error interrupt processing” executed when an error occurs in the operation of the network device 13, refer to the flowchart of FIG. 8 by taking as an example the case where the guest OS 31-1 is the master guest OS. I will explain.

  It is assumed that an error has occurred in the operation of the network device 13 now. In this case, the network device 13 issues an HW interrupt for notifying the driver 310-1 of the master guest OS 31-1 that an error has occurred (step S30).

  When the driver 310-1 (the HW interrupt handler 311) receives the HW interrupt (step S30) from the network device 13, the interrupt factor indicating the cause of the HW interrupt mapped to the physical register map area 321 of the shared memory 32 By referring to a register (for example, an error status register indicating the error status of the network device 13), the type of error that has caused the HW interrupt is identified (step S31). In this step S31, the driver 310-1 (the error interrupt processing unit 317) determines the bit stored in the special processing status area 322 of the shared memory 32 if processing corresponding to the identified error (error processing) is necessary. A bit corresponding to the error processing in the map is set to a state indicating that error processing has started. That is, the driver 310-1 (the driver 310-1 of the master guest OS 31-1) has a status (special processing status) indicating that processing corresponding to the identified error (error processing) has started in the special processing status area 322. ) Is set (step S31).

  Next, the driver 310-1 (the error interrupt processing unit 317) of the master guest OS 31-1 started error processing for the drivers 310-2 and 310-3 of the other guest OSs 31-2 and 31-3, respectively. This is notified using the SW interrupt (step S32). After that, when the error processing is completed, the driver 310-1 of the master guest OS 31-1 processes the bit status corresponding to the processing in the bitmap stored in the special processing status area 322 of the shared memory 32. Switch to a state that indicates not being done. That is, the driver 310-1 cancels the status that is set in the special processing status area 322 and indicates that error processing has been started (step S33).

  On the other hand, the drivers 310-2 and 310-3 (the error interrupt processing unit 317) of the guest OSs 31-2 and 31-3 other than the master guest OS 31-1 notify the start of error processing from the driver 310-1. When an interrupt (step S32) is received, a process necessary for interrupting or canceling the currently executing process is performed according to the type of the error (step S41).

  Next, the drivers 310-2 and 310-3 monitor the status of the special processing status area 322 of the shared memory 32, respectively, and confirm that the status indicating that error processing has been started is released. In other words, if it is confirmed that the error process has been completed, the process returns to the normal process (step S42).

  As described above, the open processing unit 313, the transmission processing unit 315, the reception processing unit 316, and the error interrupt provided in the driver 310-i of the guest OS 31-i (i = 1, 2, 3) applied in the present embodiment. The four basic functions of the processing unit 317), that is, “open processing function”, “transmission processing function”, “reception processing function”, and “error interrupt processing function” have been described in detail. With these functions, in particular, the “transmission processing function” and the “reception processing function”, it is possible to eliminate overhead due to copying of data in the DMA buffer.

  In this embodiment, a “master right delegation processing function” and a “master right acquisition processing function” (a master right delegation processing unit 318a and a master right acquisition processing unit 318b, respectively) are added to the driver 310-i. ing. Hereinafter, the “master right delegation process” and the “master right acquisition process” will be sequentially described.

[Delegation of master rights]
The “master right delegation process” is a process for the master guest OS to autonomously transfer the master right to another guest OS. The “master right delegation process” will be described below with reference to the flowchart of FIG. 9 by taking as an example the case where the guest OS 31-1 is the master guest OS.

  The driver 310-1 of the master guest OS 31-1 (the master right delegation processing unit 318a), when master right delegation is required, selects the master guest OS from other guest OSs currently sharing the network device 13. One guest OS to which the right is to be delegated is selected (step S51). Here, it is assumed that the guest OS 31-2 is selected. In step S51, the driver 310-1 of the master guest OS 31-1 uses the SW interrupt to send all guest OSs (here, the guest OSs 31-2 and 32-3) to the guest OSs other than the master guest OS 31-1. The master guest OS change from the OS 31-1 to the guest OS 31-2 is notified.

  Of the guest OSs notified of the change of the master guest OS by the SW interrupt, the driver 310-2 of the guest OS 31-2 to which the master right is transferred is related to the master guest OS in the guest OS information area 323 of the shared memory 32. The information is updated to indicate the guest OS 31-2 (step S52).

  Of the guest OSs that have received the notification of the change of the master guest OS, the driver 310-2 of the guest OS (new master guest OS) 31-2 to which the master right is transferred has the HW interrupt destination from the network device 13 as the guest OS 31- 2 (Driver 310-2) The setting is changed to become itself (step S61). If the guest OS (old master guest OS) 31-1 that has notified the change of the master guest OS is executing special processing, the new master guest OS 31-2 sets the special processing status area 322 of the shared memory 32. Referring to the special process from the middle (step S62).

[Master right acquisition processing]
The “master right acquisition process” is a process for a guest OS other than the master to transfer the master right to itself, that is, a process for a guest OS other than the master to acquire the master right. Hereinafter, with respect to the “master right acquisition process”, the guest OS 31-1 is the master guest OS, and the guest OS 31-2 is the guest OS to acquire the master right, with reference to the flowchart of FIG. I will explain.

  When the guest OS 31-2 wants to acquire the master right, the driver 310-2 (the master right acquisition processing unit 318b) of the guest OS 31-2 notifies the master guest OS 31- other than the guest OS 31-2. 1 is notified to all guest OSs (here, guest OSs 31-1 and 32-3) including 1 using the SW interrupt (step S71). By this notification, the processing related to the master guest OS in the guest OS other than the guest OS 31-2 is suppressed, and the guest OS 31-2 can acquire the master right exclusively.

  When executing the step S71, the driver 310-2 of the guest OS 31-2 updates the master guest OS information in the guest OS information area 323 of the shared memory 32 to indicate the guest OS 31-2 (step S72). As a result, the guest OS 31-2 acquires the master right and becomes a new master guest OS (new master guest OS).

  The driver 310-2 of the guest OS 31-2 changes the setting so that the HW interrupt destination from the network device 13 becomes the guest OS 31-2 itself (step S73).

  If the guest OS (old master guest OS) 31-1 that was the master until the guest OS (new master guest OS) 31-2 obtains mastership is executing special processing, the new master guest The OS 31-2 refers to the special process status area 322 of the shared memory 32 and takes over the special process from the middle (step S74).

[Close processing]
In the present embodiment, the above-mentioned “master right delegation process” is performed in the “close process (driver close process)” executed when the driver (close process unit 314) of the guest OS terminates the use of the network device 13. Is used. Hereinafter, the procedure of the “close (close) process” will be described with reference to the flowchart of FIG. 11 by taking as an example the case where the driver 310-1 of the guest OS 31-1 terminates the use of the network device 13.

  Now, it is assumed that a “close request” is given from the guest OS 31-1 to the driver 310-1 of the guest OS 31-1. Then, the driver 310-1 (the close processing unit 314) determines whether the guest OS 31-1 including the driver 310-1 is a master guest OS (step S81). If the guest OS 31-1 is not the master guest OS (No in step S81), the driver 310-1 proceeds to step S84 described later.

  On the other hand, if the guest OS 31-1 is the master guest OS (Yes in step S81), the driver 310-1 determines whether there is another guest OS (other guest OS) sharing the network device 13. Determination is made (step S82).

  If the determination in step S82 is Yes, that is, if the guest OS 31-1 is the master guest OS and there is another guest OS sharing the network device 13, the driver 310 of the guest OS 31-1 -1 (the close processing unit 314) performs the above-mentioned “master right delegation processing” (using the master right delegation processing unit 318a) (step S83). Then, the driver 310-1 proceeds to step S84.

  In step S84, the driver 310-1 (the driver 310-1 of the old master guest OS 31-1) deletes information related to the guest OS (old master guest OS) 31-1 including the driver 310-1 from the shared memory 32. To do. The processing in step S84 includes releasing each descriptor secured and referenced by the driver 310-1. When executing step S84, the driver 310-1 ends the “close process”.

  On the other hand, if the determination in step S82 is No, that is, if the guest OS 31-1 is the master guest OS and there is no other guest OS sharing the network device 13, the driver 310 of the guest OS 31-1 −1 performs processing for stopping the network device 13 (network device end processing) (step S85). Then, the driver 310-1 releases the shared memory 32 (shared memory area 120) by the VMM 20 (step S86), and ends the “close process”.

  By such “close processing”, even if the driver of the master guest OS is closed, that is, even if the master guest OS ends the use of the network device 13, it becomes possible to continue operation with other guest OSs. .

<Elimination of guest OS based on mutual monitoring>
When a plurality of guest OS drivers (network device drivers) operate in a coordinated manner as in this embodiment, the following problem may occur. For example, when a guest OS falls into an inoperable state called “panic” or “hang”, processing of descriptors used by the guest OS may not proceed depending on the HW specification of the network device 13. As a result, the transmission / reception process may not proceed. Further, if the master guest OS becomes inoperable, communication itself cannot be performed.

  Therefore, in the present embodiment, the mechanism in which the drivers 310-1 to 310-3 of the guest OSs 31-1 to 31-3 mutually monitor whether the guest OSs 31-1 to 31-3 are operating normally, A mechanism is provided for forcibly removing a guest OS that has been determined not to be operating from the shared state of the network device 13. With these two mechanisms, even if the guest OS (for example, the master guest OS) becomes inoperable, the operation is continued by the remaining guest OS.

There are various methods for detecting a guest OS that is not operating normally. Here, the following simple detection method is applied.
First, a counter (counter area) common to the guest OSs 31-1 to 31-3 is prepared in the shared memory 32 (shared memory area 120).

  The drivers 310-1 to 310-3 of the guest OSs 31-1 to 31-3 respectively count up the common counter at a specific timing, and use the counter value (counter value) after the count-up as a shared memory. It is held in its own guest OS information stored in the 32 guest OS information area 323. The specific timing may be managed by a timer in the guest OS, or may be an opportunity for specific processing during communication.

  The drivers 310-1 to 310-3 of the guest OSs 31-1 to 31-3 are counter values held in the guest OS information of the other guest OSs by the other guest OSs (that is, counter values of the other guest OSs). ). If the difference between the counter value of the other guest OS and the value of the common counter exceeds the threshold value, the drivers 310-1 to 310-3 distribute the SW interrupt to the other guest OS. Note that the above monitoring timing may be managed by a timer in the guest OS, or may be a specific processing opportunity during communication.

  If the guest OS to which the SW interrupt is distributed cannot react to the SW interrupt (for example, the common counter is counted up), the drivers 310-1 to 310-3 are not operating normally. Judge as a guest OS.

[Guest OS exclusion process]
Hereinafter, the procedure of “guest OS exclusion processing” for eliminating an abnormal guest OS determined to be not operating normally (from a state in which the network device 13 is shared) will be described with reference to the flowchart of FIG. .

  Now, the guest OS 31-2 driver 310-2 (the guest OS exclusion processing unit 319) has detected, for example, the guest OS 31-1 as an abnormal guest OS that is not operating normally (that is, a guest OS to be excluded). It is assumed (step S91). The driver 310-2 that has detected the abnormal guest OS 31-1 determines whether the abnormal guest OS 31-1 is the master guest OS based on the guest OS information of the abnormal guest OS 31-1 (step S92).

  If the abnormal guest OS 31-1 is not the master guest OS (No in step S92), the driver 310-2 that has detected the abnormal guest OS 31-1 proceeds to step S94 described later. On the other hand, if the abnormal guest OS 31-1 is the master guest OS (Yes in step S92), the driver 310-2 that has detected the abnormal guest OS 31-1 (using the master right acquisition processing unit 318b) described above. The “master right acquisition process” is performed (step S93). When driver 310-2 executes step S93, it proceeds to step S94.

  In step S94, the driver 310-2 notifies the abnormal guest OS 31-1 to be excluded using the SW interrupt (step S94). This notification is excluded from the state in which the network device 13 is shared when the abnormal guest OS 31-1 (the abnormal guest OS determined to be not operating normally) returns from the inoperable state. This is performed to notify the user that the device is using the network device 13 so as not to malfunction.

  Next, the driver 310-2 deletes information related to the abnormal guest OS 31-1 from the shared memory 32 (step S95). The processing in step S95 includes releasing each descriptor secured and referred to by the driver 310-1 of the abnormal guest OS 31-1. When the driver 310-2 forcibly excludes the abnormal guest OS 31-1 from the state in which the network device 13 is shared by executing step S95, the “guest OS exclusion process” ends.

  Assume that the driver 310-1 of the excluded guest OS 31-1 has been restored. Then, it is assumed that the restored driver 310-1 recognizes that the guest OS 31-1 including the driver 310-1 has been eliminated by the SW interrupt (step S94) from the driver 310-2. In this case, the driver 310-1 performs post-processing corresponding to the exclusion of the guest OS 31-1, for example, processing for treating the guest OS 31-1 as an error (step S100).

<Dynamic mastership transfer>
In the above description, the transfer of the master right is specially performed when the master guest OS is terminated or when an abnormality occurs in the master guest OS. However, even when the master guest OS is operating normally, it is possible to dynamically transfer the master right in order to improve the operation efficiency. Examples of such transfer of master rights for improving operational efficiency are listed below.

  (1) The guest OS with the highest number of communications becomes the master. In this case, overhead due to notification and dispatch between the master guest OS and other guest OSs during communication can be reduced. With regard to the number of communications, the number-of-communications statistics information included in the guest OS information stored in the guest OS information area 323 of the shared memories 32-1 to 321-2 may be used.

  (2) The guest OS with the most dispatch opportunities (time) (that is, the guest OS with the most dispatch opportunities) becomes the master. In order to obtain information on the dispatch opportunity (time) of each guest OS, the guest OS itself only needs to grasp the dispatch policy (schedule) of each guest OS. In this embodiment, the VMM 20 has means for providing a dispatch policy for the guest OSs 31-1 to 31-3. The drivers 310-1 to 310-3 (the master right transfer processing unit 318) of the guest OSs 31-1 to 31-3 grasp the dispatch policies of the guest OSs 31-1 to 31-3 using this means. . The means for providing the dispatch policy is assumed to be included in, for example, a scheduler or dispatcher provided in the VMM 20 for assigning the CPU 11 (CPU time) to the guest OSs 31-1 to 31-3. Here, the means for providing the dispatch policy is a dispatch designating means for designating a ratio of dispatch times of the guest OSs 31-1 to 31-3.

  (3) A priority (guest OS priority) is given to each guest OS in advance, and the guest OS having the highest priority among the operating guest OSs becomes the master. For example, the priority of each guest OS is given from a client terminal connected to the network 2 by the designation of a user such as a system builder. As described above, the priority of each guest OS is included in the guest OS information stored in the guest OS information area 323 of the shared memories 32-1 to 321-2.

[Transfer processing of master right to guest OS with frequent communication]
Next, “master right transfer processing to a guest OS having a large number of communications” corresponding to the above (1) will be described.

  In this embodiment, every time a guest OS other than the master guest OS performs communication, an overhead due to an interrupt notification and dispatch to the master guest OS occurs as compared with the case where the master guest OS itself performs communication. Therefore, it is expected that the overhead of the entire system is reduced and the communication throughput is improved when the guest OS having a higher communication frequency becomes the master guest OS.

  In this embodiment, the number of descriptors used by each guest OS is used to determine the number of communications. Here, it is assumed that the transmission descriptor chain 325a (the transmission descriptor 325-j in the transmission descriptor chain 325a) is used for the determination of the number of communications. However, the reception descriptor chain (the reception descriptor 326-j) may be used to determine the number of communications. Further, both descriptor chains (descriptors 325-j and 326-j) may be used in order to determine the number of communications more accurately.

  In order to determine whether to transfer the master right, a simple method such as “the guest OS that uses the most descriptors as the master guest OS” can be considered. When this method is applied, there is a possibility that the master right transfer process occurs frequently. Further, there is a possibility that the master right transfer process itself becomes an overhead.

Therefore, in the present embodiment, in order to prevent frequent transfer of the master right, it is determined whether to transfer the master right based on the following two conditions.
1a) When the number of communications of one guest OS other than the master guest OS is extremely large:
This is the case when a certain guest OS is using a certain ratio or more (for example, 1/2 or more) of the number of descriptors included in the descriptor chain.

1b) When the number of communications of the master guest OS is extremely small:
Assuming that N guest OSs share the network device 13, the master guest OS used less than a certain percentage of the number of descriptors included in the descriptor chain, for example, less than 1 / (2N). This is the case.

  In the following, with respect to the procedure of “migrating the master right to the guest OS having a large number of communications” performed based on the above two conditions, the guest OS 31-1 is a master guest OS as an example in the flowchart of FIG. Will be described with reference to FIG.

  The driver 310-1 (master right transfer processing unit 318) of the master guest OS 31-1 transmits a transmission request from the master guest OS 31-1, or a DMA from another guest OS (guest OS 31-2 or 31-3). When transmission processing is performed in response to a request interrupt, the statistical information on the number of communication times of the corresponding guest OS (transmission request source or the guest OS of the DMA request interrupt source) in the shared memory 32 is updated (step S111).

  Next, in the driver 310-1 of the master guest OS 31-1, the total z of the communication times of the guest OSs 31-1 to 31-3 indicated by the statistical information of the communication frequency reaches a predetermined fixed number, for example, 1200. It is determined whether or not (step S112). If the z reaches 1200 (Yes in step S112), the driver 310-1 investigates the number of communications as follows. Note that the timing at which the investigation is performed may be other timing than the number of z, for example, at regular intervals.

  First, the driver 310-1 of the master guest OS 31-1 investigates statistical information on the number of communication times of guest OSs other than the master guest OS 31-1, that is, guest OSs 31-2 and 31-3, and the guest OSs 31-2 and 31- 3, it is determined whether or not there is a guest OS having a descriptor usage number (communication count) b equal to or greater than a predetermined ratio (1200), for example, 1/2 or more (that is, 600 or more) (step S113). ). If b is 600 or more guest OSs (step S113 is Yes), the driver 310-1 (the master right delegation processing unit 318a included in the master right transfer processing unit 318) receives the guest OS. The aforementioned “master right delegation process” for delegating the master right is performed (step S114). Then, the driver 310-1 proceeds to step S116 described later.

  On the other hand, if b is not found in the guest OS having 600 or more (No in step S113), the driver 310-1 of the master guest OS 31-1 investigates the statistical information of the communication count of the master guest OS 31-1, Whether the number of descriptors used (number of communications) a of the master guest OS 31-1 is less than a certain ratio of the above-mentioned certain number (1200), for example, less than 1 / (2N) (when N is 3, less than 200). Determination is made (step S115).

  If the descriptor usage number of the master guest OS 31-1 is less than 1 / (2N) of 1200 (Yes in step S115), the driver 310-1 of the master guest OS 31-1 proceeds to step S114. In this step S114, the driver 310-1 of the master guest OS 31-1 (the master right delegation processing unit 318a included in the master right transfer processing unit 318) makes the guest OSs 31-2 and 31- except the guest OS 31-1. 3, the above-described “master right delegation process” for delegating the master right to the guest OS having the largest number of descriptors used (step S114). Then, the driver 310-1 proceeds to step S116.

  In step S <b> 116, the driver 310-1 clears statistical information on the number of communication times (number of descriptors used) of the guest OSs 31-1 to 31-3 in the shared memory 32.

  Next, a specific example (examples 1 to 3) of the above-mentioned “transfer process of master right to a guest OS with a large number of communications” will be described. Here, the guest OS 31-1, guest OS 31-2, and guest OS 31-3 are expressed as guest OS # 1, guest OS # 2, and guest OS # 3, respectively. Further, it is assumed that the guest OS # 1 is the master guest OS and the total number of descriptors in the transmission descriptor chain 325a is 1200 when step S112 is executed.

(Example 1)
Number of descriptors used by guest OS # 1: 400
Number of descriptors used by guest OS # 2: 700
Number of descriptors used by guest OS # 3: 100
In Example 1, guest OS # 2 matches the determination condition in step S113. In this case, the master right is transferred from the guest OS # 1 to the guest OS # 2.

(Example 2)
Number of descriptors used by guest OS # 1: 100
Number of descriptors used by guest OS # 2: 500
Number of descriptors used by guest OS # 3: 600
In Example 2, there is no guest OS that matches the determination condition in step S113. Here, the number of descriptors used by the master guest OS # 1 is 1200 / (3 × 2), that is, less than 200. Therefore, the number of descriptors used (number of communications) of the master guest OS # 1 matches the determination condition in step S115. In this case, of the remaining guest OSs, the master right is transferred to the guest OS # 3 with the largest number of descriptors used.

(Example 3)
Number of descriptors used by guest OS # 1: 300
Number of descriptors used by guest OS # 2: 500
Number of descriptors used by guest OS # 3: 400
In Example 3, there is no guest OS that matches the determination condition in step S113. Further, the number of descriptors used by the master guest OS # 1 does not match the determination condition in step S115. In this case, although the guest OS # 2 uses the largest number of descriptors, the master right is not transferred to the guest OS # 2. As a result, frequent transfer of master rights is prevented.

[Transition processing of master right to guest OS with many dispatch opportunities]
Next, “master right transfer processing to a guest OS with many dispatch opportunities” corresponding to the above (2) will be described.

  If the guest OS with the highest dispatching opportunity (or time) has the master right, the opportunity for accessing the network device 13 and performing special processing increases accordingly. For this reason, throughput may be improved as a result.

  Therefore, in the present embodiment, the drivers 310-1 to 310-3 of the guest OSs 31-1 to 31-3 use the dispatch specifying means of the VMM 20, and the dispatch time ratios of the guest OSs 31-1 to 31-3 are used. To figure out.

  The drivers 310-1 to 310-3 of the guest OSs 31-1 to 31-3, based on the dispatch time ratio of the guest OSs 31-1 to 31-3, “master right acquisition processing” and “ The “master right delegation process” when the driver is closed is executed as follows. Note that the master guest OS is the guest OS 31-1. The guest OS 31-2 or guest OS 31-3 other than the master guest OS is expressed as a guest OS 31-k (k is 2 or 3).

(When the driver is open)
It is assumed that when the driver 310-k of the guest OS 31-k is open, the setting of the dispatch time ratio of the guest OS 31-k is larger than that of the master guest OS 31-1. In this case, the driver 310-k of the guest OS 31-k performs a master right acquisition process.

(During driver close)
It is assumed that the setting of the dispatch time ratio of the guest OS 31-k is the largest among the other guest OSs when the driver 310-1 of the master guest OS 31-1 is closed. In this case, the driver 310-1 of the master guest OS 31-1 delegates the master right to the guest OS 31-k at the time of its own opening.
Instead of the dispatch time, a dispatch opportunity (number of times) may be used.

[Master right transfer processing to a guest OS with higher priority]
Next, “master right transfer processing to a guest OS with a high priority” corresponding to the above (3) will be described.

  As described above, the priority (guest OS priority) of the guest OSs 31-1 to 31-3 is a value used as a selection criterion when the VMM 20 selects a guest OS to be dispatched. For this reason, it is assumed that the guest OS having a higher priority has more opportunities for dispatch to the guest OS and the CPU allocation time increases. Therefore, it can be said that the priority of the guest OSs 31-1 to 31-3 is an index of the ease with which the guest OSs 31-1 to 31-3 are dispatched (that is, an index of time or number of times of dispatch). For this reason, it is possible to use the priority of the guest OSs 31-1 to 31-3 instead of the ratio of the dispatch time of the guest OSs 31-1 to 31-3.

  Therefore, the drivers 310-1 to 310-3 of the guest OSs 31-1 to 31-3 are based on the guest OS priority included in the guest OS information stored in the guest OS information area 323 of the shared memory 32. The “master right acquisition process” when the driver is open and the “master right transfer process” when the driver is closed are executed as follows. Note that the master guest OS is the guest OS 31-1. The guest OS 31-2 or guest OS 31-3 other than the master guest OS is expressed as a guest OS 31-k (k is 2 or 3).

(When the driver is open)
It is assumed that the priority of the guest OS 31-k is higher than that of the master guest OS 31-1 when the driver 310-k of the guest OS 31-k is open. In this case, the driver 310-k of the guest OS 31-k performs a master right acquisition process.

(During driver close)
When the driver 310-1 of the master guest OS 31-1 is closed, the guest OS 31-k has the highest priority among the other guest OSs. In this case, the driver 310-1 of the master guest OS 31-1 delegates the master right to the guest OS 31-k at the time of its own opening.

[Master rights transfer process when changing priority of guest OS]
For example, the priority of the guest OSs 31-1 to 31-3 is changed by the VMM 20, and the change is notified from the VMM 20 to the guest OSs 31-1 to 31-3. The priority levels of the guest OSs 31-1 to 31-3 are also changed by requests from the guest OSs 31-1 to 31-3 to the VMM 20.

  In the following, with respect to the “master rights transfer process (to a guest OS with a higher priority) when the priority of the guest OS is changed”, an example in which the priority of the guest OS 31-1 is changed is illustrated in the flowchart of FIG. Will be described with reference to FIG.

  Now, the driver 310-1 of the guest OS 31-1 (the master right transfer processing unit 318) notifies the VMM 20 that the priority (guest OS priority) of the guest OS 31-1 has been changed by the VMM 20. Detected by. Then, the driver 310-1 of the guest OS 31-1 sets the guest OS priority of the guest OS 31-1 included in the guest OS information stored in the guest OS information area 323 of the shared memory 32 to the priority after the change. It is updated every time (step S121). It should be noted that the guest OS priority of the guest OS 31-1 has been changed by the driver 310-1 of the guest OS 31-1 periodically referring to the guest OS information stored in the guest OS information area 323, for example. You may detect that.

  Next, the driver 310-1 of the guest OS 31-1 determines whether the guest OS 31-1 is a master guest OS (step S122). If the guest OS 31-1 is the master guest OS (Yes in step S122), the driver 310-1 of the guest OS 31-1 determines whether the priority of the guest OS 31-1 has decreased (step S123). ).

  If the priority of the guest OS 31-1 is not lowered (No in step S123), the driver 310-1 of the guest OS 31-1 does nothing and ends the master right transfer process.

On the other hand, if the priority of the guest OS 31-1 is lowered (Yes in step S123), the driver 310-1 of the guest OS 31-1 is stored in the guest OS information area 323 of the shared memory 32. Based on the OS information, it is determined whether there is a guest OS having a higher priority than the guest OS 31-1 (that is, the master guest OS) (step S124).
If there is no guest OS having a higher priority than the guest OS 31-1 (master guest OS) (No in step S124), the driver 310-1 of the guest OS 31-1 does nothing and transfers the master right. The process ends.

  On the other hand, if there is a guest OS having a higher priority than the guest OS 31-1 (master guest OS) (Yes in step S124), the driver 310-1 of the guest OS 31-1 (master right transfer processing unit thereof) The master right delegation processing unit 318a included in 318 delegates the master right to the guest OS having the highest priority among the guest OSs having a higher priority than the guest OS 31-1 (master guest OS) ( Step S125), the master right transfer process is terminated. In other words, the driver 310-1 of the guest OS 31-1 is such that the guest OS 31-1 is the master guest OS, and the priority of the guest OS 31-1 is lowered and the priority of the other guest OS is higher. , “Master right delegation processing” is performed.

  On the other hand, even when the guest OS 31-1 is not the master guest OS (No in step S122), the driver 310-1 determines whether the priority of the guest OS 31-1 has decreased (step S126).

  If the priority of the guest OS 31-1 decreases (Yes in step S126), the driver 310-1 of the guest OS 31-1 does nothing and ends the master right transfer process.

  On the other hand, if the priority of the guest OS 31-1 is not lowered (No in step S126), the driver 310-1 of the guest OS 31-1 increases the priority of the guest OS 31-1 and becomes the master guest OS. It is determined whether or not the priority is higher (step S127).

  If the priority of the guest OS 31-1 is still lower than the priority of the master guest OS (No in step S127), the driver 310-1 of the guest OS 31-1 does nothing and performs the master right transfer process. finish.

  On the other hand, if the priority of the guest OS 31-1 becomes higher than the priority of the master guest OS (Yes in step S127), the driver 310-1 of the guest OS 31-1 (master right transfer processing unit 318 thereof). The master right acquisition processing unit 318b included in FIG. 2 acquires the master right (step S128), and ends the master right transfer process. In other words, the driver 310-1 of the guest OS 31-1 is that if the guest OS 31-1 is not the master guest OS and the priority of the guest OS 31-1 is higher than the priority of the master guest OS, Perform “master right acquisition processing”.

  Note that the present invention is not limited to the above-described embodiment as it is, and can be embodied by modifying the constituent elements without departing from the scope of the invention in the implementation stage. In addition, various inventions can be formed by appropriately combining a plurality of components disclosed in the embodiment. For example, some components may be deleted from all the components shown in the embodiment.

1 is a block diagram showing a configuration of a virtual computer system according to an embodiment of the present invention. The figure which shows the example of allocation of the area | region in the shared memory shown by FIG. The figure which shows an example of the transmission descriptor chain stored in the transmission descriptor chain area | region shown by FIG. The figure which shows an example of the reception descriptor chain stored in the reception descriptor chain area | region shown by FIG. 6 is a flowchart showing a procedure of “open processing” in the embodiment. 6 is a flowchart showing a procedure of “transmission processing” in the embodiment. 7 is a flowchart showing a procedure of “reception processing” in the embodiment. 6 is a flowchart showing a procedure of “error interrupt processing” in the embodiment. 9 is a flowchart showing a procedure of “master right delegation processing” in the embodiment. 6 is a flowchart showing a procedure of “master right acquisition processing” in the embodiment. 7 is a flowchart showing a procedure of “close processing” in the embodiment. 8 is a flowchart showing a procedure of “guest OS exclusion processing” in the embodiment. 6 is an exemplary flowchart illustrating a procedure of “master right transfer processing to a guest OS having a high communication count” according to the embodiment. 6 is an exemplary flowchart illustrating a procedure of “master right transfer processing when changing the priority of a guest OS” in the embodiment.

Explanation of symbols

  DESCRIPTION OF SYMBOLS 1 ... Physical computer, 2 ... Network, 10 ... HW (hardware), 11 ... CPU, 12 ... Memory, 13 ... Network device, 20 ... VMM (virtual computer manager), 30-1-30-3 ... Virtual computer, 31-1 to 31-3: Guest OS, 32 ... Shared memory, 120 ... Shared memory area, 310-1 to 310-3 ... Network device driver, 311 ... HW interrupt handler, 312 ... SW interrupt handler, 313 ... Open processing , 314... Close processing unit, 315... Transmission processing unit, 316... Reception processing unit, 317... Error interrupt processing unit, 318... Master right transfer processing unit, 318 a. 319: Guest OS exclusion processing unit, 321: Physical register map area, 322: Special processing status area 323 ... Guest OS information area, 324 ... DMA buffer area, 324a ... DMA buffer, 325 ... Transmission descriptor chain area, 325a ... Transmission descriptor chain, 325-1 to 325-10 ... Transmission descriptor, 326 ... Reception descriptor chain area, 326a ... Receive descriptor chain, 326-1 to 326-10 ... Receive descriptor, 327 ... Other shared information area.

Claims (12)

A virtual machine manager that operates on a physical computer including a CPU, a memory, and a network device and constructs a virtual machine execution environment in which a plurality of guest OSs can operate;
A plurality of network device drivers respectively operating on the plurality of guest OSs, wherein when the guest OS operating on the plurality of guest OSs is a master guest OS having a master right, a plurality of network devices that process an interrupt from the network device A driver,
A shared memory constructed by the virtual machine manager using a shared memory area secured in the memory and accessible from the plurality of guest OSs and the plurality of network device drivers, and received from the network by the network device And a shared memory in which a buffer for temporarily storing transmission data transferred from any of the plurality of guest OSs is secured,
Each of the plurality of network device drivers is
When the guest OS on which it operates is the master guest OS, the received data is converted into the received data in response to a reception completion interrupt from the network device for notifying that the received data is stored in the buffer. Receiving processing means for receiving by the destination guest OS;
When the guest OS on which it operates is the master guest OS, the transmission data stored in the buffer in response to a transmission request from the master guest OS or a transmission request interrupt from a guest OS other than the master guest OS Transmission processing means for transmitting data to the network by the network device.   When the guest OS on which the network device driver operates is the master guest OS, the transmission processing unit of the network device driver transmits from the master guest OS in response to a transmission request from the master guest OS. Data is stored in the buffer, and then the transmission data stored in the buffer is transmitted to the network by the network device, and the guest OS on which the network device driver operates is different from the master guest OS. In this case, in response to a transmission request from the other guest OS, transmission data from the other guest OS is stored in the buffer, and then the transmission request interrupt is issued to the master guest OS. The provisional claim 1 Computer system.   Each of the plurality of network device drivers includes a plurality of guest OSs when a guest OS on which the network device driver operates is the master guest OS and a master right needs to be transferred from the guest OS to another guest OS. 3. A master right delegation unit that selects a guest OS from which a master right is to be delegated and executes a master right delegation process for delegating the master right to the selected guest OS. Virtual computer system.   4. The virtual machine system according to claim 3, wherein the master right delegation unit executes the master right delegation process when the master guest OS finishes using the network device. Each of the plurality of network device drivers detects an abnormal guest OS by monitoring an operating state of a guest OS other than the guest OS in which the plurality of guest OSs are operating, and detects the detected abnormality. An exclusion means for excluding a guest OS from sharing the network device;
When the detected abnormal guest OS is the master guest OS, the exclusion unit performs a master right acquisition process for causing the guest OS on which the network device driver including the exclusion unit operates to acquire the master right. The virtual machine system according to any one of claims 1 to 4, further comprising a master right acquisition unit to be executed.   Each of the plurality of network device drivers includes the number of communications of the plurality of guest OSs, the time or number of times when the plurality of guest OSs are dispatched, or the number of times when the plurality of guest OSs are indicators of the time or number of times dispatched. Based on the priority, an optimal guest OS is determined as the master guest OS, and when the determined guest OS is different from the current master guest OS, the master right transfer for transferring the master right to the determined guest OS The virtual machine system according to claim 1, further comprising a master right transfer unit that executes processing. In a virtual machine system in which a plurality of guest OSs operate in a virtual machine execution environment provided by a virtual machine manager that operates on a physical machine including a CPU, a memory, and a network device, the network devices are shared by the plurality of guest OSs A network device sharing method,
A network device driver that is one of a plurality of network device drivers that respectively operate on the plurality of guest OSs is secured in the memory in response to an open request from the guest OS that operates the network device driver. A shared memory that has a virtualized memory area and is accessible from the plurality of guest OSes and the plurality of network device drivers, and temporarily stores received data received from the network by the network device, and A step of causing the virtual machine manager to construct a shared memory in which a buffer for temporarily storing transmission data transferred from any of the guest OSs is secured;
The network device driver operating on the master guest OS having the master right among the plurality of guest OSs receives a reception completion interrupt from the network device for notifying that the received data is stored in the buffer. In response, receiving the received data by the destination guest OS of the received data;
The network device driver operating on the master guest OS receives the transmission data stored in the buffer in response to a transmission request from the master guest OS or a transmission request interrupt from a guest OS other than the master guest OS. A network device sharing method comprising: causing the network device to transmit to the network. The network device driver that has received the transmission request from the guest OS that operates among the plurality of network device drivers stores the transmission data from the guest OS in the buffer;
The network device driver that has received the transmission request determines whether the transmission request source is the master guest OS; and
The network device driver that has received the transmission request issues the transmission request interrupt to the master guest OS when the transmission request source is not the master guest OS. Network device sharing method.   Among the plurality of network device drivers, a network device driver operating on the master guest OS selects a guest OS to which the master right should be delegated from among the plurality of guest OSs, and the selected guest OS The network device sharing method according to claim 8, further comprising: delegating a master right to the network device. Each of the plurality of network device drivers detecting an abnormal guest OS by monitoring an operating state of a guest OS other than the guest OS on which the plurality of guest OSs are operating;
If the detected abnormal guest OS is the guest OS, a network device driver that detects the abnormal guest OS causes the guest OS in which it is operating to acquire the master right;
The network device driver according to claim 7, further comprising: a step of removing the abnormal guest OS from sharing the network device by the network device driver that has detected the abnormal guest OS. Device sharing method.   Each of the plurality of network device drivers indicates the number of communication times of the plurality of guest OSs, or the time or number of times when the plurality of guest OSs are dispatched, or the time or number of times when the plurality of guest OSs are dispatched. Based on the priority, an optimal guest OS is determined as the master guest OS, and when the determined guest OS is different from the current master guest OS, the master right is further transferred to the determined guest OS. 9. The network device sharing method according to claim 7 or 8, wherein: The step for causing the network device driver to construct the shared memory includes:
The network device driver determining whether the shared memory has already been constructed in response to an open request from a guest OS on which the network device driver operates;
If the shared memory is not built, the network device driver causing the virtual machine manager to build the shared memory;
The network device driver that has constructed the shared memory includes the step of registering in the shared memory master guest OS information indicating that the guest OS on which the network device driver operates is the master guest OS. The network device sharing method according to claim 7.

Images