U.S. patent number 7,302,511 [Application Number 11/251,282] was granted by the patent office on 2007-11-27 for chipset support for managing hardware interrupts in a virtual machine system.
This patent grant is currently assigned to Intel Corporation. Invention is credited to Andrew V. Anderson, Steven M. Bennett, Erik Cota-Robles, Stalinselvaraj Jeyasingh, Alain Kagi, Gilbert Neiger, Richard Uhlig.
United States Patent |
7,302,511 |
Jeyasingh , et al. |
November 27, 2007 |
Chipset support for managing hardware interrupts in a virtual
machine system
Abstract
In one embodiment, an apparatus includes a set of multiplex
blocks coupled with an interrupt controller and multiple interrupt
request lines, and a virtual machine monitor block (VMM) coupled to
the set of multiplex blocks. Each multiplex block corresponds to a
distinct interrupt request line. Each multiplex block is to route
the interrupt request signal received via the corresponding
interrupt request line either to the interrupt controller or the
VMM block depending on a current configuration value of this
multiplex block.
Inventors: |
Jeyasingh; Stalinselvaraj
(Beaverton, OR), Anderson; Andrew V. (Hillsboro, OR),
Bennett; Steven M. (Hillsboro, OR), Cota-Robles; Erik
(Portland, OR), Kagi; Alain (Portland, OR), Neiger;
Gilbert (Portland, OR), Uhlig; Richard (Hillsboro,
OR) |
Assignee: |
Intel Corporation (Santa Clara,
CA)
|
Family
ID: |
34422123 |
Appl.
No.: |
11/251,282 |
Filed: |
October 13, 2005 |
Prior Publication Data
|
|
|
|
Document
Identifier |
Publication Date |
|
US 20060036791 A1 |
Feb 16, 2006 |
|
Related U.S. Patent Documents
|
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
Issue Date |
|
|
10676890 |
Sep 30, 2003 |
|
|
|
|
Current U.S.
Class: |
710/260; 710/266;
710/48; 712/224 |
Current CPC
Class: |
G06F
9/45533 (20130101); G06F 9/4812 (20130101); G06F
13/24 (20130101) |
Current International
Class: |
G06F
13/24 (20060101); G06F 13/26 (20060101); G06F
12/00 (20060101); G06F 9/445 (20060101) |
Field of
Search: |
;710/260-269,200,40,48,49 ;712/224,244 ;718/1,100,103,108
;711/6,151,203 ;700/1 |
References Cited
[Referenced By]
U.S. Patent Documents
Foreign Patent Documents
|
|
|
|
|
|
|
4217444 |
|
Dec 1992 |
|
DE |
|
0473913 |
|
Mar 1992 |
|
EP |
|
0600112 |
|
Jun 1994 |
|
EP |
|
0602667 |
|
Jun 1994 |
|
EP |
|
0892521 |
|
Jan 1999 |
|
EP |
|
0930567 |
|
Jul 1999 |
|
EP |
|
0961193 |
|
Dec 1999 |
|
EP |
|
0965902 |
|
Dec 1999 |
|
EP |
|
1030237 |
|
Aug 2000 |
|
EP |
|
1055989 |
|
Nov 2000 |
|
EP |
|
1056014 |
|
Nov 2000 |
|
EP |
|
1085396 |
|
Mar 2001 |
|
EP |
|
1146715 |
|
Oct 2001 |
|
EP |
|
1209563 |
|
May 2002 |
|
EP |
|
1271277 |
|
Jan 2003 |
|
EP |
|
2000076139 |
|
Mar 2000 |
|
JP |
|
WO9524696 |
|
Sep 1995 |
|
WO |
|
WO9729567 |
|
Aug 1997 |
|
WO |
|
WO9812620 |
|
Mar 1998 |
|
WO |
|
WO9834365 |
|
Aug 1998 |
|
WO |
|
WO9844402 |
|
Oct 1998 |
|
WO |
|
WO9905600 |
|
Feb 1999 |
|
WO |
|
WO9918511 |
|
Apr 1999 |
|
WO |
|
WO9957863 |
|
Nov 1999 |
|
WO |
|
WO9965579 |
|
Dec 1999 |
|
WO |
|
WO0021238 |
|
Apr 2000 |
|
WO |
|
WO0062232 |
|
Oct 2000 |
|
WO |
|
WO0127723 |
|
Apr 2001 |
|
WO |
|
WO0127821 |
|
Apr 2001 |
|
WO |
|
WO0163994 |
|
Aug 2001 |
|
WO |
|
WO0175565 |
|
Oct 2001 |
|
WO |
|
WO0175595 |
|
Oct 2001 |
|
WO |
|
WO0201794 |
|
Jan 2002 |
|
WO |
|
WO9909482 |
|
Jan 2002 |
|
WO |
|
WO0217555 |
|
Feb 2002 |
|
WO |
|
WO02060121 |
|
Aug 2002 |
|
WO |
|
WO0175564 |
|
Oct 2002 |
|
WO |
|
WO02086684 |
|
Oct 2002 |
|
WO |
|
WO03058412 |
|
Jul 2003 |
|
WO |
|
Other References
"A highly efficient path-restoration protocol for management of
optical network transport integrity" by Iraschko et al. (abstract
only) Publication Date: May 2000. cited by examiner .
Saha, et al., "Test Floor Verification Of Multiprocessor Hardware"
Abstract only, Publication Date: Mar. 27-29, 1996, 1 page. cited by
other .
Hall, Judith S., et al., "Virtualizing the VAX Architecture," ACM
SIGARCH Computer Architecture News, Proceedings of the 18th annual
international symposium on Computer architecture, vol. 19, Issue
No. 3, Apr. 1991, 10 pages. cited by other .
Berg, Cliff, "How Do I Create a Signed Applet?", Dr. Dobb's
Journal, (Aug. 1997), 1-9. cited by other .
Brands, Stefan, "Restrictive Blinding of Secret-Key Certificates",
Springer-Verlag XP002201306, (1995), Chapter 3. cited by other
.
Chien, Andrew A., et al., "Safe and Protected Execution for the
Morph/AMRM Reconfigurable Processor", 7th Annual IEEE Symposium,
FCCM '99 Proceedings, XP010359180, ISBN 0-7695-0375-6, Los
Alamitos, CA, (Apr. 21, 1999), 209-221. cited by other .
Compaq Computer Corporation, "Trusted Computing Platform Alliance
(TCPA) Main Specification Version 1.1a", XP002272822, (Jan. 25,
2001), 1-321. cited by other .
Coulouris, George, et al., "Distributed Systems, Concepts and
Designs", 2nd Edition, (1994), 422-424. cited by other .
Crawford, John, "Architecture of the Intel 80386", Proceedings of
the IEEE International Conference on Computer Design: VLSI in
Computers and Processors (ICCD '86), (Oct. 6, 1986), 155-160. cited
by other .
Davida, George I., et al., "Defending Systems Against Viruses
through Cryptographic Authentication", Proceedings of the Symposium
on Security and Privacy, IEEE Comp. Soc. Press, ISBN 0-8186-1939-2,
(May 1989). cited by other .
Fabry, R.S. , "Capability-Based Addressing", Fabry, R.S.,
"Capability-Based Addressing," Communications of the ACM, vol. 17,
No. 7, (Jul. 1974),403-412. cited by other .
Frieder, Gideon, "The Architecture And Operational Characteristics
of the VMX Host Machine", The Architecture And Operational
Characteristics of the VMX Host Machine, IEEE, (1982),9-16. cited
by other .
Goldberg, Robert P., "Survey of Virtual Machine Research", COMPUTER
Magazine, (Jun. 1974),3 4-35. cited by other .
Gong, Li, et al., "Going Beyond the Sandbox: An Overview of the New
Security Architecture in the Java Development Kit 1.2", Proceedings
of the USENIX Symposium on Internet Technologies and Systems,
Monterey, CA,(Dec. 1997). cited by other .
Gum, P. H., "System/370 Extended Architecture: Facilities for
Virtual Machines", IBM J. Research Development, vol. 27, No. 6,
(Nov. 1983), 530-544. cited by other .
Heinrich, Joe, "MIPS R4000 Microprocessor User's Manual, Second
Edition", Chapter 4 "Memory Management", (Jun. 11, 1993), 61-97.
cited by other .
HP Mobile Security Overview, "HP Mobile Security Overview", (Sep.
2002), 1-10. cited by other .
IBM, "Information Display Technique for a Terminate Stay Resident
Program IBM Technical Disclosure Bulletin", TDB-ACC-No. NA9112156,
vol. 34, Issue 7A, (Dec. 1, 1991), 156-158. cited by other .
IBM Corporation, "IBM ThinkPad T30 Notebooks", IBM Product
Specification, located at
www-1.ibm.com/services/files/cisco.sub.--t30.sub.--spec.sub.--sheet.sub.--
-070202.pdf, last visited Jun. 23, 2004,(Jul. 2, 2002),1-6. cited
by other .
Intel, "IA-32 Intel Architecture Software Developer's Manual", vol.
3: System Programming Guide, Intel Corporation--2003,13-1 through
13-24. cited by other .
Intel, "Intel386 DX Microprocessor 32-Bit CHMOS Microprocessor With
Integrated Memory Management", (1995), 5-56. cited by other .
Intel Corporation, "IA-64 System Abstraction Layer Specification",
Intel Product Specification, Order No. 245359-001, (Jan. 2000),
1-112. cited by other .
Intel Corporation, "Intel 82802AB/82802AC Firmware Hub (FWH)",
Intel Product Datasheet, Document No. 290658-004,(Nov. 2000),1-6,
17-28. cited by other .
Intel Corporation, "Intel IA-64 Architecture Software Developer's
Manual", vol. 2: IA-64 System Architecture, Order No. 245318-001,
(Jan. 2000),i, ii, 5.1-5.3, 11.1-11.8, 11.23-11.26. cited by other
.
Karger, Paul A., et al., "A VMM Security Kernal for the VAX
Architecture", Proceedings of the Symposium on Research in Security
and Privacy, XP010020182, ISBN 0-8186-2060-9, Boxborough, MA, (May
7, 1990),2-19. cited by other .
Kashiwagi, Kazuhiko, et al., "Design and Implementation of
Dynamically Reconstructing System Software", Software Engineering
Conference, Proceedings 1996 Asia-Pacific Seoul, South Korea Dec.
4-7, 1996, Los Alamitos, CA USA, IEEE Comput. Soc, US, ISBN
0-8186-7638-8,(1996). cited by other .
Lawton, Kevin, et al., "Running Multiple Operating Systems
Concurrently on an IA32 PC Using Virtualization Techniques",
http://www.plex86.org/research/paper.txt, (Nov. 29, 1999),1-31.
cited by other .
Luke, Jahn, et al., "Replacement Strategy for Aging Avionics
Computers", IEEE AES Systems Magazine, XP002190614,(Mar. 1999).
cited by other .
Menezes, Alfred J., et al., "Handbook of Applied Cryptography", CRC
Press LLC, USA XP002201307, (1997),475. cited by other .
Menezes Alfred J., et al., "Handbook of Applied Cryptography", CRC
Press Series on Discrete Mathematics and its Applications, Boca
Raton, FL, XP002165287, ISBN 0849385237,(Oct. 1996),403-405,
506-515, 570. cited by other .
MOTOROLA, "M68040 User's Manual", (1993), 1-1 to 8-32. cited by
other .
Nanba, S., et al., "VM/4: ACOS-4 Virtual Machine Architecture",
VM/4: ACOS-4 Virtual Machine Architecture, IEEE, (1985), 171-178.
cited by other .
Richt, Stefan, et al., "In-Circuit-Emulator Wird Echtzeittauglich",
Elektronic, Franzis Verlag GMBH, Munchen, DE. vol. 40, No. 16,
XP000259620,(100-103),Aug. 6, 1991. cited by other .
Robin, John S., et al., "Analysis of the Pentium's Ability to
Support a Secure Virtual Machine Monitor", Proceedings of the 9th
USENIX Security Symposium, XP002247347, Denver, Colorado. (Aug. 14,
2000), 1-17. cited by other .
Rosenblum, M., "Virtual Platform: A Virtual Machine Monitor for
Commodity PC", Proceedings of the 11th Hotchips Conference, (Aug.
17, 1999),185-196. cited by other .
RSA Security, "Hardware Authenticators",
www.rsasecurity.com/node.asp?id=1158, 1-2. cited by other .
RSA Security, "RSA SecurID Authenticators",
www.rsasecurity.com/products/securid/datasheets/SID.sub.--DS.sub.--0103.p-
df, 1-2. cited by other .
RSA Security, "Software Authenticators",
www.srasecurity.com/node.asp?id=1313, 1-2. cited by other .
Saez, Sergio, et al., "A Hardware Scheduler for Complex Real-Time
Systems", Proceedings of the IEEE International Symposium on
Industrial Electronics, XP002190615,(Jul. 1999), 43-48. cited by
other .
Schneier, Bruce, "Applied Cryptography: Protocols, Algorithm, and
Source Code in C", Wiley, John & Sons, Inc., XP002939871; ISBN
0471117099, (Oct. 1995),47-52. cited by other .
Schneier, Bruce, "Applied Cryptography: Protocols, Algorithm, and
Source Code in C", Wiley, John & Sons, Inc., XP002138607; ISBN
0471117099, (Oct. 1995),56-65. cited by other .
Schneier, Bruce, "Applied Cryptography: Protocols, Algorithms, and
Source Code C", Wiley, John & Sons, Inc., XP0021111449; ISBN
0471117099, (Oct. 1995),169-187. cited by other .
Schneier, Bruce, "Applied Cryptography: Protocols, Algorithms, and
Source Code in C", 2nd Edition: Wiley, John & Sons, Inc.,
XP002251738; ISBN 0471128457,(Nov. 1995),28-33; 176-177; 216-217;
461-473; 518-522. cited by other .
Sherwood, Timothy, et al., "Patchable Instruction ROM
Architecture", Department of Computer Science and Engineering,
University of California, San Diego, La Jolla, CA, (Nov. 2001).
cited by other .
Rosenblum, et al., "Virtual machine monitors: current technology
and future trends," IEEE Xplore, abstract, Publication Date: May
2005, 2 pages. cited by other .
Ahmad, et al., "An analysis of disk performance in VMware ESX
server virtual machines," Abstract only, publication date Oct. 27,
2003. cited by other .
U.S. Appl. No. 10/676,890, Office Action dated Sep. 12, 2005, 6
pages. cited by other .
U.S. Appl. No. 10/676,890, Office Action dated Nov. 3, 2005, 17
pages. cited by other .
U.S. Appl. No. 10/676,890, Notice of Allowance dated Mar. 6, 2006,
4 pages. cited by other .
U.S. Appl. No. 10/676,890, Notice of Allowance dated Apr. 24, 2006,
9 pages. cited by other .
U.S. Appl. No. 10/676,890, Notice of Allowance dated Sep. 1, 2006,
9 pages. cited by other.
|
Primary Examiner: Ray; Gopal C.
Attorney, Agent or Firm: Blakely, Sokoloff, Taylor &
Zafman LLP
Parent Case Text
RELATED APPLICATIONS
This application is a divisional of U.S. patent application Ser.
No. 10/676,890, now U.S. Pat. No. 7,177,967, filed Sep. 30, 2003.
Claims
What is claimed is:
1. A method comprising: receiving, at a multiplex block, an
interrupt request signal from a device via an interrupt request
line coupled with the multiplex block; and determining, based on a
current configuration value of the multiplex block, whether the
interrupt request signal is to be sent to an interrupt controller
or a virtual machine monitor (VMM) block coupled to the multiplex
block, wherein the current configuration value of the multiplex
block requires that the interrupt request signal be sent to the
interrupt controller or the VMM block depending on whether the
device is managed by a currently-operating virtual machine (VM) or
is not managed by the currently-operating VM respectively.
2. The method of claim 1 further comprising determining whether the
interrupt request signal sent to the VMM block is masked based on
data stored in a mask register of the VMM block.
3. The method of claim 1 further comprising updating a
corresponding indicator in a status register of the VMM block upon
receiving the interrupt request signal at the VMM block.
4. The method of claim 1 further comprising: determining that the
interrupt request signal received at the VMM block is not masked;
asserting an internal signal; combining the internal signal with an
external signal generated by an external signal source; and
transmitting the combined signal to a processor.
5. The method of claim 4 wherein: the external signal is a
non-maskable interrupt (NMI) signal; and the designated external
signal source is a NMI source.
6. A method comprising: identifying one or more interrupt request
lines that are coupled to one or more devices managed by a virtual
machine (VM); configuring one or more multiplex blocks to route
only interrupt request signals on the one or more interrupt request
lines associated with the VM to an interrupt controller;
configuring one or more multiplex blocks to route interrupt request
signals on interrupt request lines that are not managed by the VM
to a vritual machine monitor (VMM) block; and generating a request
to transfer control to the VM.
7. The method of claim 6 further comprising: configuring a mask
register in the VMM block to cause blocking of interrupt request
signals routed to the VMM block.
8. The method of claim 7 further comprising: restoring a state
saved during a previous operation of the VM in the interrupt
controller.
9. A machine-readable medium containing instructions which, when
executed by a processing system, cause the processing system to
perform a method, the method comprising: identifying one or more
interrupt request lines that are coupled to one or more devices
managed by a virtual machine (VM); configuring one or more
multiplex blocks to route only interrupt request signals on the one
or more interrupt request lines associated with the VM to an
interrupt controller; configuring one or more multiplex blocks to
route interrupt request signals on interrupt request lines that are
not managed by the VM to a virtual machine monitor (VMM) block; and
generating a request to transfer control to the VM.
10. The machine-readable medium of claim 9 wherein the method
further comprises: configuring a mask register in the VMM block to
cause masking/unmasking of interrupt request signals routed to the
VMM block.
11. The machine-readable medium of claim 10 wherein the method
further comprises: restoring a state saved during a previous
operation of the VM in the interrupt controller.
12. An apparatus comprising: an interrupt controller; a virtual
machine monitor (VMM) block; and a multiplex block, couplable with
the interrupt controller and the VMM block, to receive an interrupt
request signal from a device via an interrupt request line coupled
with the multiplex block, and to determine, based on a current
configuration value of the multiplex block, whether the interrupt
request signal is to be sent to the interrupt controller or the VMM
block, wherein the current configuration value of the multiplex
block requires that the interrupt request signal be sent to the
interrupt controller or the VMM block depending on whether the
device is managed by a currently-operating virtual machine (VM) or
is not managed by the currently-operating VM respectively.
13. The apparatus of claim 12 wherein the VMM block comprises a
mask register to store data indicating whether the interrupt
request sent to the VMM block is masked.
Description
FIELD
Embodiments of the invention relate generally to virtual machines,
and more specifically to managing hardware interrupts in a virtual
machine system.
BACKGROUND OF THE INVENTION
In a typical computer system, devices request services from system
software by generating interrupt requests, which are propagated to
an interrupt controller via multiple interrupt request lines. Once
the interrupt controller identifies an active interrupt request
line, it sends an interrupt signal to the processor. In response,
the interrupt controller interface logic on the processor
determines whether the software is ready to receive the interrupt.
If the software is not ready to receive the interrupt, the
interrupt is held in a pending state until the software becomes
ready. Once the software is determined to be ready, the interrupt
controller interface logic requests the interrupt controller to
report which of the pending interrupts is highest priority. The
interrupt controller prioritizes among the various interrupt
request lines and identifies the highest priority interrupt request
to the processor which then transfers control flow to the code that
handles that interrupt request.
In a conventional operating system (OS), all the interrupts are
controlled by a single entity known as an OS kernel. In a virtual
machine system, a virtual-machine monitor (VMM) should have
ultimate control over various operations and events occurring in
the system to provide proper operation of virtual machines and for
protection from and between virtual machines. To achieve this, the
VMM typically receives control when guest software accesses certain
hardware resources or certain events occur, such as an interrupt or
an exception. In particular, when system devices generate
interrupts, the VMM may intercede between the virtual machine and
the interrupt controllering device. That is, when an interrupt
signal is raised, the currently running virtual machine is
interrupted and control of the processor is passed to the VMM. The
VMM then receives the interrupt and handles the interrupt or
delivers the interrupt to an appropriate virtual machine.
BRIEF DESCRIPTION OF THE DRAWINGS
The present invention is illustrated by way of example, and not by
way of limitation, in the figures of the accompanying drawings and
in which like reference numerals refer to similar elements and in
which:
FIG. 1 illustrates one embodiment of a virtual-machine environment,
in which the present invention may operate;
FIG. 2 is a block diagram of one embodiment of a system for
processing interrupts in a virtual machine environment;
FIG. 3 is a flow diagram of one embodiment of a process for
handling interrupts in a virtual machine system;
FIG. 4 is a flow diagram of one embodiment of a process for
configuring the handling of interrupts during execution of a
virtual machine in a virtual machine system; and
FIG. 5 is a flow diagram of one embodiment of a process for
managing the configuration of the chipset interrupt control during
a switch in virtual machines in a virtual machine system.
DESCRIPTION OF EMBODIMENTS
A method and apparatus for controlling interrupts in a virtual
machine system are described. In the following description, for
purposes of explanation, numerous specific details are set forth in
order to provide a thorough understanding of the present invention.
It will be apparent, however, to one skilled in the art that the
present invention can be practiced without these specific
details.
Some portions of the detailed descriptions that follow are
presented in terms of algorithms and symbolic representations of
operations on data bits within a computer system's registers or
memory. These algorithmic descriptions and representations are the
means used by those skilled in the data processing arts to most
effectively convey the substance of their work to others skilled in
the art. An algorithm is here, and generally, conceived to be a
self-consistent sequence of operations leading to a desired result.
The operations are those requiring physical manipulations of
physical quantities. Usually, though not necessarily, these
quantities take the form of electrical or magnetic signals capable
of being stored, transferred, combined, compared, and otherwise
manipulated. It has proven convenient at times, principally for
reasons of common usage, to refer to these signals as bits, values,
elements, symbols, characters, terms, numbers, or the like.
It should be borne in mind, however, that all of these and similar
terms are to be associated with the appropriate physical quantities
and are merely convenient labels applied to these quantities.
Unless specifically stated otherwise as apparent from the following
discussions, it is appreciated that throughout the present
invention, discussions utilizing terms such as "processing" or
"computing" or "calculating" or "determining" or the like, may
refer to the action and processes of a computer system, or similar
electronic computing device, that manipulates and transforms data
represented as physical (electronic) quantities within the computer
system's registers and memories into other data similarly
represented as physical quantities within the computer-system
memories or registers or other such information storage,
transmission or display devices.
In the following detailed description of the embodiments, reference
is made to the accompanying drawings that show, by way of
illustration, specific embodiments in which the invention may be
practiced. In the drawings, like numerals describe substantially
similar components throughout the several views. These embodiments
are described in sufficient detail to enable those skilled in the
art to practice the invention. Other embodiments may be utilized
and structural, logical, and electrical changes may be made without
departing from the scope of the present invention. Moreover, it is
to be understood that the various embodiments of the invention,
although different, are not necessarily mutually exclusive. For
example, a particular feature, structure, or characteristic
described in one embodiment may be included within other
embodiments. The following detailed description is, therefore, not
to be taken in a limiting sense, and the scope of the present
invention is defined only by the appended claims, along with the
full scope of equivalents to which such claims are entitled.
Although the below examples may describe embodiments of the present
invention in the context of execution units and logic circuits,
other embodiments of the present invention can be accomplished by
way of software. For example, in some embodiments, the present
invention may be provided as a computer program product or software
which may include a machine or computer-readable medium having
stored thereon instructions which may be used to program a computer
(or other electronic devices) to perform a process according to the
present invention. In other embodiments, steps of the present
invention might be performed by specific hardware components that
contain hardwired logic for performing the steps, or by any
combination of programmed computer components and custom hardware
components.
Thus, a machine-readable medium may include any mechanism for
storing or transmitting information in a form readable by a machine
(e.g., a computer), but is not limited to, floppy diskettes,
optical disks, Compact Disc, Read-Only Memory (CD-ROMs), and
magneto-optical disks, Read-Only Memory (ROMs), Random Access
Memory (RAM), Erasable Programmable Read-Only Memory (EPROM),
Electrically Erasable Programmable Read-Only Memory (EEPROM),
magnetic or optical cards, flash memory, a transmission over the
Internet, electrical, optical, acoustical or other forms of
propagated signals (e.g., carrier waves, infrared signals, digital
signals, etc.) or the like.
Further, a design may go through various stages, from creation to
simulation to fabrication. Data representing a design may represent
the design in a number of manners. First, as is useful in
simulations, the hardware may be represented using a hardware
description language or another functional description language.
Additionally, a circuit level model with logic and/or transistor
gates may be produced at some stages of the design process.
Furthermore, most designs, at some stage, reach a level of data
representing the physical placement of various devices in the
hardware model. In the case where conventional semiconductor
fabrication techniques are used, data representing a hardware model
may be the data specifying the presence or absence of various
features on different mask layers for masks used to produce the
integrated circuit. In any representation of the design, the data
may be stored in any form of a machine-readable medium. An optical
or electrical wave modulated or otherwise generated to transmit
such information, a memory, or a magnetic or optical storage such
as a disc may be the machine readable medium. Any of these mediums
may "carry" or "indicate" the design or software information. When
an electrical carrier wave indicating or carrying the code or
design is transmitted, to the extent that copying, buffering, or
re-transmission of the electrical signal is performed, a new copy
is made. Thus, a communication provider or a network provider may
make copies of an article (a carrier wave) embodying techniques of
the present invention.
FIG. 1 illustrates one embodiment of a virtual-machine environment
100, in which the present invention may operate. In this
embodiment, bare platform hardware 116 comprises a computing
platform, which may be capable, for example, of executing a
standard operating system (OS) or a virtual-machine monitor (VMM),
such as a VMM 112.
The VMM 112, though typically implemented in software, may emulate
and export a bare machine interface to higher level software. Such
higher level software may comprise a standard or real-time OS, may
be a highly stripped down operating environment with limited
operating system functionality, may not include traditional OS
facilities, etc. Alternatively, for example, the VMM 112 may be run
within, or on top of, another VMM. VMMs may be implemented, for
example, in hardware, software, firmware or by a combination of
various techniques.
The platform hardware 116 can be of a personal computer (PC),
mainframe, handheld device, portable computer, set-top box, or any
other computing system. The platform hardware 116 includes a
processor 118, memory 120, chipset core logic 122 and one or more
interrupt sources 128.
Processor 118 can be any type of processor capable of executing
software, such as a microprocessor, digital signal processor,
microcontroller, or the like. The processor 118 may include
microcode, programmable logic or hardcoded logic for performing the
execution of method embodiments of the present invention. Though
FIG. 1 shows only one such processor 118, there may be one or more
processors in the system.
Memory 120 can be a hard disk, a floppy disk, random access memory
(RAM), read only memory (ROM), flash memory, any combination of the
above devices, or any other type of machine medium readable by
processor 118. Memory 120 may store instructions and/or data for
performing the execution of method embodiments of the present
invention.
The one or more interrupt sources 128 may be, for example,
input-output (I/O) devices (e.g., network interface cards,
communication ports, video controllers, disk controllers) on system
buses (e.g., PCI, ISA, AGP) or devices integrated into the chipset
logic or processor (e.g., real-time clocks, programmable timers,
performance counters).
The VMM 112 presents to other software (i.e., "guest" software) the
abstraction of one or more virtual machines (VMs), which may
provide the same or different abstractions to the various guests.
FIG. 1 shows two VMs, 102 and 114. The guest software running on
each VM may include a guest OS such as a guest OS 104 or 106 and
various guest software applications 108 and 110. Each of the guest
OSs 104 and 106 expect to access physical resources (e.g.,
processor registers, memory and I/O devices) within the VMs 102 and
114 on which the guest OS 104 or 106 is running and to handle
various events including interrupts generated by system devices
during the operation of the VMs 102 and 114.
Some interrupts may need to be handled by a currently operating VM.
Other interrupts may need to be handled by the VMM 112 or a VM that
is not currently operating. If the interrupt is to be handled by
the currently-operating VM, control remains with this VM, and the
interrupt is delivered to this VM if it is ready to receive
interrupts (as indicated, for example, by an interrupt flag in a
designated processor register). If the interrupt is to be handled
by the VMM 112, control is transferred to the VMM 112. The transfer
of control from guest software to the VMM 112 is referred to herein
as a VM exit. After receiving control following the VM exit, the
VMM 112 may perform a variety of processing, including, for
example, acknowledging and handling the interrupt, after which it
may return control to guest software. If the VMM does not handle
the interrupt itself, it may facilitate delivery of the interrupt
to a VM designated to handle the interrupt. The transfer of control
from the VMM to guest software is referred to as a VM entry.
In one embodiment, the processor 118 controls the operation of the
VMs 102 and 114 in accordance with data stored in a virtual machine
control structure (VMCS) 124. The VMCS 124 is a structure that may
contain state of guest software, state of the VMM 112, execution
control information indicating how the VMM 112 wishes to limit or
otherwise control operation of guest software, information
controlling transitions between the VMM 112 and a VM, etc. In one
embodiment, the VMCS 124 is stored in memory 120. In another
embodiment, the VMCS 124 is stored in the processor 118. In some
embodiments, multiple VMCS structures are used to support multiple
VMs.
The processor 118 reads information from the VMCS 124 to determine
the execution environment of the VM and to constrain its behavior.
For example, the processor 118 may consult the execution control
information in the VMCS to determine if external interrupts are to
cause VM exits. When a VM exit occurs, components of the processor
state used by guest software are saved to the VMCS 124, and
components of the processor state required by the VMM 112 are
loaded from the VMCS 124. When a VM entry occurs, the processor
state that was saved at the VM exit is restored using data stored
in the VMCS 124, and control is returned to guest software.
In one embodiment, chipset core logic 122 is coupled to the
processor 118 to assist the processor 118 in handling interrupts
generated by the interrupt sources 128, described below. The
chipset logic 122 may be part of the processor 118 or an
independent component. The chipset logic 122 may include microcode,
programmable logic or hardcoded logic for performing the execution
of method embodiments of the present invention. Though FIG. 1 shows
only one chipset logic 122, the system may contain one or more such
chipsets.
As will be discussed in more detail below, the chipset core logic
122 controls the distribution of interrupts generated by the one or
more interrupt sources 128. If an interrupt is generated by a
device that is managed by a currently operating VM, the chipset
core logic 122 sends the interrupt request to the processor 118 for
delivery to the currently operating VM. If an interrupt is
generated by a device that is not managed by a currently operating
VM, the chipset core logic 122 either holds the interrupt pending
or indicates to the processor 118 that control is to be
transitioned to the VMM 112.
FIG. 2 is a block diagram of one embodiment of a system 200 for
processing interrupts in a virtual machine environment. The system
200 includes a processor 220 and chipset core logic 202. The system
200 is active during operation of the VMM and during operation of
guest software. The term "currently operating software" is used
herein to refer to the VMM or the currently operating guest
software (i.e., the currently operating VM).
In one embodiment, the chipset core logic 202 includes an interrupt
controller 204, a set of multiplex blocks 206, and a VMM block
210.
The interrupt controller 204 receives interrupt request signals
generated by system devices and delivers interrupt requests (INTRs)
to the processor 220. In an embodiment, the processor acknowledges
an interrupt request from the interrupt controller 204 by an
interrupt acknowledgement bus cycle (INTA), for which the interrupt
controller 204 returns the vector number of the interrupt service
routine to be executed to service the interrupt.
The interrupt controller 204 has a state machine and a number of
registers, which may include readable and writable registers,
read-only registers and write-only registers. In one embodiment,
the interrupt controller 204 includes a read and write access path
to its registers to allow a VMM to save the current state of the
interrupt controller 204 (e.g., in the VMCS or in a VMM data
structure) and to restore the interrupt controller state associated
with a VM that is to be invoked. In addition, in one embodiment,
the current state of the state machine in the interrupt controller
204 is readable and writable to allow the VMM to switch VMs. In
another embodiment, the state machine in the interrupt controller
204 is readable and the VMM has to replay a series of writes to the
interrupt controller 204 to place the interrupt controller 204 into
the correct state.
The interrupt controller 204 may be a conventional interrupt
controller (e.g., an 8259A interrupt controller) that is enhanced
to provide a read and write access path to its registers and state
machine. The read and write access path may be implemented, for
example, as an extension to chipset specific registers to provide
the behavior that is identical to the behavior of the conventional
interrupt controller (e.g., the read-only registers remain
read-only unless being accessed by the VMM). This can be achieved,
for example, by providing access to the registers of the interrupt
controller through memory mapped I/O registers. The interrupt
controller 204 may include masking and prioritization logic that is
known to one of ordinary skill in the art.
The interrupt controller 204 is coupled to the multiplex blocks
206. The number of multiplex blocks 206 is equal to the number of
interrupt request lines 208. Each interrupt request line 208
propagates interrupt requests generated by a specific device to a
corresponding multiplex block 206.
In a virtual machine system, a device may be managed by a certain
VM and generate interrupts that need to be delivered to this VM.
For example, a video capture card may be managed directly by a
single VM and may not be visible to other VMs. Alternatively, a
device may be managed by several VMs and generate interrupts that
need to be delivered to multiple VMs. Yet, alternatively, the
device may be managed by the VMM and generate interrupts that need
to be delivered to the VMM. For example, an integrated drive
electronics (IDE) controller may be managed exclusively by the
VMM.
Each multiplex block 206 receives interrupt request signals
generated by a specific device. Depending on its setting, each
multiplex block 206 may route an interrupt request signal to the
interrupt controller 204 or the VMM block 210. In one embodiment,
the multiplex blocks 206 are set by the VMM. The VMM may set the
multiplex blocks 206 prior to requesting a VM entry and/or
following a VM exit. In another embodiment, the multiplex blocks
206 are set by the processor as part of a VM entry and/or a VM
exit. The values used to set the multiplex blocks 206 may be stored
in the VMCS or in any other data structure.
In one embodiment illustrated in FIG. 2, when a multiplex block 206
is set to route interrupt request signals generated by a
corresponding device to the interrupt controller 204, the interrupt
request signal may be routed to a specific input of the interrupt
controller 204. For example, FIG. 2 shows interrupt IRQ0 being
routed to input 1 of the interrupt controller 204 and IRQ1 is shown
routed to input 0 of the interrupt controller 204. Other
embodiments allow the interrupt request signal to be routed to a
single fixed input of the interrupt controller 204.
In addition, in the embodiment illustrated in FIG. 2, when a
multiplex block 206 is set to route interrupt request signals
generated by a corresponding device to the VMM block 210, the
interrupt request signal can be routed to a fixed input of the VMM
block 210. For example, in the example shown in FIG. 2, IRQn is
routed to the n.sup.th input of the VMM block 210. In another
embodiment, the interrupt request signal may be routed by the
multiplex block 206 to an arbitrary input of the VMM block 210.
The VMM block 210 includes a number of input lines connected to the
output lines of the multiplex blocks 206. The VMM block 210
generates an output signal indicating to the processor 200 that
control needs to be transitioned to the VMM. In one embodiment, the
output signal is generated by combining the interrupt request
signals routed to the VMM block 210 with an external signal
generated by an external signal source 218. An external signal may
be any signal, other than a signal of an external interrupt type,
that may be configured by the VMM to cause a VM exist. For example,
as shown in FIG. 2, an external signal may be a non-maskable
interrupt (NMI) signal that is configured to cause a VM exit each
time the NMI occurs. The interrupt request signals are combined
with the external signal using a Boolean OR operator illustrated by
a gate 216.
In one embodiment, the VMM block 210 includes a mask register 212
that can mask an interrupt request signal routed to the VMM block
210. In one embodiment, the VMM configures the mask register 212 to
allow masking of interrupt request signals generated by certain
devices. Masking may be used when the VMM does not need to be
notified about interrupts generated by a device managed exclusively
by a non-currently operating VM. In one embodiment, the mask
register 212 is set by the VMM. The VMM may set the mask register
212 prior to requesting a VM entry and/or following a VM exit. In
another embodiment, the mask register 212 is set by the processor
as part of a VM entry and/or a VM exit. The value used to set the
mask register 212 may be stored in the VMCS or in any other data
structure.
In one embodiment, the VMM block 210 includes a status register 214
that stores status of interrupt input lines of the VMM block 210.
In one embodiment, when an interrupt request signal is asserted on
an interrupt input line of the VMM block 210, a bit associated with
this interrupt input line in the status register 214 is set. The
status register 214 may be read by the VMM to obtain the status of
the interrupt input lines of the VMM block 210. The status may be
used, for example, to determine whether the output signal sent to
the processor 220 by the VMM block 210 resulted from an interrupt
propagated from an interrupt request line 208 or from an external
signal (e.g., an NMI signal) generated by the external signal
source 218.
As discussed above, in one embodiment, the VMM configures the
multiplex blocks 206 prior to requesting a transfer of control to a
VM. In this embodiment, once the control is transferred to a VM as
requested by the VMM, only interrupt request signals generated by
devices managed by the VM are allowed to reach the interrupt
controller 204. Interrupts managed by the VMM are routed to the VMM
block 210. Interrupts managed by other VMs are routed to the VMM
block and may be masked using masking register 212. Thus, the
chipset core logic 202 allows a currently-operating VM to control
all the interrupts generated by the devices managed by the
currently-operating VM, while allowing the VMM to gain control over
interrupts generated by devices owned by the VMM and other VMs.
In some embodiments, the chipset core logic 202 may include
multiple interrupt controllers 204, with each interrupt controller
204 serving a corresponding VM. In those embodiments, the VMM does
not need to save and restore the state of the interrupt controller
each time it switches from one VM to another.
As discussed above, in some embodiments, the multiplex blocks 206
and mask register 212 are configured as part of a VM entry (e.g.,
by the VMM before requesting a VM entry or by the processor when
performing a VM entry). Hence, the settings of the multiplex blocks
206 and mask register 212 remain unchanged following a VM exit, and
interrupts generated during the operation of the VMM are routed
according to the settings of a previously-operating VM. That is, if
interrupts are not masked by the VMM, they may be delivered to the
VMM via the interrupt controller 204 or the VMM block 210 using the
mechanisms discussed above. The designated software within the VMM
then handles these interrupts appropriately.
In other embodiments, the multiplex blocks 206 and mask register
212 are configured as part of a VM exit (e.g., by the VMM following
a VM exit or by the processor when performing a VM exit). Hence,
the multiplex blocks 206 and mask register 212 may be changed to
route interrupts generated during the operation of the VMM
differently than during operation of the VM which was running
previously.
FIG. 3 is a flow diagram of one embodiment of a process 300 for
handling interrupts in a virtual machine system. The process may be
performed by processing logic that may comprise hardware (e.g.,
circuitry, dedicated logic, programmable logic, microcode, etc.),
software (such as run on a general purpose computer system or a
dedicated machine), or a combination of both. In one embodiment,
processing logic is implemented in chipset core logic 202 of FIG.
2.
Referring to FIG. 3, process 300 begins with processing logic
receiving, at a multiplex block, an interrupt request signal
generated by a device (processing block 302). As discussed above,
each multiplex block is coupled with a distinct interrupt request
line that delivers interrupt request signals generated by a certain
device.
At decision box 304, processing logic determines whether the
interrupt request signal is to be routed to the interrupt
controller. In one embodiment, this determination is done based on
the configuration performed by the VMM.
If the determination made at decision box 304 is positive,
processing logic sends the interrupt request signal to the
interrupt controller (processing block 306), which may, according
to the architecture of the interrupt controller, send the interrupt
request to the processor (processing block 308). The interrupt
controller may perform masking and prioritization of
interrupts.
If the determination made at decision box 304 is negative,
processing logic routes the interrupt request signal to the VMM
block (processing block 310) and updates a status register of the
VMM block to indicate that a signal has been asserted on an
interrupt input line of the VMM block (processing block 312). Next,
processing logic determines whether the interrupt request signal
routed to the VMM block is masked (decision box 314). In one
embodiment, the determination is made based on data set by the VMM
in a mask register of the VMM block. If the interrupt request
signal is masked, processing logic holds the interrupt pending
(processing block 316). The interrupt may be held pending, for
example, until a VM managing the device that generated this
interrupt is invoked. At the time the VM managing the device is
invoked, the VMM will modify the configuration of the multiplex
blocks to route the interrupt request to the interrupt controller
and hence allow the VM to manage the device directly.
If the interrupt request signal is not masked, processing logic
generates an internal signal (processing block 318), combines the
internal signal with an external signal generated by a designated
external signal source (e.g., an NMI source) using the OR operator
(processing block 320), and delivers the resulting output signal to
the processor (processing block 322).
The output signal may cause the processor to transfer control to
the VMM. The VMM may then read the status register of the VMM
block, determine that the signal resulted from an external
interrupt, and handle this external interrupt itself or invoke an
appropriate VM to handle it. It should be noted that an external
signal (e.g., NMI) causing the output signal may require some
predefined operations to be performed by the processor when
asserted. If these predefined operations are different from the
desired behavior, then the processor blocks the output signal to
avoid the occurrence of the predefined operations. For example, an
NMI may cause a transition within the VMM (e.g., by vectoring the
NMI) when it is asserted during operation of the VMM. Blocking the
NMI signal following the VM exit caused by the assertion of the NMI
prevents the occurrence of the predefined transition within the
VMM.
FIG. 4 is a flow diagram of one embodiment of a process 400 for
handling interrupts in a virtual machine system. The process may be
performed by processing logic that may comprise hardware (e.g.,
circuitry, dedicated logic, programmable logic, microcode, etc.),
software (such as run on a general purpose computer system or a
dedicated machine), or a combination of both. In one embodiment,
processing logic is implemented in a VMM such as the VMM 112 of
FIG. 1.
Referring to FIG. 4, process 400 begins with processing logic
identifying interrupt request lines that are coupled to devices
managed by a VM to be invoked (processing block 401). In one
embodiment, these interrupt request lines are identified using data
stored in the VMCS or any other data structure.
Next, processing logic configures a set of multiplex blocks
(processing block 402). Based on this configuration, only interrupt
request signals from the devices managed by the VM to be invoked
can reach the interrupt controller. All the remaining interrupt
signals are to be routed to the VMM block. In addition, in another
embodiment, the VMM may configure the multiplex blocks to route the
interrupt to a particular input of the VMM block.
At processing block 404, processing logic configures a mask
register in the VMM block to allow selective masking of interrupt
request signals routed to the VMM block. The selective masking can
be used, for example, to hold some interrupt requests pending.
Interrupt requests may be held pending if, for example, the VMM
does not need to be notified about these interrupt requests because
they come from a device that is managed exclusively by another VM.
However, some interrupts belonging to another VM may not be masked
if, for example, the other VM needs to run at a higher priority
than the currently running VM. An example of such a situation is a
VM which maintains some real-time quality of service with respect
to some device (e.g., all interrupts need to be serviced in a
specific amount of time).
At processing block 408, processing logic sets designated execution
control fields in the VMCS to allow the VM being invoked to control
I/O accesses to the interrupt controller and delivery of hardware
interrupts. For example, the VMM may set designated execution
control fields in the VMCS such that accesses to the I/O ports of
the interrupt controller do not cause VM exits.
At processing block 410, processing logic sets a designated
execution control field in the VMCS to cause a VM exit on each
event generated when the VMM block asserts its output signal to the
CPU. In one embodiment, the event may be a non-maskable interrupt
(NMI). Other embodiments may use other events, according to the
architecture of the chipset core logic and system. The VMM may also
need to set controls such that certain predefined operations
following VM exits are prevented from happening. For example, if
the output signal of the VMM block of FIG. 2 is coupled to the NMI
input of the processor, then the NMI signal may need to be blocked
following VM exits that result from the assertion of the NMI
signal.
At processing block 412, processing logic executes a VM entry
instruction to request a transfer of control to the VM. Any
mechanism in the art may be used to facilitate this transfer of
control to the VM. After the transfer of control to the VM, the VM
can directly access the interrupt controller (e.g., using I/O
operations) and interrupts routed through the interrupt controller
will be handled directly by the VM, with no intervention by the
VMM.
FIG. 5 is a flow diagram of one embodiment of a process 500 for
managing chipset core logic state during a switch from one VM to
another VM. The process may be performed by processing logic that
may comprise hardware (e.g., circuitry, dedicated logic,
programmable logic, microcode, etc.), software (such as run on a
general purpose computer system or a dedicated machine), or a
combination of both. In one embodiment, processing logic is
implemented in a VMM such as the VMM 112 of FIG. 1.
Referring to FIG. 5, process 500 begins with processing logic
recognizing that a transfer of control from one VM to another VM is
pending (processing block 510). This may occur, for example, if the
VMM is managing more than one VM, providing time slices to each VM
in turn, similarly to how a traditional operating system may time
slice processes on a single CPU.
At processing block 520, processing logic saves the current state
of the interrupt controller. The state may be saved in the VMCS or
any other designated data structure. In an embodiment, this saving
of state is performed by the VMM. In another embodiment, the saving
of the interrupt controller state is performed by the processor. In
one embodiment, the savings of the interrupt controller state is
performed as part of the processing at the time of a VM exit.
Additionally, processing logic may need to save the state of the
multiplex controls, and the VMM block masking register. The saving
of state relies on having the ability to read all appropriate state
in the chipset core logic, as described above.
At processing block 540, processing logic restores the chipset core
logic state from the previous operation of the VM to be activated.
This restoration includes writing all appropriate state to the
interrupt controller to configure the masking and control registers
and state machine configuration that was present when the VM to be
activated was last active. Additionally, the multiplex blocks and
VMM block controls (e.g., masking register) in the chipset core
logic may need to be reconfigured for the new VM, as described
above. This restoration of state relies on having the ability to
write to all appropriate state in the chipset core logic. In one
embodiment, this restoration of chipset core logic state is
performed by the VMM. In another embodiment, it is performed by the
processor as part of the VM entry to the new VM.
At processing block 560, the VMM requests a transfer of control to
the VM. In one embodiment, the VMM executes an instruction to
initiate the transfer. Any mechanism in the art may be used to
facilitate this transfer of control to the VM.
It should be noted that process 500 assumes that the execution
controls were set appropriately prior to the first entry to the new
VM (as described with regard to process 400).
Thus, a method and apparatus for handling interrupts in a virtual
machine system have been described. It is to be understood that the
above description is intended to be illustrative, and not
restrictive. Many other embodiments will be apparent to those of
skill in the art upon reading and understanding the above
description. The scope of the invention should, therefore, be
determined with reference to the appended claims, along with the
full scope of equivalents to which such claims are entitled.
* * * * *
References