Data processing: structural design – modeling – simulation – and em – Emulation – Of peripheral device
Reexamination Certificate
1998-10-01
2003-05-27
Broda, Samuel (Department: 2123)
Data processing: structural design, modeling, simulation, and em
Emulation
Of peripheral device
C703S027000, C710S260000, C713S100000
Reexamination Certificate
active
06571206
ABSTRACT:
FIELD OF THE INVENTION
The invention relates generally to the field of multi-processor computer systems, and more specifically, to the emulation of input or output data and the communication of and/or commands to or from a processor that is executing an I/O instruction directed to a specified I/O device in a multi-processor computer system environment.
This invention also relates generally to the field of SMI services and multi-Processor computer systems and specifically to the field of servicing Software SMI's.
BACKGROUND OF THE INVENTION
The modern computer architecture typically includes a set of hardware called Legacy Hardware. This Legacy Hardware is hardware that all applications, operating systems and BIOS (Basic Input/Output System firmware used to boot and to test the architecture as well as to provide run-time services) expect to be present in the computer system and expect to behave in the computer system in a prescribed way. To communicate with diverse hardware in a given architecture, a series of Input and Output instructions along with specified addresses and data values have been standardized. When removing or adding new hardware in the computer system, in order to allow all existing applications and operating systems software to make use of the new hardware without modification, the Input/Output instructions between the new hardware and the old system hardware typically require emulation, which is accomplished by dispatching the Input/Output instructions to a software emulation subroutine. This is also referred to as trapping. A specific example of hardware requiring an emulation operation is the Universal Serial Bus (USB) Legacy support system. The USB hardware in this support system adds to the overall computer system the following: A USB host controller, a root hub, a connector, interrupt generating mechanisms, and USB devices including a USB keyboard. For all existing applications and operating systems to take advantage of the USB keyboard, this keyboard at the Input/Output instruction level must be made to look like the original keyboard used with the Legacy Hardware, for example, a PS/2 keyboard. To emulate the PS/2 keyboard, a System Management Interrupt (SMI) is generated by trapping on the PS/2 keyboard controller Input/Output instructions. Within the SMI service routine, specific routines then translate the command/data from the Legacy Hardware format to USB keyboard command/data.
A fundamental problem results from the use of such interrupts in a multi-processor environment. This problem when interrupts are utilized, is to determine which processor in the multi-processor environment caused the instruction trap. The emulation of an IN instruction, for example, can cause significant problems if that command or data is not loaded into the proper register in the processor that initiated and executed the input instruction. Likewise, the emulation of an OUT instruction, although it will not cause corruption of registers in a processor, will cause incorrect data to be provided to the output device if the data is not received from the processor that executed the OUT instruction.
In a typical multi-processor architecture, if no changes are made to the I/O instruction emulation, the Boot Strapped Processor (BSP) will have one of its registers changed when one of the Application Processors in the multi-processor architecture performs an input instruction requiring emulation. This causes two problems: (1) the input instructions data is never received by the application processor that performed the input instruction; and (2) one of the Boot Strapped Processor's registers is inadvertently changed, which could have a disastrous effect.
Likewise, with no changes to the output instruction emulation, the emulation code would only get the output data from the Boot Strapped Processor, even if one of the Application Processors performed the output instruction. This causes two problems: (1) the Application Processor output instruction data will never be received by the output instruction emulation code; (2) one of the Boot Strapped Processor's registers will be used as the output instruction data which could put the emulated device into an undesirable state. The present invention is designed to solve both of these problems.
In general, modern CPU hardware such as the Intel Pentium includes a provision for a System Management Interrupt (SMI) signal. The interrupt is connected to an output pin from the computer system's chipset logic. When certain system hardware events occur, external to the CPU(s) of a system, such as chipset logic's programmable timers timing out, error conditions such as parity errors, low battery indications from external hardware, and particular BUS I/O cycle execution, the chipset logic will generate the software management interrupt (SMI) signal. This interrupt transfers CPU execution to a BIOS SMI interrupt handler for further processing, which is usually implemented by a software module.
In addition to pure hardware events, the SMI feature can also be invoked deliberately by software through the use of a software SMI procedure. In general, a software SMI procedure executes one or more I/O instructions that the chipset logic has been programmed to monitor. Upon detection that the I/O cycle has occurred, the chipset logic will generate the SMI signal to the SMI pin(s) of the CPU(s). The chipset logic in this situation is simply monitoring I/O Bus cycles (treating them as hardware events), and so has no knowledge which CPU actually generated the instruction.
In the case of SMI's generated by external hardware events, the state of the registers of the various CPU(s) of the system are largely irrelevant to the interrupt handling. The hardware event is CPU independent and the BIOS's SMI handler is simply given control to handle the hardware event and then, following the handling, it allows the system to resume it's normal processing. The CPU(s) themselves generally input no information and require no information to be passed back to them.
However, in the case of an SMI generated deliberately by software (S/W SMI), it is generally necessary to pass information into the SMI handler and to also get results back. For example, in the case of a software SMI used to enable a power management function, the results would be control information communicated to one or more registers in the particular CPU to power-up or power lower given pieces of equipment connected to that CPU. As another example, a software SMI may be generated in order to enable a MODEM, and the results to be communicated back to a register in the particular CPU is whether the MODEM was or was not enabled. As a yet further example, a software SMI may be generated in order to check a password, and the result to be communicated back by changing a register in the particular CPU is whether the entered password matches a stored set of accepted passwords.
In the case of a single CPU, results are passed by reading the standard CPU registers by the SMI handler and output is retrieved by changing these registers in the CPU upon resume. However, in the case of multiple CPUs a new problem arises because the individual CPU which generated the Software SMI has never been readily determinable and thus the CPU registers to read as input and to write data are not known.
With no changes to the software SMI functionality, the Boot Strapped Processor (BCP) will have its register used for any input and output changes when one of the Application Processor(s) (AP's) performs a software SMI. This causes two problems: 1) The Input Instruction's data is never received by the AP. 2) The BCP's registers were inadvertently changed which could have a disastrous effect. Support for multiple CPUs has never been performed.
SUMMARY OF THE INVENTION
Briefly, the present invention comprises a multi-processor system, including at least a first and a second processors, each capable of executing an I/O instruction to transfer data or a command between the processor and an I/O d
Casano Anthony Paul
Edrich David Steven
Broda Samuel
Phan T.
Phoenix Technologies Ltd.
LandOfFree
Apparatus and method for emulating an I/O instruction for... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Apparatus and method for emulating an I/O instruction for..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Apparatus and method for emulating an I/O instruction for... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3090557