The invention may be best understood by referring to the following description and accompanying drawings that are used to illustrate embodiments of the invention. In the drawings:
In the following description, numerous specific details are set forth. However, it is understood that embodiments of the invention may be practiced without these specific details. In other instances, well-known circuits, structures and techniques have not been shown in detail in order not to obscure the understanding of this description.
Reference throughout the specification to “one embodiment” or “an embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, the appearance of the phrases “in one embodiment” or “in an embodiment” in various places throughout the specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.
Moreover, inventive aspects lie in less than all features of a single disclosed embodiment. Thus, the claims following the Detailed Description are hereby expressly incorporated into this Detailed Description, with each claim standing on its own as a separate embodiment of this invention.
At operation 210 the front-end portion is implemented in, for example real mode memory (for an INT13 hook) or, for example, the OS kernel address space (for an IDE filter driver).
At operation 215 the back-end portion is implemented in the system management mode (SMM). Implementing the back-end portion of the MPA in the SMM will be discussed more fully below. The SMM is a reduced power consumption state supported by IA32 CPUs. When a CPU enters SMM it saves its current state in a special area of static random access memory (RAM) called system management RAM (SMRAM) which is reserved by the platform firmware upon initialization and hidden from the OS until system reset. Because it has its own memory, the SMM provides an isolated execution environment that operates transparently to the OS.
The system management interrupt (SMI) is an OS-transparent interrupt, it is not stored in the interrupt vector table (IVT). The SMI cannot be triggered by any instruction, but is instead raised by the chipset to cause the CPU to enter SMM mode and the SMI handler to be executed. The SMI is the highest priority interrupt, and therefore cannot be interrupted again.
The SMI handler could instruct the CPU to leave SMM by executing an RSM instruction, which reads the CPU state data from a state save map and restores the CPU state. Because the CPU context at the time the SMI is raised is automatically saved, and restored after leaving SMM, the SMM is transparent to OS.
Thus one embodiment of the invention allows a MPA to be implemented as two distinct portions, a front-end interface and a back-end algorithm. For example, a HDP software may implemented as an HDP algorithm (such as redirecting read/write request) could be implemented in the SMM as the back-end of an HDP suite, while other components (e.g., INT13 hook or IDE filter driver in OS) are implemented as front-end interfaces, which intercept the read/write request and pass them to the back end for further processing.
For one embodiment of the invention, the back-end portion of the MPA is shared among multiple front-end portions. For such an embodiment, the bulk of the MPA, for example the core part of an HDP software (e.g., the HDP algorithm) may be implemented only once in the SMM, thereby saving front-end memory and simplifying the multiple front-end portions. That is, for example, the same algorithm need not be implemented in the INT13 and again in the OS driver. In prior art systems when the OS boots up, for example, Windows98, it won't use the INT13 again, it will use its own disk driver, therefore a prior art HDP software scheme has to provide the driver for Windows98 with the same algorithm that is implemented in the INT13. This redundancy is eliminated in accordance with one embodiment of the invention.
In accordance with one embodiment of the invention, as discussed above, the SMI has only one internal state and cannot be interrupted and all of the internal states are in the SMM (neither the INT13 nor the OS driver has to maintain the internal state. This eliminates the synchronization problem inherent in prior art schemes. That is, in prior art schemes, some applications may use INT13 to access the HD while others use the OS drivers to access the HD. Because the OS is multitasking, the internal state of the INT13 hook and the internal state of the driver become unsynchronized. This lack of synchronization is overcome by embodiments of the invention.
For one embodiment of the invention in which the back-end portion of the MPA contains the bulk of the complicated processing of the MPA, each of multiple front-end portions need not communicate with each other because they do not have to maintain any context information. Each of the front-end portions of the MPA passes the user input to the back-end portion of the MPA. The logic contained in the front-end portions is limited and therefore does not consume excessive system resources.
As described above, in accordance with one embodiment of the invention, the MPA is divided into a front-end portion and a backend portion. The INT13 hook 305 and IDE filter driver 310 are the front-end portions of the MPA. For example, the INT13 hook 305 is still implemented in real mode, but acts as an interface to assert an I/O request from the BIOS 302 or DOS 304. For one embodiment of the invention the OS could be any OS that accesses the HD through an INT13 and is run in real mode, including DOS or an OS loader (e.g., NT loader or Linux needle). The INT13 hook 305 (MPA front-end) does not process the I/O request itself, but communicates the I/O request, using an SMI, to the MPA back-end portion 322 implemented in SMM 321 for processing. That is, the front-end portion intercepts the I/O request and indicates to the back-end portion what is to be done with the I/O request. The back-end portion then, analyzes the I/O request and tells the front-end portion how to effect the request. The front-end portion leverages the INT13 (e.g., INT13 307, INT13 316) in real mode to fulfill the I/O request.
Likewise, the IDE filter driver 310 is still implemented in the OS kernel address space and functions as an interface between the OS 306 and the MPA back-end portion 322 implemented in SMM 321. The DOS 104 requests OS kernel and driver files the INT13 hook 305 to boot OS 306. For OS, the front-end portion leverages the IDE driver (e.g., IDE driver 312) to fulfill the I/O request.
The INT13 hook 305 or the IDE filter driver 310 may have to communicate multiple I/O requests from the BIOS or OS, respectively, to the MPA back-end portion 322. For example, the MPA back-end portion 322 may contain an application algorithm that requires access to data structures (e.g., an HDP algorithm mapping table) that are stored on HD 320. The INT13 hook 305 or IDE filter driver 310 may receive a write request pertaining to specific data blocks. The INT13 hook 305 or IDE filter driver 310 then communicates that request to the SMM 321. The MPA back-end portion 322 checks if the requested data blocks are protected, if so, the MPA back-end portion 322 will load the mapping entries from the HD 320 if that entry does not exist in memory at that time. Therefore, the MPA back-end portion 322 may issue further requests (not included in the original I/O request) to access the required data. That is, because the SMM 321 may not be able to access hard disk 320, directly, the MPA back-end portion 322 will request an MPA front-end portion to read or write some data on behalf of the MPA back-end portion 322. As shown in Figure the MPA back-end portion 322 may access the HD 320 directly, but practically the MPA back-end portion 320 may instruct an MPA front-end portion to access the HD 320 on its behalf due to compatibility issues in accessing the HD 320 from SMM 321.
Once the MPA back-end portion 322 has all of the required data, the received request is processed. The MPA back-end portion 322 will then communicate the results of the processing to the INT13 hook 305 (or IDE filter driver 310).
For one embodiment of the invention, system 300, shown in
Moreover, for one such embodiment, the INT13 hook or IDE filter driver is much easier to implement and consumes much less resources in comparison to prior art schemes, because the HDP algorithm is not implemented in the INT13 hook or IDE filter driver, but in the SMM instead. The increased memory in the SMM (i.e., relative to real mode memory) allows more complex HDP algorithms to be implemented. Where prior art schemes in which the HDP software was implemented in real mode had limited features due to the limited memory (i.e., 1 MB), embodiments of the invention have access to the greater memory capacity of the SMM. For example a prior art scheme may provide redirection of read requests in the INT13 hook so that Windows NT or Linux could boot properly. Such schemes however may not provide redirection of write requests because OS loaders (e.g., Linux needle, NT loader, etc.) seldom write to the HD. Implementing the HDP algorithm in the SMM allows the INT13 hook to provide all of the features of the IDE filter driver in the OS (e.g., write redirect).
The additional memory also allows the HDP algorithm to be written in a high level language (e.g., C programming language) rather than assembly language which was typical in prior art schemes due to memory constraints. Moreover, because the HDP algorithm is implemented only once in the SMM and shared by multiple front-end portions, debugging is easier and less time consuming.
Embodiments of the invention have been described that provide a HDP software implemented as a front-end portion that provides an interface between the BIOS and a back-end portion of the HDP software. The back-end portion of the HDP software is implemented in the SMM and contains the HDP mapping algorithm. However, it will be apparent to those skilled in the art that embodiments of the invention are applicable to a variety of MPAs.
In accordance with one embodiment of the invention, the HDP software is implemented under DOS without additional hardware support while maintaining compatibility. Embodiments of the invention allow for implementation of low-cost HDP software without impacting performance the increased costs of prior art schemes (e.g., add-in cards).
Embodiments of the invention include methods having various operations, many of which are described in their most basic form, but operations can be added to or deleted from any of the methods without departing from the basic scope of the invention. The operations of various embodiments of the invention may be performed by hardware components or may be embodied in machine-executable instructions as described above. Alternatively, the operations may be performed by a combination of hardware and software. Embodiments of the invention may be provided as a computer program product that may include a machine-readable (machine-accessible) medium having stored thereon instructions, which may be used to program a computer (or other electronic devices) to perform a process according to embodiments of the invention as described above.
A machine-accessible medium includes any mechanism that provides (i.e., stores and/or transmits) information in a form accessible by a machine (e.g., a computer, network device, personal digital assistant, manufacturing tool, any device with a set of one or more processors, etc.). For example, a machine-accessible medium includes recordable/non-recordable media (e.g., read only memory (ROM); random access memory (RAM); magnetic disk storage media; optical storage media; flash memory devices; etc.), as well as electrical, optical, acoustical or other form of propagated signals (e.g., carrier waves, infrared signals, digital signals, etc.); etc.
DPS 401 interfaces to external systems through communications interface 413. Communications interface 413 may include a radio transceiver compatible with wireless telephone signals or other interfaces for coupling a device to other devices. In one embodiment of the present invention, carrier wave signal 425 is received/transmitted between communications interface 413 and network 450. In one embodiment of the present invention, a communications signal 425 may be used to interface DPS 401 with another computer system, a network hub, router or the like. In one embodiment of the present invention, carrier wave signal 425 is considered to be machine readable media, which may be transmitted through wires, cables, optical fibers or through the atmosphere, or the like.
In one embodiment of the present invention, processor 403 may be a conventional microprocessor, such as for example but not limited to an Intel ×86 or Pentium family microprocessor, a Motorola family microprocessor, or the like. Memory 405 may be a machine-readable medium such as dynamic random access memory (DRAM) and may include static random access memory (SRAM). Display controller 409 controls in a conventional manner a display 419, which in one embodiment of the invention may be a cathode ray tube (CRT), a liquid crystal display (LCD), an active matrix display, a television monitor or the like. The input/output device 417 coupled to input/output controller 415 may be a keyboard, disk drive, printer, scanner and other input and output devices (e.g., a mouse). In one embodiment of the present invention, audio controller 427 controls in a conventional manner audio output 431 and audio input 429.
Storage 411 may include machine-readable media such as for example but not limited to a magnetic hard disk, a floppy disk, an optical disk, a smart card or another form of storage for data. In one embodiment of the present invention, storage 411 may include removable media, read-only media, readable/writable media or the like. Some of the data may be written by a direct memory access process into memory 405 during execution of software in computer system 401. It is appreciated that software may reside in storage 411, memory 405 or may be transmitted or received via modem or communications interface 413. For the purposes of the specification, the term “machine readable medium” shall be taken to include any medium that is capable of storing data, information or encoding a sequence of instructions for execution by processor 403 to cause processor 403 to perform the methodologies of the present invention.
While the invention has been described in terms of several embodiments, those skilled in the art will recognize that the invention is not limited to the embodiments described, but can be practiced with modification and alteration within the spirit and scope of the appended claims. The description is thus to be regarded as illustrative instead of limiting.
Filing Document | Filing Date | Country | Kind | 371c Date |
---|---|---|---|---|
PCT/CN04/01585 | 12/31/2004 | WO | 00 | 8/23/2007 |