Patenttips-handling shared interrupts in BIOS under a virtualization technology environment

BACKGROUND

This relates to the operation of software under a virtualization Technology (VT) environment.

in a VT environment, such as the Intel VT or AMD Pa Cifica, an infrastructure is provided to execute applications in an isolated and protected partition, called the Servi Ce partition, using the VT capability. The operating system is visible to end users runs in another partition, called the user partition. For example, a firewall application running in service partition are forwarding the Inspected/verified data packets to the User partition. A typical flow of a network packet consist of a) processing and inspection of the network packet by the firewall Applicati On service partition, and B) subsequent forwarding of the network packet to the user partition through the Inter-commun Ication Channel. The network packet eventually reaches the end-user application running in user partition (as it would happen in a non-vt E nvironment).

in a particular VT environment, Windows CE can be used in the service partition and Windows XP in the user partition. The control flow of the boot process can be summarized as FOLLOWS:A) Basic input/output system passes the control to VT Loade R b) VT loader loads itself and prepares the environments for the service partition and user partition for both guests Windo WS CE and Windows XP respectively; c) VT Loader launches Windows CE in service partition, Windows CE completes it boot, and requests VT Loader to launch Win Dows XP; d) VT loader then launches Windows XP and Windows XP starts booting.

during initial stages of a boot process, the XP Operating system uses different basic input/output system services as usual. However, the XP operating system is unaware, it's running within a partition isolated and supervised by another entit Y. Although the control flow of the XP operating system in the VT aware environment remains identical to that of the non-v T environment, the underlying hardware environment differs as far as the device ownership is concerned.

typically, devices is fully owned by one Operating system or guest running in a particular partition (service partition or user partition), and, therefore, is ISO Lated from one another. For example, network controllers is owned by the Windows CE operating system running in service partition, that's handle s all incoming and outgoing packets, while storage devices, like hard disks, could be owned by the XP operating system Runni ng in user partition. However, some devices, like programmable interrupt controller, could be shared between the operating systems and is the Reby exposed to both guests via the underlying software models.

when an interrupt request was shared by Different devices, owned by different guests, level-triggered interrupt environments, the interrupt is conveyed to Both guests under the assumption that the service routine of both guests would be invoked; The service routine of a particular guest would check the interrupt source for the device it controls; If several devices raise a shared interrupt request simultaneously, all devices would be checked as possible interrupt sour Ces and serviced as necessary; And if a guest detects that the interrupt source for the device it controls, it would service the interrupt or, otherwise, It would ignore the interrupt by sending an end of interrupt.

The basic Input/output System (BIOS) installs a default interrupt request handler for all hardware interrupts. If No other entity installs a handler for a particular interrupt request, the basic Input/output system default Interrupt Service routine remains as the only active interrupt handler for the concerned interrupt request. In a GKFX interrupt environment, when an entity installs a handler for a particular interrupt request, the concerned Han Dler is installed in a chained fashion so, the last installed handler gets control first on the occurrence of the Conc Erned interrupt Request and the basic Input/output system default interrupt Service routine remains at the bottom of the I Nterrupt handler chain. Thus, if no handler claims and services the generated interrupt request, the basic Input/output system default interrupt S Ervice routine eventually gets control and finds the interrupt request that have been generated, but not claimed and, hence , not serviced by anybody, and DISABles the request, treating it like a spurious interrupt.

detailed DESCRIPTION

some Virtualization Technology (VT) Capabilities may expect a interrupt request would be ignored if no owner was found while the basic Input/output syste M (BIOS) expects that the interrupt request would be disabled if No. owner is found. The conflicting requirements regarding the handling of a GKFX interrupt request gives rise to a situation where the inte Rrupt request is disabled by the basic Input/output system default interrupt Service routine if no owner claims it. For example, where an interrupt request was shared by a network controller and a hard disk controller, if the interrupt is Generated by the network controller in the virtualized environment when one operating system Windows XP are booting up in t He user partition, the interrupt is injected into both operating system guests.

In a environment where one operating system Windows XP is booting in the user partition, the interrupt handlers Installed by the basic input/output system, or other entities, is invoked. However, the installed interrupt handlers for the hard disk could not service the interrupt because it's not generated by a Hard disk operation, but, instead, was generated by a network operation. Even though the other operating system guest Windows CE running in service partition installs a network driver and process Es the interrupt as expected, no entity may install the interrupt handler for the network controller during the boot Proce SS of the operating system in the user partition. Hence, the basic input/output system default interrupt service routine is invoked as the last entry in the chained Interru PT handlers, disabling the interrupt request which may subsequently result in a error while accessing the hard disk and P Ossibly in the failure to boot the system.

this situation may be overcome by installing on Demand a custom interrupt service routine. The BIOS is requested to install the custom interrupt handler as required, allowing the basic input/output system DEFA Ult Interrupt Service routine to remain unchanged, while allowing installation of a custom interrupt service routine for a Particular interrupt request as needed.

thus, a custom interrupt service routine may Active only for a concerned shared interrupt request between-guests and existing basic input/output system default int Errupt Service routines is active for all and interrupt requests. In a NON-VT environment, the existing basic Input/output system default interrupt Service routine remains active for all I Nterrupts as usual. This allows development of a single basic input/output system that works in both VT and NON-VT environments, while Maintai Ning the compatibility with all existing environments.

The invocation of a callback method by VT loader are illustrated in FIG. 1. The callback function? implemented in the basic input/output system in one embodiment. The basic Input/output system may also implement the custom interrupt service routine This does not disable the interrupt Request if no owner is found, but just issues an end of interrupt and keep the custom interrupt service routine inactive a nd make it active if asked by the caller (e.g. VT loader). The basic input/output system may provide the pointer to the callback function when the basic input/output system passes t He control to the VT Loader (loader of VT. Environment), as indicated by the arrow adjacent to block? FIG. 1.

then in diamond? , the loader validates the basic Input/output system provided callback function. If The function is not a valid, an error message could be displayed, as indicated at? . Otherwise, the loader performs the normal operation of checking and validating and configuring other System parameters as indicated in block? .

a check at Diamond? determines whether the boot is to a controlled environment. If not, the normal boot path was followed as indicated in block? . Otherwise, the loader determines the interrupt request for which a custom interrupt service routine n Eeds to is installed, as indicated in block? . A check at Diamond? ? Determines whether to install the custom interrupt routines to service any interrupt requests. If So, the callback function was invoked by the loader, as indicated in block? .

the Loader thus uses a callback function to Install and activate the custom interrupt service routine, as indicated in block? , for a particular interrupt request during the boot process. A check at Diamond? ? Determines whether the custom interrupt Service routine installation was successful. If So, booting continues in the controlled environment, as indicated in block? .

The custom interrupt Service routine operates, as indicated in FIG. 2, in accordance with one embodiment. The custom interrupt service routine is invoked when no owner claims or services the generated interrupt request, as Indic Ated in block? the pending interrupt request level was then identified, as indicated in block? If The custom interrupt service routine is active for the request, as determined in diamond? A end of interrupt is issued to the interrupt controller, as indicated in block? There is a exit from the interrupt service routine.

if The custom interrupt service routine is not Active, the interrupt request is masked off and disabled in their interrupt controller, as indicated in block? Interrupt . Then a end of issued to the interrupt controller, as indicated in block? ? And there is a exit from the interrupt service routine.

when Active, the interrupt service routine Finds the unclaimed interrupt request and whether the custom interrupt service routine have been activated for the Unclaime D request. If the custom interrupt service routine have been activated for the unclaimed request, it issues an end of interrupt Withou T disabling the interrupt request, as indicated in FIG. 2, block? . The loader can also optionally uninstall a custom interrupt service routine when the boot process is Complete. The loader supply a new custom interrupt service routine or use a built-in custom interrupt service routine in the BAS IC input/output system.

In some embodiments, the use of a custom interrupt service routine makes the basic Input/output system compatible with VAR IOUs environments, including both VT and NON-VT environments. A Custom Interrupt Service routine may is installed on demand and May is installed for one or more interrupt requests. It may also is uninstalled in some embodiments.

Src=http://www.freepatentsonline.com/7562173.html