EP3118740B1

EP3118740B1 - Device and method for hardware virtualization support

Info

Publication number: EP3118740B1
Application number: EP15176883.5A
Authority: EP
Inventors: Jani Kokkonen
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2015-07-15
Filing date: 2015-07-15
Publication date: 2021-09-08
Anticipated expiration: 2035-07-15
Also published as: CN107924322B; US20190340008A1; US11086655B2; EP3118740A1; CN107924322A; US10394592B2; WO2017008594A1; US20170185443A1

Description

TECHNICAL FIELD

The present application relates to the field of virtual timer delivery. In particular, the present application relates to a device and a method for hardware virtualization support.

BACKGROUND

Various computer central processor instruction sets are used today. One type of them, the ARM architecture, abbreviated for Advanced RISC Machines, provides optional hardware, HW, extensions support or HW virtualization support. For instance, in ARMv7 as introduced in 2004 and in ARMv8 architectures, such HW virtualization support is present and supported.
Even though ARM adds HW features to support virtualization, there is still need for a substantial amount of hypervisor software in order to handle virtualization events. Hypervisor software as compared to HW-based virtualization solution provides flexibility in the form of easy extensibility of virtualization features, but downsizes its performance overhead due to lack of HW acceleration on SW handled operations. One area that is especially affected by this performance overhead is the virtual timer interrupt delivery in ARM platforms.
Document CHRISTOFFER DALL ET AL: "KVM/ARM", pages 333-348, DOI: 10.1145/2644865.2541946, ISBN: 978-1-60558-392-1 is directed to the Linux ARM hypervisor, KVM/ ARM, a full system ARM virtualization solution specifying an implementation for virtual timer delivery that allows virtual machines direct access to timers.

SUMMARY AND DESCRIPTION

It is the object of the present invention to provide an improved hardware virtualization support.
This object is achieved by the features of the independent claims. Further implementation forms are apparent from the dependent claims, the description and the figures.
According to a first aspect, a device for hardware virtualization support is provided, the device comprising: a hypervisor component configured to launch a virtual machine, VM, and configured to exit and/or to enter a host level; a host system component configured to process a configuration flag that enables an interrupt delivery mechanism; wherein the host system component is configured to record, if the configuration flag is set, a virtual timer number as a global variable, providing information to the hypervisor component when a virtual timer is expired; and wherein the hypervisor component is configured to process the virtual timer number of the global variable in the host level.
The device for hardware virtualization support advantageously provides improving virtual timer delivery time in ARM chips based on generic interrupt controller v2/3, GICv2/3. The hindrance with regard to virtual timer delivery in ARM chips based on GICv2/3 is that the hardware is not able to send a virtual timer directly to the guest operating system, the guest OS.
Thus, the expiration of a virtual timer may generate a physical interrupt which may cause an exit to the hypervisor mode and then to the host OS which updates kernel-based virtual machines, KVM, software structures related to the GIC and then yet gets back to the hypervisor mode which updates actual physical GIC registers before entering back to guest OS mode. Thus, the delivery of a virtual timer may require significant amount of work by the software layer, i.e. processing time and/or memory requirements.
The device for hardware virtualization support advantageously allows simplifying interrupt delivery paths as used and therefore shortens the virtual timer delivery time.
In other words, the device for hardware virtualization support may comprise a linux KVM hypervisor code part that may provide code to perform a "word switch", i.e. the possibility to launch a VM and exit and/or enter the host linux level. The hypervisor code may also be responsible to write and/or to read into physical GIC, for instance, as the interrupt controller.
In other words, the device for hardware virtualization support may comprise a linux host system that may need to be extended with a supplementary configuration flag that enables fast interrupt delivery mechanism.
In other words, the linux host system may have the requirement to be extended with an additional configuration flag, for instance defined as
CONFIGURE_KVM_TIMER_OPTIMIZATION.
Processing the new, added configuration flag and considering the new configuration flag may enable a quicker interrupt delivery mechanism if compared to the mechanism without a supplementary configuration flag.
If the flag is set, the host system, i.e. linux may record the virtual timer number in a global variable so that the hypervisor mode knows when virtual timer has expired and can use the fast path mechanism if that has been enabled.
The hypervisor mode may be extended to take into account a fast delivery option.
In other words, the device for hardware virtualization support may be configured to run several VMs on a single physical central processing unit, CPU. The device for hardware virtualization support may be configured to run one VM on one physical CPU.
In a first possible implementation form of the device according to the first aspect, the host system component is configured to perform a virtualization specification for a physical interrupt taken in a hypervisor mode. This advantageously provides a reduction in time by mapping a so-called virtual interrupt for the guest OS.
In a second possible implementation form of the device according to the first aspect as such or according to the first implementation form of the first aspect, the host system component is configured to restore a host OS state, to mark an exit reason to a register and to return to the host OS state. This advantageously provides an improved performance of the virtual timer delivery to the guest OS.
In a third possible implementation form of the device according to the first aspect as such or according to the any one of the preceding implementation forms of the first aspect, the host system component is configured to perform a virtual timer performance optimization if an optimization flag is enabled. This advantageously provides an embedded mechanism based on a simple check for improving the virtual timer performance. In other words, a virtual timer delivery time optimization is provided. Virtual timer performance is improved because an extra exit to host state is avoided.
In a fourth possible implementation form of the device according to the first aspect as such or according to the any one of the preceding implementation forms of the first aspect, if the optimization flag is enabled, the host system component is configured to optimize a hypervisor return path to a guest OS state. This advantageously provides an improved performance of the hardware virtualization support. Hence, a virtual timer delivery time optimization is provided.
In a fifth possible implementation form of the device according to the first aspect as such or according to the any one of the preceding implementation forms of the first aspect, if the optimization flag is enabled, the host system component is configured to update a generic interrupt controller list register and to return back to the guest OS state, when an expiration of the virtual timer is detected. This advantageously provides an adjusted hardware virtualization support and returning to the guest OS state. The virtual timer delivery to the guest OS is thus faster.
In a sixth possible implementation form of the system according to the first aspect as such or according to the any one of the preceding implementation forms of the first aspect, the hypervisor component is configured to record a virtual timer IRQ number in a timer device tree entry. This advantageously provides an adjusted hardware virtualization support. The term IRQ as used by the present invention refers to the term "interrupt request". In other words, an IRQ is a signal that is sent to the computer processor to stop the processor momentarily while it decides which task it should perform next. This advantageously causes asynchronous exit to the interrupt handler once an interrupt occurs.
In a seventh possible implementation form of the system according to the first aspect as such or according to any of the preceding implementation forms of the first aspect, the hypervisor component is configured to specify the virtual IRQ number. This advantageously provides an improved performance of the virtual interrupts. In other words, the performance is improved, when the virtual IRQ number is specified.
The reason is that normally a hypervisor component may not be aware which interrupt should be handled by the guest OS and which one by host OS. By employing a virtual IRQ number a unique assignment of interrupts to guest OS or host OS is possible.
When an interrupt occurs then the hypervisor component goes to the host state because the interrupt might be targeted for the host OS. If the host OS does not handle the interrupt and acknowledges the interrupt in the end then it will be handled by the KVM which checks which of the VMs should handle it. That means that the KVM structures of the responsible VM are updated and then the KVM returns to the hypervisor mode and in hypervisor mode the actual HW registers for the virtual timer that is updated before returning to the guest OS. This extra round to host state is avoided if hypervisor component is aware that a physical IRQ is targeted to a running VM.
In an eighth possible implementation form of the system according to the first aspect as such or according to any of the preceding implementation forms of the first aspect, the hypervisor component is configured to specify the virtual IRQ number according to a physical IRQ number that is delivered to the hypervisor mode once the virtual timer is expired. This advantageously provides an improved performance of the virtual interrupts.
According to a second aspect, the present invention relates to a hypervisor component for hardware virtualization support, wherein the hypervisor component is configured to launch a virtual machine and configured to exit and/or to enter a host level and to process a virtual timer number of a global variable in the host level.
According to a third aspect, the invention relates to a host system component for hardware virtualization support, wherein the host system component is configured to process a configuration flag that enables an interrupt delivery mechanism, wherein the host system component, if the configuration flag is set, is configured to record a virtual timer number as a global variable, providing information to a hypervisor component according to the second aspect when a virtual timer is expired.
According to a fourth aspect, the present invention relates to a method for hardware virtualization support, the method comprising the following steps of:

launching a virtual machine by a hypervisor component and exiting and/or entering a host level;
processing a configuration flag by a host system component, wherein the configuration flag enables an interrupt delivery mechanism;
if the configuration flag is set, recording a virtual timer number as a global variable by the host system component, providing information to the hypervisor component when a virtual timer is expired; and
processing the virtual timer number of the global variable in the host level by the hypervisor component.

In a first possible implementation form of the method according to the fourth aspect, the method further comprises the step of: performing a virtualization specification for a physical interrupt taken in a hypervisor mode by the host system component. This advantageously provides a reduction of processing time by mapping a virtual interrupt for the guest OS.
The processing or delivery time is the time measured between an expiration of virtual timer, which always causes physical IRQ that is trapped to hypervisor mode i.e. to EL2 mode, and the delivery of virtual timer to guest OS state. In other words, the processing or delivery time corresponds to the time measured between the time point of the expiration of virtual timer and the time point of the delivery of virtual timer to guest OS state.
In a second possible implementation form of the method according to the fourth aspect as such or according to the first implementation form of the method according to the fourth aspect, the method further comprises the steps of: restoring a host OS state, marking an exit reason to a register and returning to the host OS state. This advantageously provides an improved performance of the virtual timer delivery to the guest OS.
In a third possible implementation form of the method according to the fourth aspect as such or according to the any of the preceding implementation forms of the method according to the fourth aspect, the method further comprises the step of: performing a virtual timer performance optimization if an optimization flag is enabled. This advantageously provides an embedded mechanism for enhancing the virtual timer performance.
The present invention can be implemented in digital electronic circuitry, or in computer hardware, firmware, software, or in combinations thereof, e.g. in available hardware of conventional mobile devices or in new hardware dedicated for processing the methods described herein.
These and other aspects of the present invention will become apparent from and be elucidated with reference to the embodiments described hereinafter. A more complete appreciation of the present invention and the attendant advantages thereof will be more clearly understood with reference to the following schematic drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

Further embodiments of the invention will be described with respect to the following figures, in which:

Fig. 1 shows a schematic diagram of a device for hardware virtualization support according to one embodiment of the present invention;
Fig. 2 shows a schematic diagram of a flowchart diagram of a method for hardware virtualization support according to an embodiment of the invention;
Fig. 3 shows a schematic diagram of a virtual timer delivery diagram in KVM based hypervisor according to one embodiment of the present invention;
Fig. 4 shows a schematic diagram of modifications in the KVM hypervisor and the host system according to one embodiment of the present invention;
Fig. 5 shows a schematic diagram of an example of virtual timer IRQ number in an ARM arch_timer device tree entry according to one embodiment of the present invention; and
Fig. 6 shows a schematic diagram of an example of a GICv2 architecture diagram according to one embodiment of the present invention.

DETAILED DESCRIPTION OF EMBODIMENTS OF THE INVENTION

In the associated figures, identical reference signs denote identical or at least equivalent elements, parts, units or steps. In addition, it should be noted that all of the accompanying drawings are not to scale.
The technical solutions in the embodiments of the present invention are described clearly and completely in the following with detailed reference to the accompanying drawings in the embodiments of the present invention.
The present invention advantageously allows running several VMs on the same CPU, the advantage of the virtual timer delivery optimization can be achieved if one VCPU is running on single physical CPU.
The present invention advantageously provides a mechanism that avoids, in case existing KVM hypervisor code has been modified, entering back to Host OS mode once virtual timer expires i.e. after virtual timer expiration of the Host OS. Thus, hypervisor mode loop can be avoided.
Entering to hypervisor mode and back to Guest OS mode may still be performed because current ARM GIC architecture mandates to catch all physical interrupts in hypervisor mode. When a virtual timer may expire, hypervisor mode code path selects optimized virtual timer handling if Linux kernel compiler time option CONFIGURE_KVM_TIMER_OPTIMIZATION - flag is enabled.
If the CONFIGURE_KVM_TIMER_OPTIMIZATION flag is enabled, then entering to the host OS state may be avoided. Instead a hypervisor return path to the guest OS state may be optimized such that when the hypervisor recognizes expiration of the virtual timer it may update the GIC list register directly and it may return back to the guest OS state. This way the delivery time of the virtual timer can be significantly improved.
The method for hardware virtualization support describes a virtual timer delivery optimization.
The GIC architecture may be used to define the architectural requirements for handling all interrupt sources for any processor connected to a GIC or to a common interrupt controller programming interface applicable to uniprocessor or multiprocessor systems.
According to an exemplary embodiment of the present invention, the GIC architecture may be used as a centralized resource for supporting and managing interrupts in a system that includes at least one processor. The GIC architecture may provide registers for managing interrupt sources, interrupt behavior, and interrupt routing to one or more processors, support for the ARM architecture and software-generated or virtual interrupts.
According to an exemplary embodiment of the present invention, a software based method to simplify and optimize virtual timer delivery time in KVM based hypervisor by avoiding unnessary store and load of Linux Host OS state is provided.
According to an exemplary embodiment of the present invention, changes to the KVM hypervisor code are used and to the linux host OS code. According to an exemplary embodiment of the present invention, these modifications are optional and configurable via the linux kernel CONFIGURE_KVM_TIMER_OPTIMIZATION - compiler flag.
Fig. 1 shows a schematic diagram of a device for hardware virtualization support according to one embodiment of the present invention.
Fig. 1 shows an embodiment of a device 100 for hardware virtualization support, the device 100 comprises a hypervisor component 101 and a host system component 102.
The hypervisor component 101 is configured to launch a virtual machine VM and may be configured to exit and/or to enter a host level, wherein the hypervisor component 101 is configured to process the virtual timer number of the global variable in the host level.
The host system component 102 is configured to process a configuration flag CF that enables an interrupt delivery mechanism, wherein the host system component 102 is configured to record a virtual timer number as a global variable, if the configuration flag is set, providing information to the hypervisor component 101 when a virtual timer is expired.
The host system component 102 may be configured to perform a virtual timer performance optimization if an optimization flag OF is enabled.
The host system component 102 is configured to process a configuration flag CF in form of a CONFIGURE_KVM_TIMER_OPTIMIZATION - flag.
Fig. 2 shows a schematic diagram of a flowchart diagram of a method for hardware virtualization support according to an embodiment of the invention.
Fig. 2 describes virtual timer delivery optimization. According to an exemplary embodiment of the present invention, all steps S1 to S4 can be independent of each other.
As a first step S1 of the method, launching a virtual machine by a hypervisor component 101 and exiting and/or entering a host level.
As a second step S2 of the method, processing a configuration flag CF by a host system component 102 is conducted, wherein the configuration flag CF enables an interrupt delivery mechanism.
As a third step S3 of the method, if the configuration flag CF is set, recording a virtual timer number as a global variable by the host system component 102 is performed, providing information to the hypervisor component 101 when a virtual timer is expired.
As a fourth step S4 of the method, processing the virtual timer number of the global variable in the host level by the hypervisor component 101 is conducted.
Fig. 3 shows a schematic diagram of a virtual timer delivery diagram in KVM based hypervisor according to one embodiment of the present invention.
According to an exemplary embodiment of the present invention, the device 100 for hardware virtualization support may be configured to perform the following steps:
In step S10, triggered by a physical interrupt, the guest OS state is saved. In step S11, a hypervisor state is loaded.
A query part 2000 may use a linux kernel compilation flag to select either fast or slow path of virtual timer delivery. The query part 2000 may comprise the following steps.
In step S12, it may be determined whether, the CONFIGURE_KVM_TIMER_OPTIMIZATION - flag is set.
If yes, then the procedure may be continued with a fast part 3000. If not, the procedure may be continued with a slow part 1000. The terms fast and slow may be used in relative respect to each other, e.g. defining that one part is faster or slower than the other.
For instance, if the kernel is not compiled to support CONFIGURE_KVM_TIMER_OPTIMIZATION - settings then the normal virtual timer delivery mechanism will be used i.e. slow path. Otherwise, the fast path will be used.
The slow part 1000 may comprise the following steps:
In step S13, loading the host OS state may be conducted.
Subsequently, in step S14, updating the KVM software GIC state may be conducted.
In step S15, saving the host OS state may be conducted.
Finally, in step S16, loading the hypervisor state may be conducted.
The fast part 3000 may comprise the following steps:
In step S20, updating virtual CPU GIC registers may be conducted.
Subsequently, in step S21, loading the guest OS state may be conducted.
Fig. 4 shows a schematic diagram of modifications in the KVM hypervisor and the host system according to one embodiment of the present invention.
Fig. 4 shows the processes and steps performed between the linux host, the KVM hypervisor, and the guest virtual machine. According to an exemplary embodiment of the present invention, the device 100 for hardware virtualization support may be configured to perform the following steps:
The optimized virtual timer delivery mechanism may be enabled in the host OS:
In step S22, applying virtual timer delivery optimization code to Linux host and KVM hypervisor code may be conducted.
Subsequently, in step S23, selecting CONFIGURE_KVM_TIMER_OPTIMIZATION-compile option and compiling the host kernel may be conducted.
In the following, in step S24, recording the virtual timer physical interrupt number may be conducted. This may trigger the guest virtual machine in step S30 to have the guest virtual machine running.
Then, in step S25, configuring a single VM on single physical CPU based on normal Linux tools may be performed.
Once a physical timer interrupt arrives in step S32, exiting to hypervisor mode may be conducted. Subsequently, it may be checked in step S40 if the CONFIGURE_KVM_TIMER_OPTIMIZATION flag is set.
If yes, the procedure may be continued with step S41, if not with step S26.
In step S26, load the host OS state may be conducted.
Subsequently, in step S27, updating the KVM software GIC state may be performed.
In the following, in step S28, saving the host OS state may be conducted.
Then, in step S29, loading the hypervisor state may be conducted and the procedure may be resumed with step S42.
In step S41, updating the VCPU GIC registers may be conducted.
Subsequently, in step S42, loading the guest OS state may be performed.
Finally, returning to the guest virtual machine VM may be conducted.
The virtual timer IRQ number is recorded in timer device tree entry: third IRQ number in timer device tree entry specifies the virtual IRQ number that is delivered to hypervisor mode once virtual time expires.
The virtual timer node in the device tree entry for arch_timers is shown in Fig. 4.
The hypervisor may know the used virtual interrupt number. This can be done in different parts of the linux host OS architecture timer setup. One option is to use for instance the following pseudo code flow:

i). Specify global virt_irq_num - variable;
ii). Specify Linux kernel compile time configuration option CONFIGURE_KVM_TIMER_OPTIMIZATION to enable virtual timer delivery optimization;
iii). In arm_arch_timer.c in arch_timer_init() - function following code path records used virtual IRQ number:

 #ifdef CONFIGURE_KVM_TIMER_OPTIMIZATION
 if(is_hyp_mode_available()) {
               virt_irq_num = arch_timer_ppi[VIRT_PPI];
 }
 #endif.

The dotted line represents modifications in the linux host OS, the dashed line shows modifications in the KVM.

Fig. 5 shows a schematic diagram of an example of virtual timer IRQ number in ARM arch_timer device tree entry according to one embodiment of the present invention.

Fig. 6 shows a schematic diagram of a GICv2 architecture diagram according to one embodiment of the present invention.

Fig. 6 shows a schematic diagram of a GIC or GICv2 partitioning. The GIC or GICv2 architecture may split logically into a distributor block and one or more CPU interface blocks. According to an exemplary embodiment of the present invention, the GIC virtualization extensions add one or more virtual CPU interfaces to the GIC. Therefore, as Fig. 6 shows, the logical partitioning of the GIC is as follows:

According to an exemplary embodiment of the present invention, a distributor block may be defined. The Distributor block performs interrupt prioritization and distribution to the CPU interface blocks that connect to the processors in the system. The Distributor block registers are identified by the GICD_ prefix.

Further, according to an exemplary embodiment of the present invention, CPU interfaces may be used. Each CPU interface block may perform priority masking and preemption handling for a connected processor in the system. CPU interface block registers are identified by the GICC_ prefix. When describing a GIC that includes the GIC Virtualization Extensions, a CPU interface is sometimes called a physical CPU interface, to avoid possible confusion with a virtual CPU interface.

According to an exemplary embodiment of the present invention, virtual CPU interfaces may be used. The GIC Virtualization Extensions add a virtual CPU interface for each processor in the system.

According to an exemplary embodiment of the present invention, a virtual interface control may be used. The main component of the virtual interface control block is the GIC virtual interface control registers that include a list of active and pending virtual interrupts for the current virtual machine on the connected processor.

According to an exemplary embodiment of the present invention, these registers are managed by the hypervisor that is running on that processor. Virtual interface control block registers are identified by the GICH_ prefix.

Further, a virtual CPU interface may be used. Each virtual CPU interface block provides physical signaling of virtual interrupts to the connected processor. The ARM processor may process virtualization extensions signals and use these interrupts to the current virtual machine on that processor.

According to an exemplary embodiment of the present invention, the GIC virtual CPU interface registers, accessed by the virtual machine, provide interrupt control and status information for the virtual interrupts. The format of these registers is similar to the format of the physical registers. Further, CPU interface registers may be configured. Virtual CPU interface block registers are identified by the GICV_prefix.

From the foregoing, it will be apparent to those skilled in the art that a variety of methods, systems, computer programs on recording media, and the like, are provided.

The present disclosure also supports a computer program product including computer executable code or computer executable instructions that, when executed, causes at least one computer to execute the performing and computing steps described herein.

Many alternatives, modifications, and variations will be apparent to those skilled in the art in light of the above teachings. Of course, those skilled in the art readily recognize that there are numerous applications of the invention beyond those described herein.

While the present invention has been described with reference to one or more particular embodiments, those skilled in the art recognize that many changes may be made thereto without departing from the scope of the present invention. It is therefore to be understood that within the scope of the appended claims, the inventions may be practiced otherwise than as specifically described herein.

In the claims, the word "comprising" does not exclude other elements or steps, and the indefinite article "a" or "an" does not exclude a plurality. A single processor or other unit may fulfill the functions of several items recited in the claims.

The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measured cannot be used to advantage. A computer program may be stored or distributed on a suitable medium, such as an optical storage medium or a solid-state medium supplied together with or as part of other hardware, but may also be distributed in other forms, such as via the Internet or other wired or wireless telecommunication systems.

Claims

Device (100) for hardware virtualization support, the device (100) comprising:
- a hypervisor component (101) configured to launch a virtual machine, VM, running a guest operating system, OS, and configured to exit and/or to enter a host level;

- a host system component (102) configured to process a configuration flag, CF, that enables an interrupt delivery mechanism;
wherein the host system component (102) is configured to record, if the configuration flag is set, a virtual timer number as a global variable, providing information to the hypervisor component (101) when a virtual timer is expired; wherein the host system component (102) is configured to perform a virtualization specification for a physical interrupt taken in a hypervisor mode wherein the hypervisor component (101) is configured to process the virtual timer number of the global variable in the host level;

wherein the host system component (102) is configured to restore a host OS state, to mark an exit reason to a register and to return to the host OS state;

wherein, if an optimization flag, OF, is enabled, the hypervisor component (101) is configured to update a generic interrupt controller list register and to return back to the guest OS state, when the expiration of the virtual timer is detected.
The device (100) according to claim 1, wherein the host system component (102) is configured to perform a virtual timer performance optimization if the optimization flag, OF, is enabled.
The device (100) according to claim 2, wherein, if the optimization flag, OF, is enabled, the host system component (102) is configured to optimize a hypervisor return path to an guest OS state.
The device (100) according to one of claims 1 to 3, wherein the hypervisor component (101) is configured to record a virtual timer IRQ number in a timer device tree entry.
The device (100) according claim 4, wherein the hypervisor component (101) is configured to specify the virtual IRQ number.
The device (100) according to claim 5, wherein the hypervisor component (101) is configured to specify the virtual IRQ number according to a physical IRQ number that is delivered to hypervisor mode once the virtual timer is expired.
Method for hardware virtualization support, the method comprising the following steps of:
- launching (S1) a virtual machine running a guest operating system, OS, by a hypervisor component (101) and exiting and/or entering a host level;

- processing (S2) a configuration flag, CF, by a host system component (102), wherein the configuration flag, CF, enables an interrupt delivery mechanism;

- if the configuration flag, CF, is set, recording (S3) a virtual timer number as a global variable by the host system component (102), providing information to the hypervisor component (101) when a virtual timer is expired;

- processing (S4) the virtual timer number of the global variable in the host level by the hypervisor component (101); and.

- performing a virtualization specification for a physical interrupt taken in a hypervisor mode by the host system component (102);
wherein the method further comprises the steps of: restoring a host OS state, marking an exit reason to a register and returning to the host OS state;

wherein, if an optimization flag, OF, is enabled, the hypervisor component (101) is configured to update a generic interrupt controller list register and to return back to the guest OS state, when the expiration of the virtual timer is detected.
The method according to claim 7, wherein the method further comprises the step of: performing a virtual timer performance optimization if the optimization flag is enabled.