Patent Abstract:
A software program is used in conjunction with a standard general purpose multi-processor computer system as a means of implementing an I 2 O-compliant input-output processor (“IOP”) without requiring a special hardware IOP processor embedded on a PCI device card and connected to a computer system PCI bus. At least one of the multi-processor is targeted for operating a special software operating system module. The special software operating system module is capable of emulating the I 2 O-compliant input-output operating system program. This enables the targeted CPU to act as a virtual IOP. A driver software module is inserted into the operating system during computer system initialization which causes the software operating system to operate as if it is communicating with a physical IOP installed on a PCI bus, but instead the driver software module is redirecting the message to one of the virtual IOPs, thus making operation of the computer system indistinguishable from messages that would have been processed by a hardware implemented IOP in a computer system. Legacy computers may also implement I 2 O functionality without needing to be PCI bus configured, nor requiring special hardware IOP.

Full Description:
CROSS REFERENCE TO RELATED PATENT APPLICATION 
     This patent application is related to commonly owned U.S. patent application Ser. No. 09/153,211; filed Sep. 14, 1998 still pending; entitled “Method and System for Implementing Intelligent Distributed Input-Output Processing as a Software Process in a Host Operating System Environment” by Thomas J. Bonola, and is hereby incorporated by reference for all purposes. 
    
    
     BACKGROUND OF THE INVENTION 
     1. Field of the Invention 
     The present invention relates to a computer system using intelligent input-output (I 2 O), and more particularly, to a multi-processor computer system using at least one of its processors for processing I 2 O transactions. 
     2. Description of the Related Technology 
     Use of computers, especially personal computers, in business and at home is becoming more and more pervasive because the computer has become an integral tool of most information workers who work in the fields of accounting, law, engineering, insurance, services, sales and the like. Rapid technological improvements in the field of computers have opened up many new applications heretofore unavailable or too expensive for the use of older technology mainframe computers. These personal computers may be used as stand-alone workstations (high end individual personal computers) or linked together in a network by a “network server” which is also a personal computer which may have a few additional features specific to its purpose in the network. The network server may be used to store massive amounts of data, and may facilitate interaction of the individual workstations connected to the network for electronic mail (“E-mail”), document databases, video teleconferencing, whiteboarding, integrated enterprise calendar, virtual engineering design and the like. Multiple network servers may also be interconnected by local area networks (“LAN”) and wide area networks (“WANs”). 
     A significant part of the ever-increasing popularity of the personal computer, besides its low cost relative to just a few years ago, is its ability to run sophisticated programs and perform many useful and new tasks. Personal computers today may be easily upgraded with new peripheral devices for added flexibility and enhanced performance. A major advance in the performance of personal computers (both workstation and network servers) has been the implementation of sophisticated peripheral devices such as video graphics adapters, local area network interfaces, SCSI bus adapters, full-motion video, redundant error checking and correcting disk arrays, and the like. These sophisticated peripheral devices are capable of data transfer rates approaching the native speed of the computer system microprocessor central processing unit (“CPU”). The peripheral devices&#39; data transfer speeds are achieved by connecting the peripheral devices to the microprocessor(s) and associated system random access memory through high speed information (data and address) buses. 
     The computers system has a plurality of information buses such as a host bus, a memory bus, at least one high speed local peripheral expansion bus, and other peripheral buses such as the Small Computer System Interface (“SCSI”), Extension to Industry Standard Architecture (“EISA”), Industry Standard Architecture (“ISA”), and Peripheral Component Interconnect (“PCI”). The microprocessor(s) of the computer system communicates with main memory and with the peripherals that make up the computer system over these various buses. The microprocessor(s) communicates to the main memory over a host bus to memory bus bridge. The peripherals, depending on their data transfer speed requirements, are connected to the various buses which are connected to the microprocessor host bus through bus bridges that detect required actions, arbitrate, and translate both data and addresses between the various buses. 
     A widely used peripheral expansion bus that may be used in IBM-compatible PCs, Apple computers and RISC workstations is a high speed expansion bus standard called the “Peripheral Component Interconnect” or “PCI.” The PCI bus standard is microprocessor-independent and has been embraced by a significant number of peripheral hardware manufacturers and software programmers. A more complete definition of the PCI local bus may be found in the PCI Local Bus Specification, revision 2.1; PCI/PCI Bridge Specification, revision 1.0; PCI System Design Guide, revision 1.0; and PCI BIOS Specification, revision 2.1, the disclosures of which are hereby incorporated by reference. These PCI specifications are available from the PCI Special Interest Group, P.O. Box 14070, Portland, Oreg. 97214. 
     Computer system peripheral hardware devices, i.e., hard disks, CD-ROM readers, network interface cards, video graphics controllers, modems and the like, may be supplied by various hardware vendors. These hardware vendors must supply software drivers for their respective peripheral devices used in each computer system even though the peripheral device may plug into a standard PCI bus connector. The number of software drivers required for a peripheral device multiplies for each different computer and operating system. In addition, both the computer vendor, operating system vendor and software driver vendor must test and certify the many different combinations of peripheral devices and the respective software drivers used with the various computer and operating systems. Whenever a peripheral device or driver is changed or an operating system upgrade is made, retesting and recertification may be necessary. 
     The demand for peripheral device driver portability between operating systems and host computer systems, combined with increasing requirements for intelligent, distributed input-output (“I/O”) processing has led to the development of an “Intelligent Input/Output” (“I 2 O”) specification. The basic objective of the I 2 O specification is to provide an I/O device driver architecture that is independent of both the specific peripheral device being controlled and the host operating system. This is achieved by logically separating the portion of the driver that is responsible for managing the peripheral device from the specific implementation details for the operating system that it serves. By doing so, the part of the driver that manages the peripheral device becomes portable across different computer and operating systems. The I 2 O specification also generalizes the nature of communication between the host computer system and peripheral hardware, thus providing processor and bus technology independence. 
     The I 2 O specification, entitled “Intelligent I/O (I 2 O) Architecture Specification,” Draft Revision 1.5, dated March 1997, is available from the I 2 O Special Interest Group, 404 Balboa Street, San Francisco, Calif. 94118; the disclosure of this I 2 O specification is hereby incorporated by reference. 
     FIG. 1 illustrates a schematic block diagram of a multi-processor computer system. The computer system is generally indicated by the numeral  100  and comprises central processing units (“CPUs”)  102 , core logic  104 , system random access memory (“RAM”)  106 , a video graphics controller  110 , a local frame buffer  108 , a video display  112 , a PCI/SCSI bus adapter  114 , a PCI/EISA/ISA bridge  116 , a PCI/IDE controller  118 , and PCI/PCI bus bridges  124   a,    124   b.  The local frame buffer  108  connects to a video graphics controller  110  which interfaces and drives a video display  112 . Single or multilevel cache memory (not illustrated) may also be included in the computer system  100  according to the current art of microprocessor computer systems. 
     The CPUs  102  are connected to the core logic  104  through a CPU host bus  103 . The system RAM  106  is connected to the core logic  104  through a memory bus  105 . The core logic  104  includes a host-to-PCI bridge between the host bus  103 , the memory bus  105  and a first PCI bus  109 . The local frame buffer memory  108 , and PCI/PCI bridges  124   a,    124   b  are connected to the first PCI bus  109 . The PCI/SCSI bus adapter  114  and PCI/EISA/ISA bridge  116  are connected to the PCI/PCI bridge  124   a  through a second PCI bus  117 . The PCI/IDE controller  118  and a network interface card (“NIC”)  122  are connected to the PCI/PCI bridge  124   b  through a third PCI bus  115 . Some of the PCI devices such as the local frame buffer  108 /Video controller  110  and NIC  122  may plug into PCI connectors on the computer system  100  motherboard (not illustrated). PCI connectors  160  and  162  are illustrated connected to the PCI bus  117  and are for plugging PCI device cards into the computer system  100 . Three PCI buses  109 ,  117  and  115  are illustrated in FIG. 1, and may have logical PCI bus numbers of zero, one and two, respectively. 
     Hard disk  130  and tape drive  132  are connected to the PCI/SCSI bus adapter  114  through a SCSI bus  111 . The NIC  122  is connected to a local area network  119 . The PCI/EISA/ISA bridge  116  connects over an EISA/ISA bus  113  to a ROM BIOS  140 , non-volatile random access memory (NVRAM)  142 , modem  120 , and input-output controller  126 . The modem  120  connects to a telephone line  121 . The input-output controller  126  interfaces with a keyboard  146 , real time clock (RTC)  144 , mouse  148 , floppy disk drive (“FDD”)  150 , and serial/parallel ports  152 ,  154 . The EISA/ISA bus  113  is a slower information bus than the PCI bus  109 , but it costs less to interface with the EISA/ISA bus  113 . 
     When the computer system  100  is first turned on, start-up information stored in the ROM BIOS  140  is used to begin operation thereof. Basic setup instructions are stored in the ROM BIOS  140  so that the computer system  100  can load more complex operating system software from a memory storage device such as the disk  130 . Before the operating system software can be loaded, however, certain hardware in the computer system  100  must be configured to properly transfer information from the disk  130  to the CPU  102 . In the computer system  100  illustrated in FIG. 1, the PCI/SCSI bus adapter  114  must be configured to respond to commands from the CPUs  102  over the PCI buses  109  and  117 , and transfer information from the disk  130  to the CPU  102  via buses  117 ,  109  and  103 . The PCI/SCSI bus adapter  114  is a PCI device and remains platform independent. Therefore, separate hardware independent commands are used to setup and control any PCI device in the computer system  100 . These hardware independent commands, however, are located in a PCI BIOS contained in the computer system ROM BIOS  140 . The PCI BIOS is firmware that is hardware specific but meets the general PCI specification. Plug and play, and PCI devices in the computer system are detected and configured when a system configuration program is executed. The results of the plug and play, and PCI device configurations are stored in the NVRAM  142  for later use by the startup programs in the ROM BIOS  140  and PCI BIOS which configure the necessary computer system  100  devices during startup. After startup of the computer system  100 , the operating system software including the I 2 O software, according to the I 2 O Specification incorporated by reference above, is loaded into the RAM  106  for further operation of the computer system  100 . An I/O processor, a hardware device, called an I/O Processor (“IOP”)  202 , is utilized in conjunction with the I 2 O Specification, as more fully described hereinbelow. 
     FIG. 2 illustrates a functional block diagram of the I 2 O specification, which divides the peripheral drivers into two parts: 1) the Operating System Services Module (“OSM”)  212  which interfaces with the host operating system (“OS”)  200 ; and 2) the Device Driver Module (“DDM”)  204  that executes on an IOP  202  and which interfaces with a particular hardware device, media or server ( 206 ) that the driver must manage. All of the modules are capable of communicating with each other across a common communication layer  208 . As defined in the I 2 O Specification, the IOP  202  is a platform (node) consisting of a processor, memory, and I/O devices that are managed independently from other processors within the system for the sole purpose of processing I/O transactions. 
     FIG. 3 illustrates the basic software architecture of an I 2 O compliant system. A DDM can be a hardware driver module (“HDM”)  308 , an Intermediate Service Module (“ISM”)  306 , or both. These two modules interface with other components via a communication system comprised of two parts: 1) message layers  300  and  304  which operate in conjunction with the host operating system  200  and the IOP  202 , respectively, to set up a communications session between parties (OSM-DDM or DDM-DDM); and 2) a transport layer  302  which defines how the two parties will share information. Much like a standard communications protocol, the message layers  300 ,  304  reside on the transport layer  302 . 
     The communications model defined in the I 2 O specification, when combined with an execution environment and configuration interface, provides the DDM  204  with a host-independent interface. The modules are able to communicate without knowledge of the underlying bus architecture or computer system topology. Messages form a meta-language for the modules to communicate in a manner that is independent of the bus topology and host OS interfaces. The communications model for the I 2 O architecture is a message passing system. The I 2 O communication model is analogous to a connection oriented networking protocol, such as TCP/IP, in which the two parties interested in exchanging messages utilize the communication layer  208  to set up a connection and exchange data and control. 
     FIG. 4 illustrates the basic I 2 O communication model. When the OSM  212  is presented with a request from the host OS  200 , it translates the request into an I 2 O request ( 400 ) and invokes the host&#39;s Message Transport layer  402  to deliver the message. The OSM Message Transport layer  402  removes the first free message frame (MFA)  404  from the remote IOP&#39;s ( 202 ) inbound free list  408 , places the request information into the MFA  404  and posts the inbound message  406  in the remote IOP&#39;s ( 202 ) inbound post queue  408 . The remote IOP&#39;s ( 202 ) Message Transport layer  414  removes the message  412  from the inbound post queue  408 , extracts the request information from the inbound MFA  412 , returns the now-free MFA  412  to the Inbound free list  408 , and dispatches the posted request  416  to the appropriate DDM  204  for processing,. 
     Upon completion of the request, the DDM  204  issues a response  420  that notifies the IOP  202  to dispatch the result back to the OSM  212  by sending a message through the I 2 O Message Layer. The remote IOP&#39;s Message Transport Layer  414  removes a free MFA  422  from the outbound free list  426 , places the response data  420  into the MFA  424 , posts the MFA  424  into the outbound post list  426 , and notifies the OSM  212  that a response is waiting. The host Message Transport Layer  402  reads the MFA  430  from the outbound post list  426 , removes the response data  432  from the MFA, returns (writes) the now-free MFA  428  to the outbound free list  426 , and returns the response  432  to the OSM  212 . The OSM  212  behaves just like any other device driver in the host OS  200 . The OSM  212  interfaces to host-specific Application Programming Interfaces (“APIs”), translating them to a neutral message-based format that is then sent to a DDM  204  for processing. 
     Referring now to FIG. 5, operations flow of a standard I 2 O-compliant system is illustrated. The OS  200  of the host CPU(s)  102  issues an I/O request  500 . The OSM  212  accepts the request  500  and translates it (step  502 ) into a message  504  addressed to the target DDM  204  running on the IOP  202 . The OSM  212  invokes the host Message Transport layer  402  to deliver the message. The host Message Transport layer  402  queues the message  510  by copying it (step  508 ) across the PCI buses  109  and  117  into a message frame buffer on the remote IOP  202 . The remote IOP  202  Message Transport  414  posts the message  514  to the event queue (step  512 ) of the DDM  204 . The DDM  204  then processes the request (step  516 ). 
     After processing the message and satisfying the request (step  516 ), the DDM  204  builds a reply  520  (step  518 ), addresses the reply  520  to the initiator of the request, and invokes the remote IOP  202  Message Transport layer  414  to send the reply  524  to the initiator. The remote IOP Message Transport layer  414  queues the reply  524  by copying it (step  522 ), across the PCI buses  109 ,  117 , into a message frame buffer residing at the host&#39;s Message Transport layer  402 . The remote IOP  202  then alerts the host&#39;s Message Transport layer  402  that a message is ready for delivery. The host&#39;s Message Transport layer  402  invokes the OSM&#39;s  212  message handler (step  526 ) which retrieves the OS  200  I/O request  532  from the message in order to complete the OS I/O request (step  530 ). Finally, the request itself is returned to the OS  200  (step  528 ). 
     Referring now to FIG. 6, a schematic block diagram of a standard I 2 O architecture is illustrated. The DDMs  204   a  and  204   b  are the lowest level modules in the I 2 O environment, encapsulating the software which is specific to a particular controller and the associated peripheral devices (LAN  206   a  and disk  206   b ), in essence, providing an abstract device driver for the I 2 O environment. The DDM translation layer is unique to each individual peripheral device and vendor, and supports a range of operating types, including synchronous, asynchronous request, event-driven, and polled. The DDMs  204   a  and  204   b,  which execute on the IOP  202 , are managed by the I 2 O real-time input-output operating system (“iRTOS”)  608 , which provides the necessary support for the operating system processes and bus-independent execution. DDMs in general may therefore be designed in a manner which minimizes changes when moving from one computer system hardware platform to another. 
     In order to support the I 2 O device model, the I 2 O specification defines a hardware architecture which uses a single host processor (which may consist of multiple processors  102   a,    102   b  and  102   c  on a single host bus) and an intelligent I/O subsystem containing one or more physical hardware I/O processors  202 . The I/O subsystem  202  has its own operating system  608 , local memory (ROM and RAM) and local I/O bus(es) (not illustrated). The dedicated I/O processor(s)  202  may be located on a plug-in feature card, generally a PCI device card. Special memory must also be provided for each dedicated I/O processor so that both private and shared memory are available. The private memory is only used by the associated I/O processor  202 , but the shared memory must be available to all of the computer system resources. 
     The shared memory, through appropriate memory address translators, is the vehicle through which different I/O processors and the host processor communicate with one another through the message and transport layers. Messages sent to the IOP  202  are allocated from the inbound free list  406  and placed in the inbound post queue  408  located at an address equal to the PCI card&#39;s base address plus 0x40 (hexadecimal) ( 600 ). Messages from the IOP  202  to the OSM  212  are allocated from the outbound free list  604  and placed in an outbound post queue  606  located at an address equal to the PCI card&#39;s base address plus 0x44 ( 602 ). 
     According to the I 2 O Specification, these I/O processors (IOP  202 ) require a separate computer subsystem complete with its own dedicated microprocessor, memory, internal information bus(es) and printed circuit board real estate. This is neither cost effective nor practical for manufacturing general use computer systems having an optimal performance to cost ratio. In addition, legacy computer systems having only ISA and EISA buses could not utilize newer OS and peripheral devices running under the I 2 O specification because of their lack of a PCI bus(es). 
     What is needed is a method and system for implementing intelligent distributed I/O processing, such as I 2 O, in a multi-processor computer system without requiring special hardware for a dedicated I/O processor subsystem. 
     SUMMARY OF THE INVENTION 
     The present invention provides a software program used in conjunction with a standard general purpose multi-processor computer system as a means of implementing an I 2 O-compliant IOP without requiring a special hardware IOP processor embedded on a PCI device card. The present invention utilizes software modules inserted into the operating system during computer system initialization, thereby causing the OSM of the OS to operate as if it is communicating with a physical IOP installed on a PCI bus, but instead is utilizing at least one of the multi-processors as a virtual input-output processor (hereinafter “V-IOP”) of the computer system. These software modules intercept messages to and from the DDMs and assign them to the V-IOP, thus making operation of the computer system with the present invention indistinguishable from messages that would have been processed by a hardware configured IOP in the computer system. 
     Therefore, the present invention solves the technical problem of implementing I 2 O functionality in a computer system without requiring the added cost and complexity of a special hardware I 2 O compliant IOP device. The present invention also solves the technical problem of implementing I 2 O functionality on systems that could not otherwise utilize the I 2 O standard, such as non-PCI bus configured legacy computers. 
     Thus, the present invention provides a method and system for implementing intelligent distributed input-output processing in a multi-processor computer system by allocating one or more of the multi-processors of the host computer system as an I 2 O-compliant IOP running the DDMs and operating under the I 2 O communications protocols. The DDMs may use system memory which utilizes cache coherency hardware provided by the host multi-processor computer system. The present invention may store I 2 O message frames in the host main memory without traversing over the I/O bus(es) unless needed by a target device. In addition, the present invention enables I 2 O functionality on currently installed computers without requiring hardware upgrades to a dedicated hardware I/O processor subsystem, thus enabling non-PCI bus configured computers to take advantage of new OS and peripheral hardware utilizing the I 2 O specification. 
     Other and further features and advantages will be apparent from the following description of presently preferred embodiments of the invention, given for the purpose of disclosure and taken in conjunction with the accompanying drawings. 
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS 
     FIG. 1 is a schematic block diagram of a typical computer system; 
     FIG. 2 is a schematic block diagram of the typical I 2 O split driver model; 
     FIG. 3 is a schematic block diagram of the I 2 O software architecture; 
     FIG. 4 is a schematic block diagram of the I 2 O communication model; 
     FIG. 5 is a schematic block diagram of the standard I 2 O I/O operations flow. 
     FIG. 6 is a schematic block diagram of the I 2 O standard architecture; 
     FIG. 7 is a schematic block diagram of the I 2 O-compliant software architecture according to the present invention; 
     FIG. 8 is a flow diagram showing the process of initializing and starting the software of the present invention; 
     FIG. 9 is a flow diagram showing the initialization process for the V-IOP Driver; 
     FIG. 10 is a flow diagram showing the launching of the V-IOP; 
     FIG. 11 is a flow diagram showing the startup of the V-IOP Driver; 
     FIG. 12 is a flow diagram showing the Target CPU Initialization; 
     FIG. 13 is a flow diagram showing the Target CPU Startup; 
     FIG. 14 is a flow diagram showing the method of handling interrupt requests; 
     FIG. 15 is a flow diagram showing the creation of the List of Active Event Queues; and 
     FIG. 16 is a flow diagram showing the allocation of resource required to implement the V-IOP iRTOS. 
    
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 
     The present invention is a system and method for implementing an I 2 O-controlled IOP system using general computer system hardware controlled by software. Although the following describes the implementation of the present invention on an I 2 O-compliant system, it will be understood by those of ordinary skill in the art that the present invention can work with other input-output schemes besides the I 2 O scheme. The present invention comprises: (1) a system driver (V-IOP driver) program capable of intercepting and redirecting input-output related messages and capable of handling interrupts; (2) a real-time operating system program (V-IOP OS) that provides communication between I 2 O-controlled devices and the operating system module (OSM) that contains the V-IOP driver; and (3) an installation is program that installs the V-IOP driver and the V-IOP OS image onto the computer system and designates the number of CPUs that are to be devoted to input-output processing. 
     A CPU that runs under the V-IOP OS is called a V-IOP (“virtual input-output processor”). More than one CPU can be operated under the V-IOP OS so that multiple I/O commands can be processed in parallel. The V-IOP OS is not intended to be run under the bootstrap processor (i.e., the CPU that is running the host OS). Consequently, the number of V-IOPs possible on any computer system is the number of CPUs less one. 
     When an interrupt signal emanates from, or is sent to, the host operating system (specifically, the OSM), the V-IOP driver is invoked. The V-IOP driver interprets the intercepted signals and, if the signal is associated with an I 2 O-controlled device, forwards the signal to one of the V-IOPs. The V-IOP OS, which contains a special wrapper for the I 2 O-compliant real-time input-output operating system executable, then processes the forwarded signal. This arrangement allows multiple input-output signals to be processed in parallel and does not require a dedicated processor on a separate board. 
     Installation of the Software onto the Computer System 
     The software of the present invention is installed conventionally onto the computer system. In the preferred embodiment of the present invention, there are two electronic files: a V-IOP driver that is loaded by the host operating system, and a V-IOP executable image that runs on one or more of the multiprocessors. An installation program is provided to facilitate the setup of the two electronic files on the computer system. The installation program prompts the computer system operator to identify the folder(s) where the two files (the V-IOP driver and the V-IOP OS) are to be stored and requests the operator to designate the number of CPUs that are to be devoted to input-output processing. The installation program then copies the two files to the appropriate directory and, for example, modifies the system registry or otherwise stores information to reflect the number of CPUs that are to be devoted to the software of the present invention. 
     It should be understood that the number of CPUs originally designated during the installation phase may not be the number actually designated upon system startup. Problems could arise. For example, one of the multiprocessors originally allocated to the present invention may have been removed. For this reason, upon booting of the computer system, the V-IOP driver of the present invention counts the number of CPUs present on the computer system and allocates either the number originally requested, or as many CPU&#39;s as are available less one (that is the bootstrap processor (BSP)). 
     Configuration of the Apparatus 
     An overview of the software architecture of the present invention is illustrated in FIG.  7 . As in a standard I 2 O compliant system, the input-output driver  211  is an operating system module (OSM) that executes under the control of the host OS  200 . Unlike the prior art implementation of I 2 O, which requires a separate, special hardware IOP board  202  (FIGS. 1 and 6) connected to the PCI bus  117  (FIG. 1) in order to execute a standard iRTOS (not shown) and associated DDMs ( 204   a  and  204   b ), the present invention shown in FIG. 7 allocates one or more CPUs  102   d  to the task of acting as a virtual IOP (“V-IOP”)  702 . Executing on the V-IOP  702  is the V-IOP OS  704  in the form of a special wrapper  704  that contains an iRTOS  710  with I 2 O functionality as well as the associated DDMs ( 204   a  and  204   b ). The wrapper  704  presents an I 2 O iRTOS personality to the DDM&#39;s, i.e., the DDM&#39;s within the wrapper  704  cannot distinguish the iRTOS  710  in the wrapper  704  from a standard I 2 O iRTOS running on a separate IOP running on the host OS. The wrapper  704  is described more fully in commonly owned U.S. patent application Ser. No. 09/152,728; filed Sep. 23, 1998 still pending; entitled “Method and Apparatus for Providing Symmetric Multiprocessing in an I 2 O Real-Time Operating System” by Thomas J. Bonola, and is hereby incorporated by reference. 
     The present invention also differs from the prior art in that it allocates memory for the V-IOP  702  within the computer system RAM  106  (FIG. 7) rather than from dedicated memory on a physical IOP board  202 . Yet another way in which the present invention differs from the prior art is that, although it can communicate with devices connected to a PCI bus as in the prior art, it can also communicate with hardware I/O devices  206   a  and  206   b  connected to non-PCI buses, such as the EISA/ISA bus  113  (FIG. 1) commonly found in legacy computer systems. Finally, the present invention differs from the prior art in that all messages between the input-output operating system module (“OSM”)  212  (which contains the standard IOP driver  211 ), and the iRTOS  710  within the wrapper  704  that is executing on the V-IOP  702 , are sent over the host bus  103  via the I 2 O message handlers  706  in the V-IOP driver  700 . 
     The V-IOP driver  700  also contains a V-IOP startup routine  708  that is used to allocate a CPU, load the V-IOP OS onto that CPU, perform a fix up procedure to link the V-IOP OS to the V-IOP driver, and then launch (i.e. restart) that CPU so that it will operate under the V-IOP OS to form a V-IOP. 
     Initalization and Starting of the Software 
     FIG. 8 is a flow diagram showing the overall process of initializing and starting the software of the present invention. Specific elements of the initialization process are explained more fully elsewhere in the description and other figures. For example, step  900  is illustrated in FIG. 9, step  1000  in FIG. 10, and so on with corresponding textual explanation found in subsequent sub-sections. 
     The initialization and starting process is entered in step  800 . First, in step  802 , the number of CPU&#39;s present in the computer system is determined along with the context of the computer system. Part of the context determination process includes determining which operating system has overall command of the computer system. For example, a typical context for the present invention would have a PENTIUM PRO multiprocessor (made by Intel Corp.) utilizing A WINDOWS NT (manufactured by Microsoft Corp.) as an operating system. Once the context has been determined, the V-IOP driver will be initialized in step  804 . The manner in which the V-IOP driver is initialized depends upon the context detected in step  802 . Next, in step  900 , the V-IOP driver will be initialized. Once the V-IOP driver has been initialized, the first V-IOP CPU is launched in step  1000 . A check is made in step  806  to determine whether any more V-IOPs were requested (per the installation procedure). If so, step  1000  is repeated until all of the requested V-IOP CPUs have been launched. Once all of the V-IOP CPUs have been launched, the V-IOP driver is started, step  1100 . The initialization status is then returned to the host OS in step  808  and the initialization and startup process ends in step  810  and control is returned to the calling module. 
     Initialization of the V-IOP Driver 
     FIG. 9 illustrates the initialization process for the V-IOP driver. As mentioned earlier, one of the features of the present invention that is not duplicated in the prior art is the utilization of shared memory for IOP purposes instead of requiring extra RAM on a separate IOP card. One consequence of this feature is the need to allocate a region of shared memory ( 106  of FIG. 1) for use by the V-IOPs and the V-IOP driver. The process is entered in step  902  and, in step  904 , shared memory is allocated for use by all V-IOPs and the V-IOP driver. Finally, the hardware abstraction layer (HAL) is scanned for processor control registers (PCRs), step  906 . This process is ended in step  908  and control is returned to the calling module for subsequent processing (e.g., step  1000  of FIG.  8 ). 
     Launching of the V-IOP 
     FIG. 10 is a flow diagram showing the launching of the V-IOP (step  1000  of FIG.  8 ). Portions of this process are illustrated more fully in FIGS. 12 and 13, as well as textually later in this description. 
     After the process is entered (step  1002 ), the target CPU is initialized, step  1200 . A “target” CPU is one that has been designated for IOP processing. As mentioned earlier, the specific CPU that is targeted is not determined until startup time, to accommodate possible problems in the computer system that may not have been present when the V-IOP software was installed onto the computer system. Once the target CPU has been initialized, the target CPU is started in step  1300  to form a V-IOP. This initialization/startup procedure is performed for each of the CPUs that has been designated as an IOP. The process terminates and control is returned for subsequent processing, e.g. step  806  of FIG.  8 . 
     Startup of the V-IOP Driver 
     FIG. 11 is a flow diagram showing the details of the startup process of the V-IOP driver (step  1100  of FIG.  8 ). The process is entered in step  1102 . First, in step  1104 , the entry points in the Interrupt Dispatch Table (IDT) are saved. Next, in step  1106 , the saved entry points are patched into the dispatch routine&#39;s code space. In step  1108 , the Inter-Processor Interrupt (IPI) and End of Interrupt (EOI) codes for the specific platform are verified. Once verified, the IPI and EOI codes are used to connect the various interrupt event handlers in step  1110 . In step  1112 , the virtual adapter memory region of the shared memory (i.e., the system memory  106  of FIG. 7) is mapped and the first page of this memory region is marked “Not-Present.” By marking this memory region Not-Present, calls using this memory space, such as I/O-related calls to/from I/O devices will cause a page fault. Once the page fault occurs, it is intercepted by the V-IOP driver, the command interpreted, and, if necessary redirects the command to one of the V-IOPs. Note, only the first page is marked “Not-Present.” In step  1112 , caching is enabled for the remaining pages of the virtual adapter memory region. 
     Next, in step  1114 , it is determined which PCI bus and PCI slot will be used to report back to the OSM. Subsequently, in step  1116 , for each supported adapter, the PCI space in shared memory is scanned for information. This PCI information is placed into each adapter&#39;s PCI configuration information. In step  1118 , hooks are made on the kernel and the HAL routines needed to intercept the I/O-related calls. Finally, the V-IOP driver is “kicked-off” with a “NOP” (no operation) messaged which, in this context, is essentially a “Go” message. The V-IOP driver startup routine ends in step  1122  and control is returned (to step  808  of FIG. 8) for subsequent processing. 
     Initialization of the Target CPU 
     FIG. 12 is a flow diagram showing the Target CPU Initialization. The process is entered in step  1202 . First, in step  1204 , shared system memory is allocated for the iRTOS Executive Function Array and the array itself is then built. In step  206 , a check is made to determine whether one of the V-IOP CPU&#39;s has already been initialized. If so, execution skips to step  1218 . If not, then the next four steps are executed. In step  1208 , V-IOP information is extracted from the shared memory. Next, in step  1210 , The heap is extracted from the shared memory and initialized. Subsequently, with all of the critical information in place, the V-IOP PCI configuration space information is filled in during step  1214 . Once this information is filled in, the specific physical address of the shared memory is passed back to the PCI configuration space in step  1216 . 
     Step  1218  is executed only after at least one V-IOP CPU has been installed. During step  1218 , memory is allocated for the virtual inbound and outbound FIFO&#39;s in the local heap. In the preferred embodiment of the present invention, the inbound and outbound FIFOs are both concurrent and non-blocking. However, other FIFO schemes, such as preemption-safe locking, can be utilized. Once the memory is allocated, then the virtual inbound and outbound FIFO&#39;s are initialized, step  1220 . With the FIFO&#39;s initialized, the inbound FIFO is filled with the available MFA&#39;s (Message Frames) for use by the OSM in step  1222 . Next, in step  1500 , the list of active event queues is created. Step  1500  is described in more detail below and in FIG.  15 . Finally, in step  1600 , the resources that are required to implement the iRTOS in the V-IOP are allocated. Step  1600  is described in more detail below and in FIG.  16 . 
     Startup of the Target CPU 
     FIG. 13 is a flow diagram showing the V-IOP (Target CPU) Startup. The process is entered in step  1302 . First, in step  1304 , a check is made to determine whether a V-IOP has been initialized. If so, then execution is redirected to step  1400 . Otherwise, execution continues on to step  1306 . In step  1306 , a check is made to determine if a “Go” message was received from the V-IOP driver (indicating that the V-IOP has been initialized). If no “Go” message has been received, then step  1306  is re-executed—essentially placing the process in a wait mode until a “Go” signal is received from the V-IOP driver. 
     Once the “Go” signal has been received, execution resumes at step  1308 , where the virtual adapter table for each available adapter is initialized. Next, in step  1310 , memory for a local message frame is allocated and the Device Attach message is constructed. Subsequently, a message is posted to the Executive (i.e., the inbound FIFO). Afterwards, a signal is dispatched to indicate that the initialization of the V-IOP is complete. Once the V-IOP has been initialized, is now ready to handle interrupt requests per step  1400 . Step  1400  is described in more detail below and in FIG.  14 . 
     Handling Interrupt Requests 
     FIG. 14 is a flow diagram showing the method of handling interrupt requests. The process is entered in step  1402  where a check is made to determine if the signal was an IRQ (interrupt request). If so, an assert process is executed in step  1404 . The assert process of step  1404  is required because the iRTOS in the V-IOP OS runs as a software emulation that is not directly connected to a specific hardware device (that would otherwise issue the IRQ). In the assert process, the V-IOP OS posts a message to the outbound post list FIFO that asserts the IRQ to the proper hardware device. 
     If the signal is not an IRQ, or if the assert process has been performed, then step  1406  executed where the free event object is grabbed. Next, in step  1408 , a check is made to determine whether the grabbed object is a free event object. If not, execution is routed to step  1418 . Otherwise, execution proceeds to step  1410  where the inbound posted MFA is removed. A check is made immediately to determine if an MFA was removed in step  1412 . If not, then the free event is placed onto the free event list in step  1414  and execution is then routed to step  1418 . If, however, an MFA was removed in step  1412 , then the event object is posted to the target event queue in step  1416 . In step  1418 , the next active event queue is grabbed. A check is made in step  1420  to determine if the grabbing step of  1418  was successful. If not, execution is rerouted all the way back to the beginning to step  1402 . Otherwise, if successful, then execution is allowed to proceed to step  1422 . 
     In step  1422 , the highest priority event is grabbed. The success or failure of step  1422  is determined in step  1424 . If failure was detected in step  1422 , then the event queue is placed onto the active event queue and execution is rerouted to the beginning at step  1402  to await the next signal. Otherwise (i.e., success was detected in step  1422 ), then execution proceeds to step  1428  where the event is dispatched. Once the event is dispatched, the free event object is placed onto the free event list, step  1430 . Finally, in step  1432 , the event queue is placed onto the active event queue list and the process ends in step  1434 . 
     Creating the Active Event Queues 
     FIG. 15 is a flow diagram showing the creation of the List of Active Event Queues. This process starts in step  1502 . First, in step  1504 , the active event queue list is created. Next, in step  1506 , memory in the shared memory heap is allocated. Once allocated, the active event queue is initialized in step  1508 . Next, in step  1510 , the free event list is created and, in step  1512 , the free events list is filled with the available event objects. Execution is returned to the calling routine in step  1514  (see FIG.  12 ). 
     Allocating the Resources for the V-IOP iRTOS 
     FIG. 16 is a flow diagram showing the allocation of resource required to implement the iRTOS in the V-IOP. This process is started in step  1602 . First, the event queue for the Executive is created in step  1604 . Next, the Executive dispatch table is created in step  1606 . Finally, the Executive device object is created and initialized in step  1608 . Execution is returned to the calling routine in step  1610  (see FIG.  12 ). 
     The present invention, therefore, is well adapted to carry out the objects and attain the ends and advantages mentioned, as well as others inherent therein. While the present invention has been depicted, described, and is defined by reference to particular preferred embodiments of the invention, such references do not imply a limitation on the invention, and no such limitation is to be inferred. The invention is capable of considerable modification, alternation, and equivalents in form and function, as will occur to those ordinarily skilled in the pertinent arts. The depicted and described preferred embodiments of the invention are exemplary only, and are not exhaustive of the scope of the invention. Consequently, the invention is intended to be limited only by the spirit and scope of the appended claims, giving full cognizance to equivalents in all respects.

Technology Classification (CPC): 6