Abstract:
An interrupt processing technique is provided where an interrupt message is sent to an interrupt controller of a processor in response to an interrupt request from an individual device. The interrupt message comprises a memory address and interrupt status information. The memory address is specifically allocated to the device that has issued the interrupt request. The interrupt status information indicates an interrupt status of the device. An interrupt table that is stored in the memory is updated by the interrupt controller using the interrupt status information comprised in the interrupt message. The interrupt table holds device specific interrupt statuses. Updating the interrupt table comprises addressing the memory using the memory address in the interrupt message.

Description:
BACKGROUND OF THE INVENTION  
       [0001]     1. Field of the Invention  
         [0002]     The invention generally relates to computer systems, processors and corresponding operation methods, and in particular to techniques for processing interrupts.  
         [0003]     2. Description of the Related Art  
         [0004]     Generally, an interrupt can be described as an asynchronous event that suspends normal processing and temporarily diverts the flow of control through an “interrupt handler” routine. Interrupts may be caused by both hardware and software. Interrupt techniques are frequently used in many existing computer system technologies.  
         [0005]     Referring to  FIG. 1 , the hardware components of a common computer system layout are depicted. It is to be noted that this figures shows only one example of a motherboard layout, and other configurations exist as well. The basic elements found on the motherboard of  FIG. 1  include the CPU (Central Processing Unit)  100 , a northbridge  105 , a southbridge  110 , and system memory  115 .  
         [0006]     The northbridge  105  usually is a single chip in a core-logic chipset that connects the processor  100  to the system memory  115  and, e.g., to the AGP (Accelerated Graphic Port) and PCI (Peripheral Component Interface) buses. The PCI bus is commonly used in personal computers for providing a data path between the processor  100  and peripheral devices like video cards, sound cards, network interface cards and modems. The AGP bus is a high-speed graphic expansion bus that directly connects the display adapter and system memory  115 . AGP operates independently of the PCI bus.  
         [0007]     The southbridge  110  is usually the chip in a system core-logic chipset that controls the IDE (Integrated Drive Electronics) or EIDE (Enhanced IDE) bus, the USB (Universal Serial Bus), that provides plug-n-play support, controls the PCI-ISA (Industry Standard Architecture) bridge, manages the keyboard/mouse controller, provides power management features, and controls other peripherals.  
         [0008]     In modern computer systems, two different kinds of interrupts can be distinguished: level sensitive interrupts (or level triggered interrupts) and edge triggered interrupts. Generally speaking, level sensitive interrupts can be viewed to define a condition for an interrupt whereas edge triggered interrupts can be viewed as a discrete event.  
         [0009]     Standard PCI functions and devices use level sensitive interrupts. Level sensitive interrupts can be shared by multiple I/O devices, meaning that multiple I/O devices can share the same interrupt line even though individually the interrupts from each device are discrete events. That is, multiple devices can all assert the line, and when a level sensitive interrupt occurs, the ISR (Interrupt Service Routine) must poll all the devices that are sharing the interrupt line.  
         [0010]     Edge triggered interrupts are handled differently from level sensitive interrupts because a single edge triggered interrupt counts as a single occurrence of an event while level sensitive interrupts are conditions that exist. Modern bus concepts use e.g., MSI (Message Signal Interrupt) transport mechanisms to reduce the number of sideband signals. Message signal interrupts are edge triggered.  
         [0011]     A conventional technique for dealing with interrupts is specified in the APIC (Advanced Programmable Interrupt Controller) standard. It is used primarily in multiprocessor systems and supports interrupt redirection and interrupt transmission between processors.  
         [0012]     Referring to  FIG. 2 , APIC consists of two parts at the system level. One part  250  resides in the I/O subsystem and is called I/O APIC. The other part is the so-called Local APIC  220  in the processor  200 . The Local APIC  220  and the I/O APIC  250  communicate over a dedicated APIC bus  240 . The I/O APIC bus interface consists of two bi-directional data signals and a clock signal.  
         [0013]     The Local APIC unit  220  of the processor  200  contains the necessary intelligence to determine whether or not the processor  200  should accept interrupts broadcast on the APIC bus  240 . The Local APIC  220  also provides local pending of interrupts, nesting and masking of interrupts, and handles all interactions with its local processor  200 . The I/O APIC unit  250  consists of a set of interrupt input signals, an interrupt redirection table, programmable registers, and a message unit for sending and receiving APIC messages over the APIC bus  240 . The I/O APIC unit  250  selects the corresponding entry in the redirection table and uses the information in that entry to format an interrupt request message. Each interrupt pin is individually programmable as either edge or level triggered.  
         [0014]      FIG. 3  illustrates a conventional system configuration that uses APIC. As apparent from  FIG. 3 , the I/O APIC unit  330  is located in the southbridge device  320 .  
         [0015]     When a peripheral interrupt request occurs, the I/O APIC unit  330  sends an interrupt message to the processor  300 . The WSC# (Write Snoop Complete) protocol forces the northbridge  310  and the processor  300  to snoop all posted writes, and provide a status indicator to the southbridge  320 . The southbridge  320  (and the I/O APIC unit  330 ) is now free to issue a message to the processor  300  on the interrupt bus.  
         [0016]     Another conventional approach is shown in  FIG. 4 . If a peripheral interrupt request occurs, the PIC (Programmable Interrupt Controller)  430  located in the southbridge  420  sends an interrupt request to the processor  400  on the INTR pin. The processor  400  then responds with an interrupt acknowledge cycle which forces the northbridge  410  to flush all posted writes.  
         [0017]     In the conventional techniques, the general procedure is that the computer responds to an interrupt by storing the information about the current state of the running program, storing information to identify the source of the interrupt, and invoking a first-level interrupt handler. This first-level interrupt handler can discover the precise cause of the interrupt (e.g. if several devices share one interrupt) and what must be done to keep operating system tables (such as the process table) updated. This first-level handler may then call another handler, e.g. one associated with the particular device which generated the interrupt, i.e. a device driver.  
         [0018]     However, the conventional techniques suffer from the additional communication necessary to identify the device which has experienced the interrupt event. That is, the drivers need to send a read request to access a register in the device, and the read information needs to be sent back to the driver. This may produce severe interrupt latencies. In particular where interrupts are shared by multiple devices, the drivers need to be successively activated so that each driver can check whether the interrupt event occurred at one of the devices that are associated to the respective driver. Due to the interrupt latency produced, the operating speed of the overall computer system may be significantly affected.  
       SUMMARY OF THE INVENTION  
       [0019]     An improved interrupt processing technique is provided that may reduce interrupt latency, increase operating speed, and simplify the interrupt hardware structures.  
         [0020]     In one embodiment, a method of processing interrupts in a computer system is provided that has a memory and at least one processor. The computer system is connected to one or more devices. The method comprises sending an interrupt message to an interrupt controller of the processor in response to an interrupt request from an individual one of the devices. The interrupt message comprises a memory address and interrupt status information. A memory address is specifically allocated to the device that has issued the interrupt request. The interrupt status information indicates an interrupt status of the device. The method further comprises updating by the interrupt controller an interrupt table that is stored in the memory, using the interrupt status information comprised in the interrupt message. The interrupt table holds device specific interrupt statuses. Updating the interrupt table comprises addressing the memory using the memory address comprised in the interrupt message.  
         [0021]     In another embodiment, there is provided a computer system that comprises at least one processor and a memory. The computer system is capable of being connected to one or more devices. The at least one processor comprises an interrupt controller connected to receive an interrupt message comprising a memory address and interrupt status information. The memory address is specifically allocated to an individual one of the devices that has issued an interrupt request. The interrupt status information indicates an interrupt status of the device. The memory stores an interrupt table that holds device specific interrupt statuses. The interrupt controller is adapted to address the memory using the memory address comprised in a received interrupt message and update the interrupt table using the interrupt status information comprised in the received interrupt message.  
         [0022]     According to a further embodiment, a processor has an interrupt controller that is adapted to receive an interrupt message comprising a memory address and interrupt status information. The memory address is specifically allocated to an individual device that has issued an interrupt request. The interrupt status information indicates an interrupt status of the device. The interrupt controller is adapted to address a memory using the memory address comprised in a received interrupt message and update an interrupt table using the interrupt status information comprised in the received interrupt message. The interrupt table is stored in the memory and holds device specific interrupt statuses.  
         [0023]     According to still a further embodiment, a computer readable storage medium stores computer executable instructions that, when executed by a processor of a computer system, cause the computer system to perform interrupt handling by operating on an interrupt table that is stored in a memory of the computer system using interrupt status information comprised in an interrupt message. The interrupt message further comprises a memory address that is specifically allocated to a device that has issued an interrupt request. The interrupt status information indicates an interrupt status of the device. The interrupt table holds device specific interrupt statuses addressable by the memory address comprised in the interrupt message. 
     
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0024]     The accompanying drawings are incorporated into and form a part of the specification for the purpose of explaining the principles of the invention. The drawings are not to be construed as limiting the invention to only the illustrated and described examples of how the invention can be made and used. Further features and advantages will become apparent from the following and more particular description of the invention, as illustrated in the accompanying drawings, wherein:  
         [0025]      FIG. 1  is a block diagram illustrating the components of a conventional computer system;  
         [0026]      FIG. 2  illustrates APIC components at system level;  
         [0027]      FIG. 3  illustrates an example system configuration to show the mechanism typically employed in chipsets to flush the posted write-buffers;  
         [0028]      FIG. 4  illustrates another conventional system configuration;  
         [0029]      FIG. 5  is a diagram illustrating fields in an interrupt message according to an embodiment;  
         [0030]      FIG. 6  illustrates a message based interrupt table according to an embodiment;  
         [0031]      FIG. 7  is a system level diagram illustrating the components that may be used to apply the interrupt processing technique of the embodiments; and  
         [0032]      FIG. 8  is a flow chart illustrating an interrupt processing process according to an embodiment. 
     
    
     DETAILED DESCRIPTION OF THE INVENTION  
       [0033]     The illustrative embodiments of the present invention will be described with reference to the figure drawings wherein like elements and structures are indicated by like reference numbers.  
         [0034]     As will be apparent from the more detailed description below, the embodiments provide a message based interrupt table technique that allows for the complete interrupt status to be transmitted so that merging of interrupt information at the processor interrupt controller is prevented. That is, message based interrupts are used to signal events to the processor, and individual interrupt message addresses are used for each device so that the interrupt message address can be used as index of a system memory based interrupt table.  
         [0035]     Referring to  FIG. 5 , an interrupt message is shown that may be used in the embodiments. As apparent from the figure, each interrupt message comprises a data field  500  that stores a device specific memory address, and a data field  510  that holds an interrupt status vector. It is to be noted that there may be other data fields for other purposes in the message. It is further to be noted that the device specific memory address and/or the interrupt status vector may be located in fields other than data fields, e.g., in a message header, trailer or any other message control field.  
         [0036]     Referring now to  FIG. 7 , the interrupt message of  FIG. 5  is sent from one of the peripheral devices  770 - 790  to the local interrupt controller  710  of the processor  700 . This may be done via a southbridge device and/or an I/O interrupt controller  760  which may be located at the southbridge device. In another embodiment, the interrupt message of  FIG. 5  is generated by the I/O interrupt controller  760  in response to an interrupt request from an individual one of the devices  770 - 790 .  
         [0037]     As will be described in more detail below, the device specific memory address  500  included in the interrupt message shown in  FIG. 5  may be used to address the system memory  720  to read information from the interrupt table.  
         [0038]     An embodiment of the interrupt table  600 ,  730  is shown in  FIG. 6 . As apparent therefrom, the current interrupt status for each device is stored in memory fields  620 ,  640 ,  660  that may be addressed by addresses  610 ,  630 ,  650  that are taken from the respective message field  500 . In the embodiment, each table entry represents the actual interrupt status of the respective device. The table entries  620 ,  640 ,  660  are updated by the local interrupt controller  710  of the processor  700 , which merges the interrupt status vector  510  included in an arriving interrupt message with the current interrupt table entry for that device.  
         [0039]     That is, the embodiments use a hardware process in the local interrupt controller  710  of the processor  700  to investigate an incoming interrupt message, access and read the interrupt table  600 ,  730 , and update the interrupt table by merging the received interrupt status vector  510  with the currently stored interrupt table entry  620 ,  640 ,  660 .  
         [0040]     Once the interrupt table  600 ,  730  is updated, a first-level interrupt handler  740  that may be part of the operating system is triggered. In an embodiment, each arriving interrupt message triggers an interrupt handler  740 . Triggering the interrupt handler  740  may be the result of sending a hardware interrupt to the processor core.  
         [0041]     The interrupt handler  740  then steps from interrupt table entry to interrupt table entry and communicates any new interrupt status to the respective device specific (second-level) interrupt handler, i.e., to the respective device driver  750 . That is, since the interrupt table  600 ,  730  is built from a plurality of individually addressable table fields  620 ,  640 ,  660  each pertaining to different devices  770 - 790  where each table field is addressed by means of the memory address  500  comprised in the interrupt message and each table field  510  holds a respective device specific interrupt status, the interrupt handler  740  identifies device specific interrupt statuses not being settled by sequentially accessing each individually addressable table field. For each unsettled device specific interrupt status, the interrupt handler  740  identifies the corresponding device  770 - 790  as well as the corresponding device driver interrupt handling routine  750 . This device driver interrupt handling routine  750  is the called by the interrupt handler  740  so that the device driver interrupt handling routine  750  can now settle the respective identified device specific interrupt status.  
         [0042]     The interrupt table  600 ,  730  may now be updated to reflect that one or more previously unsettled device specific interrupt statuses have been settled. This my be done by the local interrupt controller  710  of the processor  700 . In other embodiments, it is the first-level interrupt handler  740  which updates the interrupt table  600 ,  730 . In yet another embodiment, there is even no need to update the interrupt table  600 ,  730  since in these embodiments, settlement of device specific interrupt statuses triggers another interrupt message to be sent to the local interrupt controller  710  of the processor  700  so that there is an inherent mechanism that keeps the interrupt table  600 ,  730  up-to-date all the time.  
         [0043]     That is, since the interrupt table  600 ,  730  is updated in response to an interrupt message that included the interrupt status vector  510  and a device specific memory address  500 , the interrupt handler  740  has all information needed to identify the correct device driver  750  without requiring excessive communication to the devices  770 - 790  and/or the I/O interrupt controller  760  for reading device registers. It is further to be noted that the embodiments do not require the interrupt handler  740  to contact more than one device driver  750  since the interrupt handler  740  already has complete knowledge of the current interrupt status and the respective device. It is also to be noted that in the embodiments, the device-specific interrupt handler has not to inquire the associated device about the interrupt status as the status has been transmitted by means of the interrupt message and has been stored in the interrupt table.  
         [0044]     Turning now to  FIG. 8 , an interrupt processing process according to an embodiment is depicted. In step  800 , an interrupt message is sent to the local interrupt controller  710  of the processor  700 . The local interrupt controller  710  then updates the interrupt table  600 ,  730  in step  810 , and generates a hardware interrupt for submission to the processor core (step  820 ), thereby triggering sending a call request to the first-level interrupt handler  740 . This calls the software interrupt handler  740  of the operating system which reads the interrupt table  600 ,  730  (step  830 ). The interrupt handler  740  then calls the responsible device driver  750  in step  840 , and the device driver may then act in step  850  in accordance with the initially sent interrupt message.  
         [0045]     Although not shown in  FIG. 8  it is to be noted that the process depicted in the figure may be performed iteratively. That is, once a first interrupt message is sent to the interrupt controller  710  of the processor  700  in response to an interrupt request from one of the devices  770 - 790 , a second interrupt message may be sent to the interrupt controller  710  of the processor  700  in response to another interrupt request from another one of the devices  770 - 790 . The interrupt controller  710  then separately and successively updates the interrupt table  600 ,  730  and calls the first-level interrupt handler  740  in response to each individual interrupt message. In one embodiment, the same first-level interrupt handler  740  is called twice while in another embodiment, multiple instances of the same first-level interrupt handler  740  are called. In yet another embodiment, the first called interrupt handler  740  is still active when the interrupt controller  710  of the processor  700  generates the second call, and the first called interrupt handler  740  then also assumes the responsability to deal with this second call.  
         [0046]     In another embodiment, the interrupt processing process may be as follows. The first level interrupt handler  740  only determines the number of the current interrupt. Based on that number, it calls the device driver interrupt handler of the first device  770 - 790  that shares the interrupt associated with that interrupt number. The handler then checks whether its associated device has generated the interrupt. Thereafter, it hands over to the device driver interrupt handler of the next device  770 - 790  that shares the interrupt associated with that interrupt number. This handler then also checks its associated device. That procedure ends when the device driver interrupt handlers of all devices  770 - 790  that share the interrupt have checked their devices. After that, the interrupt handlers return activity to the operating system which passes activity to the applications/device drivers.  
         [0047]     That is, this embodiment makes a distinction between the device driver interrupt handlers and the applications/device drivers. Moreover, the device driver interrupt handlers are sequentially called such that the first level interrupt handler  740  calls the first device driver interrupt handler, the first device driver interrupt handler calls the second first device driver interrupt handler, the second first device driver interrupt handler calls the third first device driver interrupt handler, and so on. As described above, the calling of (or handing over of an interrupt to) a device driver interrupt handler may take only those handlers into account which share the interrupt associated with that interrupt number.  
         [0048]     In the various embodiments, the interrupt message can be sent by the device  770 - 790  itself as well as by a southbridge based interrupt controller (such as the I/O interrupt controller  760 ) to which the device is connected. Further, the interrupt message can be sent via a dedicated interrupt message bus or via a message-based host bus (such as Hypertransport™ or PCI Express compliant buses).  
         [0049]     It is noted that in the embodiments, edge triggered as well as level triggered interrupts may be used.  
         [0050]     While in the above description of the various embodiments, the interrupt handler  740  is described to be part of the operating system it is to be noted that the interrupt handler  740  may be realized as separate piece of software in other embodiments. The interrupt handler  740  may even use specific dedicated hardware components in further embodiments.  
         [0051]     As apparent from the foregoing description of the embodiments, a technique is provided that may allow for doing all of the interrupt communication from the peripheral devices in one interrupt message so that all interrupt status information for each device is available at any time without further read requests to the devices. This significantly reduces the interrupt latencies, thereby increasing the overall operation speed, and simplifies the interrupt hardware structures.  
         [0052]     While the invention has been described with respect to the physical embodiments constructed in accordance therewith, it will be apparent to those skilled in the art that various modifications, variations and improvements of the present invention may be made in the light of the above teachings and within the purview of the appended claims without departing from the spirit and intended scope of the invention. In addition, those areas in which it is believed that those of ordinary skill in the art are familiar, have not been described herein in order to not unnecessarily obscure the invention described herein. Accordingly, it is to be understood that the invention is not to be limited by the specific illustrative embodiments, but only by the scope of the appended claims.