JP2014235578A - Virtual machine system, control method of sr-iov compatible device - Google Patents

Abstract

PROBLEM TO BE SOLVED: To emulate VF in an SR-IOV compatible device.SOLUTION: In a virtual machine system in which a guest OS operates on a virtual machine by a virtualization mechanism, an SR-IOV compatible device comprises Physical Function (PF) and Virtual Function (VF). The virtualization mechanism monitors the PF, sets a first mode when a link state of the PF of a monitoring target is in a link-up state, sets a second mode when in a link-down state, and emulates the link-down state of the VF by inhibiting the SR-IOV compatible device related to the VF from responding to a command related to the VF from the guest OS when the second mode is set.

Description

  The present invention relates to a technology of a virtual machine and an SR-IOV compatible device.

  A virtual computer system for constructing a plurality of virtual computers on a physical computer has been put into practical use. By using a virtual computer system, it is possible to expect efficient use of physical computer resources, reduction of costs required for system introduction and operation, and the like. In recent years, the introduction of virtual computer systems has progressed even in mission-critical systems, and the reliability and availability of virtual computer systems are also demanded.

  One technique for improving availability is a redundancy technique. For example, as a communication network redundancy method, a physical computer is provided with a plurality of NICs (Network Interface Cards), and communication is continued by switching to a standby NIC when the active NIC is linked down. There is a technique.

  In addition, an SR-IOV (Single Root I / O Virtualization) standard that supports virtualization on the PCI (Peripheral Component Interconnect) device side has been formulated (Non-patent Document 1).

PCI-SIG, Single Root I / O Virtualization and Sharing Specification Revision 1.1, January 20, 2010, p. 17

  For example, it is conceivable to make a communication network of virtual machines redundant by using an SR-IOV compatible device (NIC). However, even if the NIC conforms to the SR-IOV standard, not all NICs necessarily perform the same operation.

  Accordingly, an object of the present invention is to enable a virtual machine to use a function related to an SR-IOV compatible device without considering the difference even when there is a difference in operation between SR-IOV compatible devices. There is.

  A virtual computer system according to an embodiment of the present invention includes a physical CPU (Central Processing Unit), a physical memory, an SR-IOV compatible device, and a virtualization mechanism. A guest OS (Operating System) runs on a virtual machine to which logical resources obtained by logically dividing a physical CPU and physical memory are allocated by a virtualization mechanism. The SR-IOV compatible device includes a PF (Physical Function) that is a physical network device and a VF (Virtual Function) that is a virtual network device corresponding to the PF. The virtualization mechanism monitors the link status of the PF, sets the first mode when the link status of the monitored PF is the link up status, sets the second mode when the link status is the link down status, and sets the second mode. When the mode is set, the SR-IOV compatible device related to the VF is not responded to the command related to the VF from the guest OS, and the fact that the VF is in the link down state is emulated. The “virtualization mechanism” is, for example, a hypervisor as described later, but may be a hardware device (for example, a circuit) having a processor that executes a computer program such as a hypervisor.

  According to the present invention, even when there is a difference in operation between SR-IOV compatible devices, the virtual machine can use the function related to the SR-IOV compatible device without considering the difference.

FIG. 3 is a schematic diagram illustrating a configuration example of a virtual machine system in which network redundancy is performed using two NICs. It is a schematic diagram showing a configuration example of a virtual machine system in which a communication network is made redundant using an SR-IOV compatible NIC. It is a block diagram which shows the structural example of a virtual machine system. The format example of a PCI configuration register is shown. It is an example of a structure of a monitoring object device management table. It is a structural example of a PF link state management table. It is a figure explaining the operation example of the virtual machine system in the case of pass-through mode. It is a figure explaining the operation example of the virtual machine system in the case of emulation mode. It is a flowchart which shows an example of the creation process of a PF link state management table. It is a flowchart which shows an example of the process which detects the change of the link state of PF. It is a flowchart which shows an example of the process in a mode switching part. It is a flowchart which shows an example of the process in a VF MMIO emulation part.

  Hereinafter, an embodiment in a virtual machine system including an SR-IOV compatible device will be described with reference to the drawings.

  FIG. 1 is a schematic diagram showing a configuration example of a virtual machine system in which communication networks are made redundant using two NICs. Hereinafter, an example of redundancy of a conventional communication network will be described with reference to FIG.

  The physical computer 10 includes NICs 21 and 21. The hypervisor 19 virtualizes the resources of the NICs 21 and 21 included in the physical computer 10 as virtual NICs 22 and 22 and allocates them to the virtual computers.

  Redundant software 131 operating on the guest OS 13 on the virtual machine 12 forms a redundant configuration 1001 of a communication network using the virtual NICs 22 and 22. Thereby, even if one NIC 21 is in the link-down state, the guest OS 13 can continue communication with the communication network 90 using the virtual NIC 22 in the link-up state if the other NIC 21 is in the link-up state. Here, the link up refers to a state in which the NIC 21 can communicate with the communication network 90. Link down refers to a state in which the NIC 21 cannot communicate with the communication network 90.

  FIG. 2 is a schematic diagram illustrating a configuration example of a virtual machine system in which communication network redundancy is performed using an SR-IOV compatible device (NIC). Hereinafter, an example of redundancy of a general communication network using SR-IOV compatible devices will be described with reference to FIG.

  The SR-IOV compatible device 30 has a function of realizing a plurality of virtual NICs on one device. The SR-IOV compatible device has a PF 34 corresponding to a physical NIC and a VF 32 realized as a virtual NIC. The VF 32 communicates with an external communication network 90 via the PF 34. A plurality of VFs 32 may be associated with one PF 34.

  The physical computer 10 includes SR-IOV compatible devices 30 and 30. The hypervisor 19 allocates the resources of the VF 32 included in the physical computer 10 to the virtual computer 12 as VFs 33 and 33.

  The redundancy software 131 operating on the guest OS 13 on the virtual computer 12 forms a redundant configuration 1101 of the communication network using the VFs 33 and 33. As a result, even if one VF 33 is in the link-down state, the guest OS 13 can continue communication with the communication network 90 using the VF 33 in the link-up state if the other VF 33 is in the link-up state.

  In the SR-IOV compatible device 30, when the PF 34 is linked down, the VF 32 cannot communicate with the external communication network 90.

  The redundancy software 131 switches to the standby VF 33 when the active VF 33 cannot communicate with the external communication network. That is, when the redundancy software 131 detects a link down of the active VF 33, the redundancy software 131 switches to the standby VF 33. Therefore, when the PF 34 is linked down, the SR-IOV compatible device 30 must set the link state of the VF 32 corresponding to the PF 34 to the “link down state”.

  However, the link state relationship between the PF 34 and the VF 32 is not defined in the SR-IOV standard. For this reason, even if the PF 34 is linked down, there is an SR-IOV compatible device that keeps the VF 32 in the “link up state” without setting the VF 32 in the “link down state”.

When such an SR-IOV-compatible device is used, even if the PF 34 is linked down and the active VF 32 cannot communicate with the external communication network 90, the VF 32 remains in the “link up state”. From the software 131, the VF 33 appears as a “link up state”. Therefore, the redundancy software 131 cannot switch the active VF 33 to the standby VF 33 even though the PF 34 is linked down. That is, the redundancy software 131 cannot normally perform communication network redundancy.
Hereinafter, an embodiment of a virtual machine system that solves such a problem will be described.

  FIG. 3 is a block diagram illustrating a configuration example of the virtual machine system. The virtual computer system includes a physical computer 10 and a hypervisor 11.

  The physical computer 10 includes a physical CPU 41, a physical memory 42, a storage device (not shown), and an SR-IOV compatible device 30.

  The physical CPU 41 processes I / O related to the physical computer 10 and executes various computer programs (hereinafter referred to as “programs”).

  The physical memory 42 temporarily stores various programs and data. The storage medium in the physical memory 42 may be a volatile memory. The volatile memory may be a DRAM (Dynamic Random Access Memory) or the like. The physical memory 42 has a page table 52 for managing a memory area (page).

  A storage device (not shown) holds various programs and data. The storage medium in the storage device may be a non-volatile memory. Non-volatile memory is write-once memory, for example, flash memory, MRAM (Magnetic Random Access Memory), PRAM (Phase Change Random Access Memory), ReRAM (Resistivity Random Memory Access Memory). ) Etc.

  The SR-IOV compatible device 30 is a PCI device compatible with SR-IOV. The SR-IOV compatible device 30 may be a NIC. The SR-IOV compatible device 30 includes, for example, a PCI configuration register 51, a PF 34, and a VF 32.

  The PCI configuration register (hereinafter referred to as “PCI configuration”) 51 holds various information related to the PCI device. In principle, all PCI devices have the PCI configuration 51.

FIG. 4 shows a format example of the PCI configuration register.
As shown in FIG. 4, “vendor ID” is stored in a 2-byte area 401 from the address “0x00” of the PCI configuration 51. “Device 1D” is stored in the 2-byte area 402 from the address “0x02”. The “subsystem vendor ID” is stored in the 2-byte area 403 from the address “0x2C”. “Subsystem device ID” is stored in an area 404 of 2 bytes from the address “0x2E”. With these four pieces of information, the type of PCI device can be determined. Returning to the description of FIG.

  The PF 34 indicates a function of a conventional PCI device in the SR-IOV compatible device 30. In the case of this embodiment, the PF 34 corresponds to a physical NIC.

  The VF 32 shares the resource of the PF 34 in the SR-IOV compatible device 30. When a plurality of VFs 32 are associated with one PF 34, the plurality of VFs 32 share the resources of the one PF 34. In the case of the present embodiment, the VF 32 corresponds to a virtual NIC. The VF 32 is recognized as a PCI device by the virtual machine 12. That is, in this embodiment, the virtual machine 12 recognizes the VF 32 as a virtual NIC (VF 321). Therefore, when the PF 34 is linked down, the virtual machine 12 cannot access the communication network 90 via the VF 32 (VF 321) sharing the resource of the PF 34.

  The virtual computer 12 includes a virtual CPU 323 and a virtual memory 322 which are virtual resources (hereinafter referred to as “virtual resources”). These virtual resources are realized by the hypervisor 11 assigning resources of the physical computer 10. On the virtual machine 12, a guest OS 13 is executed. That is, the guest OS 13 recognizes the virtual resource of the virtual machine 12 as a normal resource. Therefore, the guest OS 13 can access the communication network 90 via the VF 321 (VF 32).

  The hypervisor 11 is a kind of virtualization mechanism, and allocates logical resources obtained by logically dividing the physical CPU 41 and the physical memory 42 to the virtual machine 12 as virtual resources. Thereby, the virtual machine 12 is realized. The hypervisor 11, which is a kind of virtualization mechanism, may be software that operates on the physical computer 10, may be hardware included in the physical computer 10, or may be a device different from the physical computer 10. Or a combination thereof.

  The hypervisor 11 includes a PF monitoring unit 101, a VF MMIO emulation unit 102, a logical CPU interrupt handler 103, and a mode switching unit 104. Further, the hypervisor 11 includes a monitoring target device management table 300 and a PF link state management table 200.

  The PF monitoring unit 101, the mode switching unit 104, and the VF MMIO emulation unit 102 can also be realized by hardware by integrating them as processing units for performing each process. In the following description, when a computer program is the subject, it is assumed that processing is actually performed by a CPU that executes the computer program. When each processing unit is realized by hardware, each processing unit mainly performs each process. In the following description, various types of information may be described using the expression “xxx table”, but the various types of information may be expressed using a data structure other than a table. In order to show that it does not depend on the data structure, the “xxx table” can be called “xxx information”. Hereinafter, the tables 200 and 300 and the units 101 to 104 will be described.

FIG. 5 shows a configuration example of the monitoring target device management table 300.
The monitoring target device management table 300 manages the SR-IOV compatible device 30 having the PF 34 that needs to be monitored by the hypervisor 11 as an entry.

  The monitored device management table 300 includes an entry number 301, a vendor ID 302, a device ID 303, a subsystem vendor ID 304, and a subsystem device ID 305 as fields. That is, the monitoring target device management table 300 has different combinations of IDs for each type of PCI device.

  For example, in FIG. 5, an entry 300 with an entry number “0” is a device with a vendor ID “0xAAAA”, a device ID “0xBBBB”, a subsystem vendor ID “0xCCCC”, and a subsystem device ID “0xDDDD”. Correspond.

  The hypervisor 11 refers to the PCI configuration 51 and identifies the type of device having a combination of the vendor ID, device ID, subsystem vendor ID, and subsystem device ID that matches the entry 300 of the monitored device management table 300. The PF 34 related to the specified device type is set as a monitoring target.

  The monitoring target device management table 300 may be set in the hypervisor 11 in advance, or may be automatically generated by a predetermined process when the hypervisor 11 is activated.

FIG. 6 shows a configuration example of the PF link state management table 200.
The PF link state management table 200 manages the current link state of the PF 34 as an entry 210.

  The PF link state management table 200 includes an entry number 201, a segment number 202, a bus number 203, a device number 204, a function number 205, and a PF link state 206 as fields.

  A number obtained by combining the segment number 202, the bus number 204, the device number 204, and the function number 205 may be referred to as a “device identification number”. That is, one entry 210 corresponds to one PF 34.

  The PF link state 206 indicates whether the current link state of the PF 34 is “link up” or “link down”. For example, the case where the PF link state 206 is “1” may be “link up”, and the case where it is “0” may be “link down”. The PF link state 206 is appropriately updated as the link state of the PF 34 changes.

  The hypervisor 11 manages the link state of a certain PF 34 specified based on the type of PCI device entered in the monitored device management table 300 using the PF link state management table 200.

  For example, in FIG. 6, the entry 210 with the entry number “0” has the PF link state of the PF 34 with the segment number “0x0”, the bus number “0xaa”, the device number “0xa”, and the function number “0x0”. Indicates “link up”. Returning to the description of FIG.

  The PF monitoring unit 101 monitors the PF 34 stored in the PF link state management table 200. That is, the PF monitoring unit 101 acquires the link status of each PF 34 stored in the PF link status management table 200 at a predetermined timing (for example, at intervals of 1 second). Then, the PF monitoring unit 101 stores the acquired link state (that is, link up or link down) in the PF link state 206 of the entry 210 corresponding to the PF 34. Here, when a change in the PF link state 206 is detected, the PF monitoring unit 101 requests the mode setting unit 104 to switch the mode.

  For example, when it is detected that the PF link state 206 has changed from “link up” to “link down”, the PF monitoring unit 101 requests the mode setting unit 104 to switch to “emulation mode”.

  For example, when it is detected that the PF 34 link state 206 has changed from “link down” to “link up”, the PF monitoring unit 101 requests the mode setting unit 104 to switch to the “pass-through mode”. Details of each mode will be described later.

  The mode switching unit 104 sets an operation mode related to the VF 32 in the hypervisor 11. When the mode switching unit 104 receives a request to switch to the “pass-through mode” from the PF monitoring unit 101, the mode switching unit 104 sets the hypervisor 11 to operate in the pass-through mode (first mode).

  For example, the mode switching unit 104 sets the Valid bit corresponding to the MMIO (Memory-Mapped I / O) area related to the VF32 of the page table 52 of the physical memory 42 to “ON”. As a result, the guest OS 13 can access the VF 32 as in the conventional case.

  When the mode switching unit 104 receives a request to switch to the “emulation mode” from the PF monitoring unit 101, the mode switching unit 104 sets the hypervisor 11 to operate in the emulation mode (second mode).

  For example, the mode switching unit 104 sets the Valid bit corresponding to the MMIO area related to the VF32 of the page table 52 of the physical memory 42 to “OFF”. In this case, when the guest OS 13 accesses the VF 32, a page fault (error) occurs. In other words, it can be said that a page fault is intentionally generated in the emulation mode.

  This page fault is notified from the physical computer 10 to the hypervisor 11 as an interrupt. The logical CPU interrupt handler 103 traps this page fault interrupt notification.

  When the logical CPU interrupt handler 103 traps the page fault interrupt notification from the physical computer 10, it issues an emulation request to the VF MMIO emulation unit 102. As described above, this page fault interrupt notification occurs when the emulation mode is set by the mode switching unit 104.

  The VF MMIO emulation unit 102 emulates the VF32. The VF MMIO emulation unit 102 emulates the VF 32 by acting as if the guest OS 12 accessed the VF 32 of the SR-IOV compatible device 30 in response to the access to the VF 321 from the guest OS 13. That is, the guest OS 12 cannot distinguish whether the VF 32 included in the SR-IOV compatible device 30 is accessed or whether the VF emulated by the VF MMIO emulation unit 102 is accessed.

  When the access VF MMIO emulation unit 102 receives an emulation request from the logical CPU interrupt handler 103, the access VF MMIO emulation unit 102 stores a response to access (command) to the VF 32 from the guest OS 13 (hereinafter referred to as “VF response storage area”). ) Stores that the VF 32 is in the link down state. Then, the VF MMIO emulation unit 102 issues a completion notification (virtual I / O interrupt notification) for access to the VF 32 to the guest OS 13. Accordingly, when the PF 34 is linked down, the guest OS 13 can correctly recognize that the VF 32 is in the link down state.

  Hereinafter, operation examples of the virtual machine system in the “pass-through mode” and the “emulation mode” will be further described with reference to the drawings.

  FIG. 7 is a diagram for explaining an operation example of the virtual machine system in the pass-through mode.

  When the mode switching unit 104 receives a request to switch to the “pass-through mode” from the PF monitoring unit 101, the mode switching unit 104 sets the valid bit 63 corresponding to the MMIO area related to the VF32 of the page table 52 of the physical memory 42 to “ON” ( S1101).

  For example, the guest OS 13 writes a command for acquiring the link status of the VF 32 (hereinafter referred to as “VF link status acquisition command”) in the command I / F register 61 of the SR-IOV compatible device 30 (S1102).

  Here, since the Valid bit 63 is “ON”, the writing of the VF link state acquisition command is successful.

  The SR-IOV compatible device 30 writes the link status of the VF 32 in the VF response storage area 62 based on the VF link status acquisition command written in the command I / F register 61 (S1103). In this embodiment, the pass-through mode is entered when the link state of the PF 34 is “link up”. Therefore, here, the SR-IOV compatible device 30 is in the VF response storage area 62 and the VF 32 is in the “link up state”. Write a message to that effect. The VF response storage area 62 may exist in the physical memory 42 or may exist in another storage area.

  Then, the hypervisor 11 receives the command completion notification issued by the physical computer 10, and notifies the guest OS 13 (virtual I / O interrupt notification) (S1104).

  Upon receiving this command completion notification, the guest OS 13 acquires the link status of the VF 32 from the VF response storage area 62 (S1105). As a result, the guest OS 13 recognizes that the VF 32 is in the “link up state”.

  Here, if the virtual machine system changes the link state of the PF as described in the above problem from “link up” to “link down”, the link state of the VF corresponding to the PF is changed to “link”. It is assumed that an SR-IOV compatible device responding “Up” is provided. When the link state of the PF is “link down”, the SR-IOV-compatible device writes in step S1103 that the VF is “link up state” in the VF response storage area. For example, when the SR-IOV device is designed to continue communication between VF even when the PF is linked down. In this case, the guest OS erroneously recognizes that the VF 32 corresponding to the PF 34 is in the “link up state” even though the PF is “link down”.

  However, since the virtual machine system according to the present embodiment operates in the next emulation mode when the link state of the PF 34 is “link down”, such erroneous recognition does not occur.

  FIG. 8 is a diagram for explaining an operation example of the virtual machine system in the emulation mode.

  When the mode switching unit 104 receives a request to switch to the “emulation mode” from the PF monitoring unit 101, the mode switching unit 104 sets the valid bit 63 corresponding to the MMIO area related to the VF32 of the page table 52 of the physical memory 42 to “OFF” ( S1201).

  The guest OS 13 tries to write the VF link status acquisition command of VF32 into the command I / F register 61 (S1202). However, since the Valid bit 63 is “OFF”, the access of this VF link state acquisition command fails.

  Therefore, the physical computer 10 issues a page fault interrupt notification to the hypervisor 11 (S1203).

  When detecting the page fault interrupt notification, the logical CPU interrupt handler 103 issues an emulation request to the VF MMIO emulation unit 102 (S1204).

  When the command from the guest OS 13 is the VF link state acquisition command, the VF MMIO emulation unit 102 writes in the VF response storage area 62 that the VF 32 is “link down state” (S1205).

  Then, the VF MMIO emulation unit 102 issues a command completion notification (virtual I / O interrupt notification) to the guest OS 13 (S1206).

  Upon receiving this command completion notification, the guest OS 13 acquires the link status of the VF 32 from the VF response storage area 62 (S1206). Thereby, the guest OS 13 can correctly recognize that the link state of the VF 32 is the “link down state”.

  According to the above-described configuration, the guest OS 13 can be made to correctly recognize the link state of the VF 32 without modifying the SR-IOV compatible device 30 (substantial modification). Further, it is possible to make the guest OS 13 recognize the correct link state of the VF 32 without modifying the virtual machine 12 and / or the guest OS 13. That is, even when the physical computer 10 includes the SR-IOV compatible device 30 that cannot correctly reflect the link state with the PF 34 so that the link state of the VF 32 may be different, the problem is absorbed in the hypervisor 11. Can do. Next, details of processing of each means will be described with reference to the drawings.

  FIG. 9 is a flowchart illustrating an example of a process for creating the PF link state management table 200. The creation process of the PF link state management table 200 may be executed when the hypervisor 11 is activated.

  The PF monitoring unit 101 determines whether or not an unconfirmed device remains in the virtual machine system (S101). If no unconfirmed device remains (S101: NO), the PF monitoring unit 101 ends the process (END).

  When an unconfirmed device remains (S101: YES), the PF monitoring unit 101 selects one of the unconfirmed devices (S102). Then, the PF monitoring unit 101 refers to the PCI configuration 51 of the selected unconfirmed device and specifies device identification information of the device (S103).

  The PF monitoring unit 101 determines whether the specified device identification information matches any entry 310 in the monitoring target device management table 300 (S104).

  When the device identification information matches any entry 310 in the monitoring target device management table 300 (S104: YES), the PF monitoring unit 101 displays the segment number, bus number, device number, and function number of the PF 34 related to the device. It is identified and registered as a new entry 210 in the PF link state management table 200 (S105). At this time, the PF monitoring unit 101 may set the initial value of the PF link state 206 of the new entry 210 to the “link down state”.

  If the device identification information does not match any entry 310 in the monitoring target device management table 300 (S104: NO), the PF monitoring unit 101 returns to step S101 as it is.

  Through the above processing, the PF 34 related to the device to be monitored is registered in the PF link state management table 200.

  FIG. 10 is a flowchart illustrating an example of a process for detecting a change in the link state of the PF 34. This process may be repeatedly executed while the hypervisor 11 is in operation.

  The PF monitoring unit 101 selects the first entry 210 of the PF link state management table 200 (S201). The PF 34 monitoring unit 101 acquires the link state of the PF 34 related to the selected entry 210 (S202).

  The PF 34 monitoring unit compares the acquired link state with the link state related to the selected entry, and determines whether or not the link state has changed (S203). If the link state has not changed (S203: NO), the PF monitoring unit 101 proceeds to step S210.

  When the link state has changed (S203: YES), the PF monitoring unit 101 rewrites the PF link state 206 of the selected entry 210 with the acquired link state of the PF 34 (S204).

  The PF monitoring unit 101 determines whether or not the acquired link state of the PF 34 is “link down” (S205).

  When the acquired link state of the PF 34 is “link down” (S205: YES), the PF monitoring unit 101 requests the mode switching unit 104 to switch to the “emulation mode” (S207), and the process proceeds to step S210. move on.

  When the acquired link state of the PF 34 is “link up” (S205: NO), the PF monitoring unit 101 requests the mode switching unit 104 to switch to the “pass-through mode” (S206), and the process proceeds to step S210. move on.

  In step S210, the PF monitoring unit 101 determines whether or not an unselected entry 210 remains in the PF link state management table 200 (S210).

  When the unselected entry 210 remains in the PF link state management table 200 (S210: YES), the PF monitoring unit 101 selects the next entry 210 from the unselected entries 210 (S211), and step S202. Return to.

  When the unselected entry 210 does not remain in the PF link state management table 200 (S210: NO), the PF monitoring unit 101 unselects all the entries 210 stored in the PF link state management table 200 (S220). ). The PF monitoring unit 101 waits for 1 second, for example (S211), and then returns to step S201. That is, since the PF monitoring unit 101 has confirmed the link status for all the entries 210 registered in the PF link status management table 200, the PF monitoring unit 101 also checks the link status of each entry from the beginning.

  With the above processing, a change in the link state of the PF 34 registered in the PF link state management table 200 can be detected.

  FIG. 11 is a flowchart illustrating an example of processing in the mode switching unit 104.

  The mode switching unit 104 determines whether the mode switching request (corresponding to steps S206 and S207 in FIG. 10) issued from the PF monitoring unit 101 is a switching request to the pass-through mode or a switching request to the emulation mode. Is determined (S301).

  When the request is for switching to the pass-through mode (S301: pass-through mode), the mode switching unit 104 sets the Valid bit 63 corresponding to the MMIO area related to VF32 of the page table 52 to “ON” (S302). End (END).

  If the request is for switching to the emulation mode (S303: emulation mode), the mode switching unit 104 sets the Valid bit 63 corresponding to the MMIO area related to VF32 of the page table 52 to “OFF” (S303), End (END).

  FIG. 12 is a flowchart illustrating an example of processing in the VF MMIO emulation unit 102.

  As described above, the VF MMIO emulation unit 102 is executed when the Valid bit corresponding to the MMIO area related to VF32 is 63 “OFF”. That is, the VF MMIO emulation unit 102 is executed when the hypervisor 11 is in the emulation mode.

  The VF MMIO emulation unit 102 determines whether or not the command from the guest OS 13 is a write to the command I / F register 61 (S401).

  If the command from the guest OS 13 is not a write to the command I / F register 61 (S401: NO), the VF MMIO emulation unit 102 passes the command from the guest OS 13 through the VF 32 as it is (S420) and ends the processing ( END).

  When the command from the guest OS 13 is writing to the command I / F register 61 (S301: YES), the VF MMIO emulation unit 102 determines whether this command is a VF link state acquisition command (S410). .

  When the command from the guest OS 13 is not the VF32 link state acquisition command (S410: NO), the VF MMIO emulation unit 102 passes the command from the guest OS 13 as it is to the VF32 (S420) and ends the processing (END). That is, this command is written to the command I / F register 61 as usual.

  When the command from the guest OS 13 is the VF32 link state acquisition command (S410: YES), the VF MMIO emulation unit 102 writes in the VF response storage area 62 that the VF32 is in the link down state (S411).

  Then, the VF MMIO emulation unit 102 raises a command completion notification (virtual I / O interrupt notification) to the guest OS 13 (S412), and ends the processing (END). Upon receiving this command completion notification, the guest OS 13 acquires the link state (that is, “link down state”) of the VF 32 from the VF response storage area 62.

  12 and 13, the guest OS 13 can correctly acquire the link state of the VF 32 corresponding to the link state of the PF 34, as shown in FIGS. That is, the guest OS 13 can correctly recognize that the VF 32 is in the link down state when the PF 34 is in the link down state.

  The above-described embodiments are examples for explaining the present invention, and are not intended to limit the scope of the present invention only to these embodiments. Those skilled in the art can implement the present invention in various other modes without departing from the gist of the present invention.

  In the above-described embodiment, the hypervisor 11 detects the link down of the PF 34, writes that the VF 32 is in the link down state in the VF response storage area 62, and the guest OS 13 refers to the VF response storage area 62 to refer to the VF 32. For example, when the hypervisor 11 detects a link down of the PF 34, the hypervisor 11 may notify the guest OS 13 that the VF 32 corresponding to the PF 34 is in the link down state. good.

DESCRIPTION OF SYMBOLS 1 ... Virtual computer system 10 ... Physical computer 11 ... Hypervisor 12 ... Virtual computer 13 ... Guest OS 30 ... SR-IOV corresponding device

Claims (8)

A physical CPU (Central Processing Unit), a physical memory, a SR-IOV (Single Root I / O Virtualization) compatible device, and a virtualization mechanism;
In a virtual machine system in which a guest OS (Operating System) runs on a virtual machine to which logical resources obtained by logically dividing the physical CPU and the physical memory are allocated by the virtualization mechanism,
The SR-IOV compatible device has a PF (Physical Function) that is a physical network device and a VF (Virtual Function) that is a virtual network device corresponding to the PF,
The virtualization mechanism is:
Monitor the link status of the PF,
The first mode is set when the link status of the monitored PF is the link up state, and the second mode is set when the link state is the link down state.
When the second mode is set, the SR-IOV compatible device related to the VF is not responded to the command related to the VF from the guest OS, and the fact that the VF is in the link down state is emulated. Virtual computer system to rate.
2. The virtual device according to claim 1, wherein, when the first mode is set, the virtualization mechanism causes the SR-IOV compatible device related to the VF to respond to the command related to the VF from the guest OS. Computer system.
The virtualization mechanism, when the second mode is set,
When the command related to the VF from the guest OS is a command for obtaining the link status of the VF, the SR-IOV compatible device related to the VF is not responded and the fact that the VF is in the link down status is emulated. Rate and
3. The virtual machine system according to claim 2, wherein, when the command related to the VF from the guest OS is not a command for acquiring the link state of the VF, the virtual machine system according to claim 2 is caused to respond to the SR-IOV device related to the VF.
The setting of the second mode is to set the processing of the command related to the VF from the guest OS to be an error,
4. The virtual computer system according to claim 1, wherein the virtualization mechanism detects an error in processing a command related to the VF and emulates that the VF is in a link down state. 5.
The setting that causes an error in the processing of the command related to the VF means that an MMIO (Memory-Mapped I / O) area related to the VF is set in the physical memory so that the SR-IOV compatible device related to the VF does not respond. The virtual computer system according to claim 4, wherein a flag referred to for identification is set to a state in which reference is impossible.
A virtual memory of a virtual machine to which a logical resource obtained by logically dividing physical memory by the virtualization mechanism is allocated, and a response to a command related to a VF from the guest OS is stored in an area on the virtual memory Is supposed to
Emulation that the VF is in a link-down state means that the VF is linked down to an area on the physical memory corresponding to an area on the virtual memory in which a response to a command related to the VF from the guest OS is stored. The virtual machine system according to claim 1, wherein a state information is written.
The virtualization mechanism monitors a PF link state of an SR-IOV-compatible device set as a monitoring target, and changes a mode setting when a change in the link state of the PF is detected. The virtual computer system according to any one of the above.
A physical CPU (Central Processing Unit), a physical memory, a SR-IOV (Single Root I / O Virtualization) compatible device, and a virtualization mechanism;
In a virtual machine system in which a guest OS (Operating System) runs on a virtual machine to which a logical resource obtained by logically dividing a physical CPU and a physical memory is allocated by the virtualization mechanism,
The SR-IOV compatible device has a PF (Physical Function) that is a physical network device and a VF (Virtual Function) that is a virtual network device corresponding to the PF,
In the virtualization mechanism, the link status of the PF is monitored, the first mode is set when the link status of the monitored PF is a link-up status, and the second mode is set when the link-down status is set, When the second mode is set, the SR-IOV compatible device related to the VF is not responded to the command related to the VF from the guest OS, and the fact that the VF is in the link down state is emulated. A method for controlling an SR-IOV compatible device to rate.

Images