Mechanism for controlling external interruptions in virtual machines system

FIELD: computer science.

SUBSTANCE: method includes recognizing interruption awaiting processing during operation of software of guest; it is determined, whether interruption is controlled by guest software; if guest software does not control interruption, it is determined, whether virtual machines monitor is ready to take control; and control is transferred to virtual machines monitor, of its is; in opposite case, if software of guest controls interruption, it is determines, whether guest software of guest is ready to receiver interruptions, and interruption is transferred to guest software, if guest software is ready.

EFFECT: higher efficiency.

3 cl, 6 dwg

Background of the invention

In a typical computer system device to request service from the system software through the generation of interrupt requests that are sent to the interrupt controller through many lines of IRQs. As soon as the interrupt controller identifies the active line of the interrupt request, it sends an interrupt signal to the processor. In response logic interface interrupt controller in the CPU determines whether software interrupt. If the software is not ready for receiving the interrupt, the interrupt is supported in a wait state processing up until the software is ready to receive. Once it is determined that the software is ready, the logic controller interface interrupt requests to the interrupt controller to notify which of the pending interrupt has the highest priority. The interrupt controller assigns priorities to different lines of the interrupt request and identifies the interrupt request of highest priority for the processor, which then translates the control flow in the code that handles this interrupt request.

In a conventional operating system (OS) all interrupts are controlled by a single entity, known as the OS kernel. In the system a virtual who's machine monitor (control program) virtual machine (MVM) must maintain ultimate control over the various operations and events arising in the system to ensure proper operation of virtual machines and for protection of virtual machines and mutual protection between them. To achieve this, MWM in a typical case takes control when the software of the client (the user who does not have a user account or password) gets access to hardware resources or explain the occurrence of some event, such as an interrupt or exception. Accordingly, in the system virtual machine interrupts in a typical case managed by MWM.

In particular, when the operations in the virtual machines supported by MBM, cause the interrupt generation units in the system, MWM performs the role of mediator between the virtual machine and interrupt controller. That is, when the interrupt signal, functioning in the current virtual machine is interrupted, and the control processor proceeds to MBM. Then MWM accepts the interrupt, performs any necessary operations for interrupt controller and handles the interrupt or delivers the interrupt to the appropriate virtual machine.

Brief description of drawings

The present invention is illustrated, for example, but not as limitations on the drawings, in which identical reference position related to kindred the m elements and which represent the following:

Fig. 1 is a variant of the implementation environment of virtual machines, which can be implemented in the invention;

Fig. 2 is a block diagram of a variant of implementation of the system for processing interrupts in a virtual machine environment;

Fig. 3 is a block diagram of the algorithm is a variant of the process interrupt in the system virtual machines.

Fig. 4 is a block diagram illustrating the interrupt processing in the system virtual machines, with a preferred virtual machine, according to a variant implementation of the present invention;

Fig. 5 is a block diagram of a variant of the implementation process interrupts that occur when working bit virtual machine, and

Fig. 6 is a block diagram of a variant of the process interrupt in the system virtual machines without preferred virtual machine.

Description of embodiments

The described method and device to control external interrupts in the system virtual machines. In the following description for purposes of explanation outlined numerous specific details to provide a thorough understanding of the present invention. However, to a person skilled in the art it is obvious that the present invention can be implemented without these specific details.

Some parts of the following detailed description presented in term of the algorithms and symbolic representations of operations on data bits in registers or memory of the computer system. These algorithmic descriptions and representations are the means used by specialists in the field of data processing for more efficient transmission of the essence of their work to other specialists in this field of technology. The algorithm discussed here, and in principle, as a self-consistent sequence of operations leading to a desired result. Operations represent the required physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals, on which can be carried out actions for the preservation, migration, aggregation, comparison, and other manipulations. It is sometimes convenient, principally for reasons of General use to refer to these signals as bits, values, elements, symbols, characters, terms (components), numbers and the like.

However, it should be borne in mind that all of these or similar terms should be associated with the appropriate physical quantities and are merely a convenient notation for these quantities. Unless specifically stated otherwise, as apparent from the following description, it is clear that throughout the description, discussions using terms such as "processing", "computing", "calculating", "determining" or the like may refer to actions the pits and processes of a computer system or similar electronic computing device, which manipulates the data and transforms data represented as physical (electronic) quantities within the registers and memory of the computer system into other data similarly represented as physical quantities within the registers and memory of the computer system, or other such units of information storage devices, transmission and display.

In the following detailed description of embodiments of the invention, reference is made to the drawings which show to illustrate specific embodiments of which the invention may be implemented. In the drawings, the same reference positions indicated essentially similar components in the various views. These implementation options are described in sufficient detail to enable specialists in the art to implement the invention. Can be used and other ways of implementation, and there may be changes in the structure, logic means and electronic means without deviating from the scope of the present invention. In addition, it should be borne in mind that various embodiments of the invention, although different, but they are not necessarily mutually exclusive. For example, a particular feature, structure or characteristic described in one embodiment, to implement the Oia, can be included in other versions of the implementation. Therefore, further detailed description should not be construed in a restrictive sense and the scope of invention is defined only by the claims, along with the full scope of equivalents, which are subject to these items.

Fig. 1 illustrates an implementation option environment 100 virtual machines, which can be implemented in the present invention. In this embodiment, the minimum hardware ("empty" hardware, without software) 116 include a computer platform that has the ability, for example, to perform a standard operating system (OS) or a virtual machine monitor (MBM), such as MWM 112. MWM 112, although in a typical case, is implemented by software that can emulate and export interface is empty (without software) of the machine to higher-level software. Such software is of a higher level can contain standard operating system or real-time operating system, can be an empty (blank) operating environment with limited functionality operating system may not include traditional OS functions etc. Alternative, MWM 112 can be performed inside or on top drugog the MWM. MWM and their typical features and functionality are well known to experts in the art and may be implemented, for example, hardware, software, firmware, hardware (built-in, hardcoded software) or a combination of various methods.

Hardware platform 116 may be a personal computer (PC), a universal computing machine, a portable device, handheld device, computer console to a TV or any other computer system. Hardware platform 116 includes a processor 118 and a memory 120.

The processor 118 may be any type of processor that can execute software, such as a microprocessor, digital signal processor, a microcontroller, and the like. The processor 118 may include firmware (microcode), programmable logic or hard-coded logic to implement the execution of embodiments of the method according to the present invention. Although in Fig. 1 shows only one such processor 118, the system may have one or more processors.

The memory 120 may be a hard disk, floppy disk, random access memory (RAM), read-only memory (ROM), flash memory, any combination of the set is built above devices, or any type of machine carrier, read by the processor 118. The memory 120 may store instructions and/or data for performing embodiments of the method of the present invention.

MWM 112 is other software (for example, software guest) the abstraction of one or more virtual machines (VMS)that can provide the same or different abstractions for different users-guests. In Fig. 1 shows two virtual machines 102 and 114. Software guest performed on each virtual machine may include a guest OS, such as OS 104 and 106 guests, and various applications 108 and 110 software features. Each of the OS 104 and 106 offers access to physical resources (e.g., processor registers, memory devices, input/output) in the VMS 102 and 114, which marks the OS 104 and 106 guests, and handle various events, including interrupts generated by devices in the system in the process VMS 102 and 114.

In one embodiment, the interrupt is generated during operation of the VM 102 or 114 may be classified as "privileged" event or "unprivileged" event. For preferred events MWM 112 provides the functionality required software guest, while retaining ultimate control over those who privilegirovanniy events. Unprivileged events do not require treatment MWM 112 and managed software for customers.

In one embodiment, interrupts are classified as privileged or unprivileged based on the current value of pointer management interrupt. Control pointer interrupt determines whether managed by interrupt software guest or MBM 112.

In one embodiment, one pointer management interrupt (for example, one bit) is used for all interrupts. In another embodiment, a separate control pointer interrupt is used for each type of interrupt (for example, the number of interrupts). For example, in the architecture of the installation instructions Pentium IV (hereinafter referred to as IA-32 ISA) may be 256 pointers management interrupt (for example, 256 bits), one for each possible type masked interrupt hardware. In other embodiments, the implementation of separate pointers to the interrupt handling can be used to group types of interrupts, or for any other combination of interrupt.

The indicator (s) of the interrupt handling in a typical case is not available and/or cannot be modified VMS 102 and 114. In one embodiment, MWM 112 sets the value (s) pointer (ukazatel the th) management interrupt before transferring control to the VM 102 or 114. Alternatively, each of the VM 102 or 114 is associated with a different pointer (set of pointers) management interrupt, which set(s) at a predetermined (defined) value (s).

In one embodiment, one or more pointers control the interrupts stored in the structure of the virtual machine management (SUWM) 122, which may reside in memory 120 (as shown in Fig. 1) or, alternatively, a processor 118, a combination of memory 120 and processor 118, or in any other location or locations in memory. Various software guest can be controlled using the data from the different views SUUM, although only one such SUWM shown in Fig. 1. It should be noted that any other data structure (e.g., a built-in cache, file, remap table, etc. can be used to save the indicator (s) of the interrupt handling without loss of generality. The indicator (s) of the interrupt handling can be a bit field in the control vector or it can be a bit or a bit map stored in a separate field SUWM.

Alternatively, in one embodiment, one or more pointers to the interrupt handling is stored in one or more registers of the machine or in the memory 120.

E is whether an interrupt is generated during operation of the software guest it is an appeal to the appropriate pointer management interrupt to determine whether the interrupt is controlled by the software for customers. If the result of this determination is positive, then the interrupt is controlled by the software for customers. Otherwise, the interrupt is controlled by MWM 112.

In one embodiment, if the interrupt is managed by MWM 122, the control is transferred to MBM 112. Transfer of control between the VM 102 or 104 and MBM 112 is implemented by any mechanism known from the prior art. Processing the interrupt, after the control is transferred to MBM 112, described in more detail below.

In one embodiment, if the interrupt is controlled software, guest management is reserved for software customers. The interrupt is delivered to the software of the guest, if the current executable software is ready to receive interrupts, as described in more detail below.

In Fig. 2 shows a block diagram of a variant of implementation of the system 200 for processing interrupts in a virtual machine environment.

According Fig. 2, the device 214 (e.g., input/output) request services from the software system by the generation of interrupt requests that are passed to the controller 212 interrupt for one or more lines 216 interrupt request. As soon as the controller 212 interrupt identifies the active line 210 interrupt request, it sends a signal 210 interrupts the Central processing unit (BSC) 202. In a possible embodiment, there may be more than one line 210 alarm interrupt to the CDC 202 or, alternatively, a "signal" interrupt may be delivered via a message sent over the bus, or through any other mechanism or communication Protocol.

In response to an active signal 210 interrupt from controller 212 abort logic 204 interface interrupt controller determines what software manages the interrupts. If the interrupt occurs in the process of MBM, the interrupt is controlled by MWM unconditional way. Alternatively, if an interrupt occurs during the operation of the software of the guest logic 204 interface interrupt controller determines whether to control the interrupt software guest or MBM.

This definition depends on the current value of the pointer control interrupt stored in one of the embodiments, in SUWM 208. Control pointer interrupt determines whether the software of the visitor or MBM to control the interrupt. As described above, one or more pointers to the interrupt handling can COI is to Lisovets for interrupts. If more than one pointer interrupt handling, access a specific index management interrupt associated with the processed interrupt.

If the pointer control interrupt determines that the interruption must be managed software the guest, the logic 204 interface interrupt controller next determines whether the software of the guest to the reception interrupt. In one embodiment, the logic 204 interface interrupt controller makes this determination after checking the flag 206 interrupts, which may be updated by the software of the guest when the software status of the guest, pointing to its ability to accept interrupts, changes. For example, in the IA-32 ISA EFLAGS register contains a bit flag interrupt IF that, in particular, controls whether the interrupt is delivered to the software (other factors can block interrupts in the IA-32 ISA, and these factors should be considered when determining whether the interrupt is to be delivered). Flag 206 interrupt is CDC 202 outside or inside logic 204 interface interrupt controller. Alternatively, any other mechanism known in the prior art, can be used to determine whether programme the e provision to accept interrupts.

If the logic 204 interface interrupt controller determines that the software is guest ready to accept the interrupt, it queries the controller 212 interrupt to identify which of the interrupts that are pending, has the highest priority, and delivers the interrupt with the highest priority in software guest, causing a transfer of control flow at the beginning of the code interrupt processing associated with the software for customers. Otherwise, if the software guest is not ready at the moment to accept the interrupt, the interrupt remains pending processing as long as the software is a guest will not be ready for his reception.

If the pointer control interrupt determines that MBM controls the interrupt, then, in one embodiment, the logic 204 interface controller interrupt starts the transfer of control to MBM.

In another embodiment, the transfer of control to MBM due to the current flag value transfer interrupt, referred to here as a control flag interrupt (CFP). Thus, the logic 204 interface controller interrupt first analyzes the current value KFP to determine whether the receive interrupt-driven MWM, to cause transfer of control to MBM. CFP acts in the same is the procedure, as the flag 206 interrupt indicates whether the interrupt cause translations for MWM. In a possible embodiment, CFP is SUWM 208 and managed by MWM. In another embodiment, CFP is in register or in memory in the machine. If the FMC does not require transfer of control, the interrupt will be maintained in the idle state processing, and will transfer control. Otherwise, the logic 204 interface interrupt controller starts the transfer control on MBM.

In one embodiment, many CFP supported for interrupts with different characteristics, and CFP that should be used for a particular interrupt is selected from these CFP on the basis of the characteristics of the interruption.

When you want to transfer control to MWM, in one embodiment, the interrupt is maintained in the standby state of the processing in the controller 212 interrupt after transferring the management on MBM. In this embodiment, the identifier of the source of the interrupt (for example, you can reference vector in the IA-32 ISA), which, in particular, identifies the device generating the interrupt may be unknown for MBM in the time immediately following the transfer of control. As part of the procedure of transfer of control, the processor clears the flag 206 Prieur is a cation, which is active after the transfer. Following the transfer of control MWM can use the flag 206 interrupt for release interrupt and ensure delivery of interrupts. MBM can define a vector of pending interrupts using any mechanism known in the prior art. For example, in the IA-32 ISA each interrupt vector is processed uniquely to a specific interrupt handler, thereby identifying an interrupt vector when an interrupt is delivered to MBM.

In another embodiment, the ID of the interrupt source known in the controller 212 interrupts before transferring control to the MBM. In this embodiment, the interrupt may be delivered to MBM data, determining the identifier of the source of the interrupt. For example, data can be delivered in the field in SUWM.

In Fig. 3 presents a block diagram of a possible form of implementation of a process 300 for processing interrupts in the system virtual machines. The process may be performed by processing logic that may include hardware (e.g., charts, dedicated logic, programmable logic, microcode, and so on), software (e.g., executing on the mainframe computer system or on a dedicated machine), or a combination of the other.

According Fig. 3, process 300 begins with processing logic identifies the presence of a pending interrupt processing (block 302 processing) and determines whether the interrupt during the operation of MBM or software guest (block 304 decision).

If the interruption occurred during the MWM, then processing logic determines if you are ready MWM for the reception of the interrupt (block 306 decision). If the result of determination is positive, processing logic delivers the interrupt to the MWM (block 308 processing). If the result of determination is negative, then processing logic does not deliver the interrupt to the MBM, leaving the interrupt pending (processing block 316 processing). In one embodiment, processing logic uses the flag of the interrupt (for example, interrupt flag, referred to as EFLAGS.IF in the IA-32 ISA) to determine if you are ready MWM to receive interrupts.

If the result of determination in block 304, the decision is negative, that is, an interrupt has occurred during the operation of the software guest, the processing logic further determines, controls whether the software guest interrupt (block 310) decision. This definition depends on the index of the interrupt handling. In one embodiment, the pointer control interrupt is set is carried out by MWM every time when MBM takes control software for customers. As described above, there may be one or more pointers to the interrupt handling, the choice of a specific index management interrupt is determined by the interrupt vector, or according to other criteria. In one embodiment, each virtual machine has a separate control pointer interrupt. If you use more than one pointer management interrupt, you are accessing the pointer control interrupt associated with the processed interrupt.

If the pointer control interrupt determines that the software guest controls the interrupt, processing logic attempts to deliver the interrupt to the software by guest execution units 306, 308 and 316 processing, as described above.

In one embodiment, if the pointer control interrupt determines that the software does not control the interrupt, the processing logic takes into account the flag of translation termination, referred to here as a control flag interrupt (CFP), and decides on the basis of its content (block 314 decision). If CFP indicates that MBM is not ready to receive transfer control due to interrupts, the interrupt is supported in standby treatment is (block 316 processing), and management remains for software customers. Otherwise, processing logic transfers the management of MBM (processing block 318).

In another embodiment (not shown) CFP not in use, and transfer of control is of course after you determine that the interrupt is controlled by MBM.

During the transfer of control to MVM interrupt flag can be set to a predetermined value is left unmodified or updated in accordance with some other mechanisms. Following the transfer of control to MBM processing logic executes the blocks 306, 308 and 316 processing, as described above.

As described above, after the transfer of control to MWM (block 318 processing) an interrupt can be maintained pending processing in the interrupt controller. If the ID of the interrupt source is known, then processing logic may attempt to deliver the interrupt to the MWM data, determining the source of the interrupt.

In one embodiment, if the termination is maintained in the standby state of the processing in the interrupt controller after the transfer of control to the LCP, LCP updates the interrupt flag when it becomes ready to receive interrupts. MBM can then handle the interrupt. Alternatively, MBM can assess the nature of the interrupt for the determining, what a virtual machine is assigned to process this interrupt emulates the delivery of interrupts assigned to the virtual machine and move the control on the designated virtual machine, as described in more detail below.

In another embodiment (not shown), processing logic does not deliver the interrupt to the MBM. Instead, processing logic provides the information about the interrupt for the MWM (for example, either in response to a request MWM, either as part of the information held by MVM when transferring control to MWM). Based on this information MBM determines which virtual machine is assigned to process the interrupt, and either transfers control to the virtual machine (which will be delivered to the interrupt, as described above), or emulates the delivery of the interrupt to the virtual machine and then transfers control to the virtual machine.

Note that while an interrupt is pending, the process 300 will be continuously repeated as long as the interrupt will not be delivered to MBM or software guest or the interrupt is no longer pending processing.

In one embodiment, the virtual machine system includes a preferred virtual machine and one or more non-preferred virtual machines. Predpochtitel the Naya virtual machine is designed to handle all interrupts, generated by the devices in the system. Preferred virtual machines are designed to perform operations other than the interrupt processing (for example, various computing, encryption, decoding, and so on). In Fig. 4 shows a block diagram illustrating the interrupt processing in the system virtual machines, with a preferred virtual machine, in accordance with one embodiment of the present invention.

According Fig. 4, VM 404 is preferred virtual machine that manages all interrupts in the system 400. VM 406 is preferred virtual machine that manages the operations that do not involve handling of interrupts in the system 400. Although in Fig. 4 shows only one preferred VM (for example, VM 406), the system may have more than one bit VM. MWM 402 knows that VM 404 is preferred virtual machine. When transferring control to VM 404 MWM 402 sets the pointer management interrupt (or each of multiple pointers management interrupt) to a value indicating that VM 404 manages all interrupts. Then, when the interrupt occurs during work VM 404, the logic interface interrupt controller considers appropriate control pointer interrupt, determines that the interrupt control is aetsa through VM 404, and delivers the interrupt to VM 404 when VM 404 is ready to receive interrupts.

When transferring control to VM 406 MWM 402 sets the pointer management interrupt (or each of the pointers management interrupt) to a value indicating that VM 406 does not control any interruptions. Then, when the interrupt occurs during work VM 406, the logic interface interrupt controller considers appropriate control pointer interrupt, determines that VM 406 does not control interrupt, and starts the transfer control MWM 402. Additionally, in one embodiment, during the transfer of control to MBM 402 logic controller interface interrupt sets the interrupt flag to a value indicating that all interrupts are masked (for example, setting the interrupt flag to 0), thereby preventing the delivery of interrupts to MBM 402. In another embodiment, the interrupt flag can be set to a predetermined value or a value read from the structure of the virtual machine management (SUWM). When control is transferred to MBM 402, MWM 402 is notified that the reason for this translation is the interrupt pending processing. MWM 402, knowing that all interrupts must be processed through VM 404, modifies pointer (pointers) management interrupt, provided the first opportunity VM 404 to control all interrupts and switches control to VM 404. If, after VM 404 took control, interrupt flag indicates that VM 404 is ready to receive interrupts, the logic interface interrupt controller retrieves the interrupt with the highest priority of the interrupt controller and delivers the interrupt with the highest priority in VM 404. Otherwise VM 404 updates the flag of the interrupt as soon as it is ready to receive interrupts. When VM 404 is ready to receive the interrupt logic interface interrupt controller retrieves the interrupt with the highest priority of the interrupt controller and delivers the interrupt with the highest priority in VM 404.

In another embodiment, the control flag interrupt (CFP) is taken into account before transferring control to MBM from VM 406, as described above with reference to Fig. 3.

In Fig. 5 presents a block diagram of one possible implementation of a process 500 of handling interrupts, occurring in the process bit virtual machine. The process may be performed by processing logic that may include hardware (i.e. schema, dedicated logic, programmable logic, microcode, and so on), software (such as sung on the mainframe computer system or on a dedicated machine), or a combination of both.

According Fig. 5,process 500 begins with what processing logic identifies and processes the event pending interrupts during operation preferred virtual machine (for example, as shown in Fig. 3), causing a transfer of control to MWM (block 502 processing). Then MBM calls preferred virtual machine and sets the pointer management interrupt to a value that allows the preferred virtual machine to manage the interrupt (block 508 processing).

Once called the preferred VM, if the interrupt is still pending processing (block 510), then processing logic determines whether the preferred virtual machine to receive the interrupt (i.e. considers flag interrupt and/or status of the other machines to determine whether it is that interrupts are not masked) (block 514 decision). If the result of this determination is positive, processing logic delivers the interrupt to the software of the guest (block 518) processing. If it is not ready to accept interrupts, the interrupt is supported in standby processing (block 516 processing), and readiness assessment is repeated (return to block 510 processing).

In one embodiment, MWM not unmask (not shown) interrupts at any given time (i.e. it does not change the interrupt flag to show that the n can be interrupted). In another embodiment (not shown) MBM can unmask interrupts. If an interrupt is pending processing when MBM executes the program and the interrupt is not masked by the interrupt flag, the interrupt will be delivered to MBM. MWM emulates the delivery of interrupts on the preferred VM when it is ready to receive interrupts, and switches control to the preferred VM.

In Fig. 6 presents a block diagram of one possible implementation of a process 600 of processing interrupts in the system virtual machines, where interrupts can be handled by more than one virtual machine or MBM. The process may be performed by processing logic that may include hardware (i.e. schema, dedicated logic, programmable logic, microcode, and so on), software (such as sung on the mainframe computer system or on a dedicated machine), or a combination of both.

According Fig. 6, process 600 begins, after the logic (in block 602 processing) or delivered to interrupt MWM (e.g., as in block 308, the processing in Fig. 3), or has transferred the management of MBM due to the presence of a pending interrupt processing (e.g., as in block 318, the processing in Fig. 3).

Then processing logic in the MWM specifies the source ID perawan is I (block 606 processing). For example, in one embodiment, MBM can perform various operations with memory or input/output for receiving the identifier of the source of the interrupt (for example, vector) from the interrupt controller or input/output. In other embodiments, the implementation in which the interruption is maintained in the standby state of the processing in the interrupt controller after transferring MBM due to a pending interrupt, MBM can unmask interrupts, allowing the processor to deliver the interrupt in MVM. Delivery of interrupts to the MBM can provide information on the source of the interrupt, as described above (e.g., interrupt handler, which delivered an interrupt, can determine the source of the interrupt in the IA-32 ISA). That is, when the interrupt is delivered to MBM or management translated into MBM software from the guest, in view of the pending interrupt processing, MBM may determine that the interrupt is to be handled by a specific virtual machine.

Then MWM determines whether the interrupt can be handled directly using MBM (block 608 processing). The result of this determination may depend on whether initiated interrupt device, which is controlled from MBM or virtual machine (for example, MWM can manage nakopitelya hard disks of all virtual machines while card video capture can be controlled by a specific virtual machine). If the result of determination obtained at block 608 decision is positive, the MWM is servicing the interrupt (block 610 processing) and the process 600 ends.

If the result of determination obtained at block 608 decision is negative, then MWM determines which virtual machine should service the interrupt (block 612 processing). Then, when this virtual machine is ready to receive interrupts, MWM emulates the delivery of the interrupt to the virtual machine and transfers control to the virtual machine (block 614 processing). Thus, the described method and apparatus for processing interrupts in the system virtual machines. It should be borne in mind that the above description is illustrative and not restrictive. Many other variants of implementation will be obvious to a person skilled in the art based on the information received from the above description. Therefore, the scope of the invention should be determined on the basis of the claims, together with the full amount of its equivalents, which are subject to these items.

1. The method for managing interrupts in the system virtual machines, including the stages at which recognize a pending interrupt processing in the process of the work programme the aqueous ensure guest; define controls whether the interrupt software the guest software if the guest does not control the interrupt control is a virtual machine monitor (MBM) to take control, and transfer control to MBM, if MWM is ready to take control, otherwise, if the software manages guest interrupt, determine whether the software guest to accept interrupts, and deliver the interrupt to the software of the guest software if the guest is ready to accept interrupts.

2. The method according to p. 1, wherein the determining controls whether the interrupt software guest, additionally includes the stage at which reading is associated with the interrupt control pointer interrupt.

3. The method according to p. 2, characterized in that the control pointer interrupt is stored in at least one of the following: in the management of virtual machines (SUWM), machine registers and memory.

4. The method according to p. 2, characterized in that the control pointer interrupt choose from a variety of directions of interrupt handling on the basis of the characteristics of the interruption.

5. The method according to p. 1, characterized in that the determination of whether software is a guest to accept interrupts, includes a stage on which the definition is given in the value of the interrupt flag.

6. The method according to p. 1, wherein the determining is mentioned monitor to take control additionally includes the stage at which the read flag of transfer interrupt.

7. The method according to p. 6, characterized in that the flag of transfer interrupt read at least one of the following: structure and manage virtual machines (SUWM), machine registers and memory.

8. The method according to p. 6, characterized in that the flag of transfer interrupt select from a variety of flags of transfer interrupt based on the characteristics of the interruption.

9. The method according to p. 1, characterized in that the software guest is associated with a preferred virtual machine.

10. The method according to p. 9, characterized in that it further includes the steps, which transferred control to MBM, find that the preferred virtual machine is ready to accept interrupts, and deliver the interrupt to the preferred virtual machine.

11. The method according to p. 1, characterized in that it further comprises a stage on which to set the interrupt flag in one of the following values: a value indicating that the MWM is not ready to accept interrupt, a value indicating that MBM is ready to accept interrupts, and the value read from the structure of the management of virtual machines when transferring control to MBM.

12. Spasibo p. 1, characterized in that it further includes the steps, which are determined by MWM virtual machine that is assigned to handle the interrupt, and emulate through MBM delivery interruption in the scheduled virtual machine, if assigned to a virtual machine is ready to accept interrupts.

13. A system for managing interrupts in a virtual machine that contains the interrupt controller intended for receiving interrupts from one or more devices in the system, and the processor associated with the interrupt controller and used for receiving notification of the interrupt from the interrupt controller during operation of the software guest, to determine whether controls whether this interrupt software guest, and, if the software guest does not control interrupt to transfer control to the virtual machine monitor (MBM), if MWM is ready to take control, otherwise, if the software manages guest interruption to delivery interrupt in the software of the guest software if the guest is ready to accept interrupts.

14. The system of item 13, characterized in that it further comprises a memory for storing software and guest management structure virtual machines containing ukazatel the management interrupt.

15. The system of item 13, wherein the processor is to determine whether controls whether the interrupt software guest based on the current value of pointer management interrupt.

16. The system of item 13, wherein the processor is designed to determine whether the software guest reception interrupt by accessing the value of the interrupt flag.

17. The system of item 13, wherein the processor is to determine that MBM is ready for receiving control based on the current value of the flag transfer interrupt.

18. The system of item 13, wherein the software guest is associated with a preferred virtual machine.

19. System p, wherein the processor is additionally designed to transfer control to MWM and MWM is designed to detect the fact that the preferred virtual machine is ready to receive interrupts for the delivery of interrupts on the preferred virtual machine.

20. The system of item 13, wherein the processor is additionally to set interrupt flag in one of the following values: a value indicating that the MWM is not ready to accept interrupt, a value indicating that MBM is ready to accept interrupts, and the value read from the management structure VI the virtual machines when transferring control to MBM.

21. The system of item 13, wherein the MWM is designed to determine the virtual machine that is assigned to handle the interrupt, and to emulate delivery interruption in the scheduled virtual machine, if assigned to a virtual machine is ready to accept interrupts.

22. Machine-readable media containing instructions that when executed by a processing system, provide the system processing method for managing interrupts in the system virtual machines, includes the recognition of the pending interrupt in the process of working software guest; determining, controls whether the interrupt software the guest software if the guest does not control the interrupt, determining, is a virtual machine monitor (MBM) to take control, and transfer control to MBM, if MWM is ready to take control, otherwise, if the software of the guest controls the interrupt, determining whether the software guest to accept the interrupt, and the delivery of the interrupt to the software of the guest software if the guest is ready to accept interrupts.

23. Machine-readable medium according to p. 22, wherein the determining controls whether the interrupt software guest, includes assumed ivanie associated with the interrupt pointer management interrupt.

24. Machine-readable medium for p. 23, characterized in that the control pointer interrupt is stored in at least one of the following: in the management of virtual machines (SUWM), machine registers and memory.

25. Machine-readable medium for p. 23, characterized in that the control pointer interrupt is selected from a set of pointers to the interrupt handling on the basis of the characteristics of the interruption.