This disclosure relates generally to computer system platforms and boot procedures thereof, and, more particularly, to methods and apparatus to optimize a basic input/output system (BIOS) for a partitioned platform.
Computing devices, personal computers, workstations, and servers (hereinafter “computer” or “computers”) typically include a basic input/output system (BIOS) as an interface between computer hardware (e.g., a processor, chipsets, memory, etc.) and an operating system (OS). The BIOS includes firmware and/or software code to initialize and enable low-level hardware services of the computer, such as basic keyboard, video, disk drive, input/output (I/O) port, and chipset drivers associated with a computer motherboard.
A computer that executes separate and multiple copies of an OS on computer hardware is referred to as a partitioned platform. Each instance of a separate OS on the platform is referred to as a partition of the platform and may use shared hardware resources (e.g., same central processing unit (CPU), same bus, etc.), yet use non-overlapping subset(s) of memory (e.g., random access memory (RAM), read-only memory (ROM), dynamic random access memory (DRAM), hard-drive space, etc.).
A partitioned platform may also have dedicated resources instantiated by server hard partitioning. Servers that employ hard partitioning may have a complete set of resources fully replicated in each partition. A rich (i.e., complete) set of resources may include multiple CPU's, large amounts of memory, and many I/O devices. As such, each partition, separated by various hardware mechanisms, typically includes a full BIOS that operates fully and independently. The hardware mechanisms for separating partitions, such as a service processor, are expensive to implement and time consuming.
Whether the underlying resources (i.e., the hardware and associated systems) are shared or dedicated, each partition executes in an environment that is independent of other environments within other partitions of the platform. Because the partitions operate independently and are unaware of the existence of any other partitions on the platform, the applications executing on their particular partitions are secure from one another. In such a case, even if one application contains a security flaw, such vulnerability is limited to only the breached partition, thereby leaving any other partitions unaffected. However, such independence results in each partition's BIOS executing all of its initialization instructions, even if one or more of the partitions has already executed such instructions.
Prior to partition creation, the platform hardware 165 initiates a CPU reset upon power-up. As discussed in further detail below, one of the multiple processors 170 is typically hard-coded to access a specific memory location, such as a fetch to BIOS 175 boot instructions. The BIOS 175 initializes memory 180 and a base minimum amount of platform hardware 165 to eventually allow each partition to run independently. However, creating each partition also requires initialization of a service processor 185. The service processor 185 thereafter creates each partition 105, 110, 115 in a serial manner. As a result, each of the partition BIOS 120, 125, 130 performs initialization in a serial manner. Initialization may include, but is not limited to, power on self test (POST) procedures for each CPU 170 and memory 180. Furthermore, because the platform hardware BIOS 175 already initialized the memory 180, the serial creation of partitions by the service processor 185 results in redundant procedures. For example, such POST procedures already performed by the platform BIOS 175 are repeated when each partition BIOS 120, 125, 130 also performs memory 180 initialization, thereby wasting significant amounts of time.
Generally speaking, each computer system has a particular set of hardware that, when working together, allows the computer system to execute an operating system. Such computer systems may include personal computers, workstations, PDAs, kiosks, and servers. Furthermore, upon successful initiation of an operating system, the computer system may thereafter execute particular user applications, such as word processing applications, spreadsheet applications, Internet browser applications, games, and/or other custom and commercial applications. Prior to executing the applications, the operating system typically initializes and takes control of the computer system hardware, including hard drive(s), memory, I/O facilities including, but not limited to disk adapters, compact disk (CD) drives, digital versatile disk (DVD) drives, local area network (LAN) adapters, serial ports, terminals, graphics/audio cards, etc. Because the operating system is itself a software application read from a hard drive, a base level initialization of the underlying hardware is accomplished via BIOS procedures before the operating system may take overall control of the computer system. Base level initialization may include initialization of computer system components such as, for example, main memory (e.g., RAM), a non-volatile storage (e.g., a hard drive), a central processing unit (CPU), and various chipsets.
Typical approaches to initializing a partitioned platform may employ a full platform set of resources to be part of every partition, sometimes referred to as server style “hard” partitions. Benefits of a partitioned platform include a prevention of conflicts between applications (i.e., programs running on a computer) running on any other partitions. For example, if an error occurs in one partition, the execution of applications in other partitions is unaffected and continues as normal. Consequently, the hard partitions typically include the service processor 185 to initialize parts of the system and create partitions before any CPUs are allowed to perform duplicative initialization procedures due to a duplicate BIOS in each partition. Alternatively, a partitioned platform may be implemented by virtualization to create “soft” partitions with a full or emulated BIOS in each partition. For example, partitions implemented by virtualization typically have no service processor and employ a single CPU to initialize the system pursuant to a system-wide BIOS. The VMM is loaded by the CPU to create individual partitions for the platform. Additionally, the VMM may provide an individual full BIOS in each partition that implements redundant operations, or the VMM may include stubs or “fake” BIOSs for each partition. While the methods and apparatus to optimize a BIOS for a partitioned platform described herein apply to either partitions created by way of virtualization, partitions created by server style hard partitions, or various combinations thereof, the remaining embodiments are described, without limitation, in view of server style hard partitions. As each partition includes a copy of BIOS instructions, additional memory resources are consumed by having multiple copies of the same BIOS on a memory device (e.g., shared RAM, shared hard-drive, etc.).
Similar to a single partition computer/server system, a multi-partitioned computer/server system also performs low-level initialization procedures during boot time. As discussed above, the BIOS routines/instructions typically dictate hardware functionality of the hardware platform to prepare various components for operation before an operating system (OS) takes control of the computer/server system. Because each partition has a BIOS, the initialization of each partition typically executes the BIOS instructions, some of which perform POST procedures/instructions on various pieces of platform hardware.
POST procedures are programs that ensure hardware is present and working properly before loading an operating system. When problems are detected as a result of POST procedures, the computer/server system typically emits beeps from a speaker because video drivers may not yet be resident and operating to enable video display of errors to a user. Various BIOS manufacturers have unique beep codes that allow diagnostics without system video capabilities. The POST procedures that execute on hardware vary in complexity and time to complete. A very thorough POST procedure typically takes a significant amount of time to complete execution.
When a typical computer system (e.g., a non-partitioned system) is powered-up from a cold boot, a CPU reset is invoked. In particular, a chipset or CPU is typically hard-coded to fetch the first BIOS boot instructions during power-up at the top of an addressable memory (e.g., a flash-memory). The conventional BIOS boot process may begin executing BIOS boot instructions located at the addressable memory location, sometimes referred to as a jump location, and initialize a sufficient amount (base level) of platform hardware prior to more advanced sub-system initialization procedures. However, a computer system employing server style hard partitioning typically invokes the service processor 185 prior to the CPUs 170. The service processor 185 will typically have its own BIOS and execute in a monolithic (e.g., embedded ROM) style set of programs and not have access to more advanced resources, such as disks and/or network resources. Accordingly, the service processor 185 may use explicit dedicated resources (e.g., RAM, ROM, etc.) that are not used by the normal execution of the system. Additionally, the service processor 185 may perform various POST procedures on various system resources and initialize a complex interconnect that allows and/or restricts various CPUs 170 to/from access of various system resources, such as RAM and/or ROM. However, while each one of the CPUs 170 executes the BIOS (e.g., one of 120, 125, 130), such BIOS execution results in redundant POST procedures.
For example, every partition for a typical platform requires a CPU and memory for proper operation. In view of the example first partition 105, when the processor (CPU) initializes, it refers to the BIOS 120, which advances through various initialization procedures. Such procedures include an initialization of memory 180, which was already initialized at a global level by the BIOS 175 of the platform hardware 165. Upon completion of the creation of the first partition 105, the service processor 185 proceeds to create the second partition 110. Much like the initialization of the first partition 105, a second CPU of the several processors 170 refers to an addressable memory location that permits execution of BIOS 125 instructions. The BIOS 125 instructions execute to initialize hardware, including the memory 180 that was previously initialized by the platform BIOS 175 and by the first partition 105 BIOS 120. Persons of ordinary skill in the art will appreciate that such a serial initialization procedure includes redundancies that consume valuable time. Hardware initializations performed at early stages of a computer system boot process establish that, for example, the memory 180 is working properly. Despite this determination, subsequent partition creation by the service processor 185 results in compounding redundancies that are exacerbated as the number of partitions for any particular computer system grows.
Each partition includes many of the same BIOS 120, 125, 130 instructions, such as POST instructions to verify properly functioning hardware (e.g., a hard-drive test, RAM integrity test, etc.). Those same instructions are repeated multiple times despite the fact that previously executed POST instructions have indicated satisfactory results for the same hardware in conjunction with a POST performed by an adjacent partition. Such duplicative POST instructions consume valuable time and computing resources during the boot process.
Manufacturers of enterprise class servers are particularly concerned with the amount of time consumed during the boot process. Computer/server systems that boot faster are more likely to satisfy rigorous metrics of “high availability servers.” A high availability server is defined by its ability to be up and running 99.999% of the time during a year. This high standard translates into a limit of no more than approximately five minutes of downtime per year. Initialization of various hardware components consumes a substantial amount of boot time. While some hardware and/or firmware component initialization procedures require only an appropriate voltage be applied to it, other hardware and/or firmware components require additional tests to verify proper operation. In particular, many hardware component initialization procedures include POST. When redundant hardware POST procedures are performed, there is no additional knowledge gained about the hardware in exchange for the time spent performing the redundant POST procedures.
Computer systems may also contain many more types of hardware components that require initialization, with or without POST procedures. For example, such other hardware components may include disk adapters, LAN adapters, serial/parallel ports, advanced graphics cards (AGP cards), sound cards, peripheral component interconnect (PCI) cards, and small computer system interface (SCSI) devices. When a computer system applies power to each of these devices, they may each execute independent POST procedures, such as POST procedures stored on a local BIOS (typically referred to as an “option ROM”) of the component. Regardless of the type of hardware devices of the computer system that are to be initialized, or whether the BIOS includes initialization for POST and non-POST devices, duplicative initialization of the same hardware component wastes significant amounts of time in a partitioned system.
Unlike the platform hardware of
The partition manager 284 includes an-overall description of the platform 200. In other words, the partition manager 284 includes a road map of partitions. Because the partition manager 284 is aware of the total number of partitions, and has access to the per-partition BIOS 220, 225, 230 for each partition 205, 210, 215, the partition manager 284 determines which system resources 270 are allocated to the partitions 205, 210, 205. As discussed in further detail below, the partition manager 284 may configure the BIOS 282 to take advantage of such multi-platform resource allocation by initializing such hardware once, rather than multiple times during a platform boot, and/or during additions of new partitions. This initialization of such hardware may be done once in the BIOS 282 or in the per-partition BIOS 220, 225, 230 depending on what hardware is allocated to which partition. Furthermore, the partition manager 284 automatically analyzes the platform 200 for additional partitions that may be added during runtime. For example, a system administrator may invoke an additional partition to accommodate a new application, such as, for example, a new database indexing application. Subsequently, or contemporaneously, the partition manager 284 may analyze the platform 200 to detect the new partition and determine which resources it requires by accessing its per-partition BIOS. Underlying hardware resources that have already been initialized are not re-initialized (e.g., POST procedures). However, if the newly added example partition uses a hardware component that has not previously been initialized and/or is not listed in the per-partition BIOS of the other partitions, then such hardware component(s) are initialized at that time.
In the example partitioned platform 200, platform initialization may be separated into four parts. First, underlying platform hardware 270 that affects all partitions is initialized. Similarly, any such hardware 270 needed before individual partitions may be created is initialized. In other words, the hardware 270 that affects all partitions has a degree of commonality with those partitions. As discussed above, the hardware that affects all partitions is determined, in part, by the information and/or prior efforts of the partition manager 284. Initialization of the underlying platform may proceed from a cold boot in the following manner. A CPU reset causes the CPU to begin execution at a hard-coded memory location that typically contains a jump instruction that points to an alternate location containing BIOS boot instructions. The processor 275 boots the BIOS 282, which proceeds to initialize a minimum or base level amount of platform hardware 270 that is required for the partition manager 284. The partition manager 284 may be an API and/or other program stored on a non-volatile memory (e.g., ROM, flash-memory, hard-drive) that is loaded into memory 280 for operation. For example, while the memory 280 may be several gigabytes in size, the BIOS 282 may initialize only a small portion sufficient to load the partition manager 284 from, for example, flash-memory that may be located on a motherboard. Because the partition manager 284 was invoked after a minimal and/or base level amount of resources initialized, the partition manager 284 may proceed to partition creation without having consumed a large amount of time. The partition manager 284 may also identify any additional platform hardware 270 that may require initialization due to a commonality or dependency on the several partitions 205, 210, 215.
During a second part of platform 200 initialization, each individual partition is created, in which fragments of the underlying hardware are allocated to each partition. For example, a specific non-overlapping range of memory may be allocated to each partition in a hard-drive, RAM, etc.
Third, additional platform resources not previously initialized on a global scale are now initialized in view of the needs of each particular partition. For example, if the underlying platform hardware 270 includes an individual CPU for the first partition 205, second partition 210, and third partition 215, then the partition manager 284 may invoke a CPU reset on each of these processors simultaneously. As a result, each of the CPUs begins execution from its hard coded memory location, which may further point to a jump location. Such memory locations or jump locations point to the respective per-partition BIOS 220, 225, 230 for each partition 205, 210, 215. Unlike the platform 100 of
During a fourth part of platform 200 initialization, upon successful completion of a base-level hardware initialization, partition control is handed-off to the corresponding OSs 235, 240, 245, in which each OS may have specific initialization procedures within each partition.
The BIOS 282 initializes underlying platform hardware 270 that is common to any existing and/or planned partitions. At a most rudimentary level, each partition 205, 210, 215 requires some processor 275 resources, some memory 280 resources, and some I/O device 290 resources for proper operation. As such, the BIOS 282 consolidates the base level initialization at one time to allow each individual partition 205, 210, 215 to take advantage of underlying platform hardware 270 that is ready to operate upon request. Unlike the known computer platform 100 of
Because the BIOS 282 initializes the base-level platform hardware 270, which is needed prior to creation of some and/or all of the partitions 205, 210, 215, each of those partitions is relieved of that burden and may use its corresponding per-partition BIOS 220, 225, 230 in a focused and time-efficient manner. Such focused initialization is accomplished with the per-partition BIOS 220, 225, 230 to address specific platform hardware 270 that is needed by a particular partition.
Although
The process 300 begins with power-up (block 305) of a computer system that will be configured to have multiple partitions. The computer system may include underlying platform hardware, such as the hardware 270 of
Because each partition is created, wherein each partition is assigned its own subgroup of platform resources 270, the per-partition BIOS 220, 225, 230 of each partition 205, 210, 215 executes independently (i.e., in parallel) of the other partitions (blocks 330A, 330B, 330C). As a result, each partition 205, 210, 215 may initialize its resources in parallel without any temporal dependency of completion by another partition. For example, the first partition 205 per-partition BIOS 220 may initialize a specific unit of 500 megabytes of memory (block 330A) while the second partition 210 per-partition BIOS 225 may initialize a separate specific unit of 500 megabytes of memory (block 330B) at the same time. Persons of ordinary skill in the art will appreciate that each per-partition BIOS 220, 225, 230 may continue such independent and parallel initialization procedures for other platform hardware 270 that is specific to each of the created partitions 205, 210, 215. Such focused use of the per-partition BIOSs eliminates both excessive memory consumption and time consumption associated with multi-partition computer systems as compared with traditional multi-partition computer systems that employ redundancy techniques for initialization purposes.
Partitions that have initialized a sufficient amount of platform hardware via the per-partition BIOS instructions may hand-off control to an OS 235, 240, 245 (blocks 335A, 335B, 335C). While specific details regarding additional OS initialization procedures is beyond the scope of this patent, such OS initialization procedures may occur in parallel (blocks 335A, 335B, 335C), as shown in
Although the foregoing discloses example systems including, among other components, firmware and/or software executed on hardware, it should be noted that such systems are merely illustrative and should not be considered as limiting. For example, it is contemplated that any or all of these hardware and software components could be embodied exclusively in dedicated hardware, exclusively in software, exclusively in firmware, or in some combination of hardware, firmware and/or software. Accordingly, while the following describes example systems, persons of ordinary skill in the art will readily appreciate that the examples are not the only way to implement such systems.
The system 400 of the instant example includes a processor 410. For example, the processor 410 can be implemented by one or more Intel® microprocessors from the Pentium® family, the Itanium® family, the XScale® family, or the Centrino™ family. Of course, other processors from other families are also appropriate.
The processor 410 is in communication with a main memory including a volatile memory 412 and a non-volatile memory 414 via a bus 416. The volatile memory 412 may be implemented by Synchronous Dynamic Random Access Memory (SDRAM), Dynamic Random Access Memory (DRAM), RAMBUS Dynamic Random Access Memory (RDRAM) and/or any other type of random access memory device. The non-volatile memory 414 may be implemented by flash-memory and/or any other desired type of memory device. Access to the main memory 412, 414 is typically controlled by a memory controller (not shown) in a conventional manner.
The computer 400 also includes a conventional interface circuit 418. The interface circuit 418 may be implemented by any type of well known interface standard, such as an Ethernet interface, a universal serial bus (USB), and/or a third generation input/output (3GIO) interface.
One or more input devices 420 are connected to the interface circuit 418. The input device(s) 420 permit a user to enter data and commands into the processor 410. The input device(s) can be implemented by, for example, a keyboard, a mouse, a touch screen, a track-pad, a trackball, isopoint and/or a voice recognition system.
One or more output devices 422 are also connected to the interface circuit 418. The output devices 422 can be implemented, for example, by display devices (e.g., a liquid crystal display, a cathode ray tube display (CRT), a printer and/or speakers). The interface circuit 418, thus, typically includes a graphics driver card.
The interface circuit 418 also includes a communication device such as a modem or network interface card to facilitate exchange of data with external computers via a network 424 (e.g., an Ethernet connection, a digital subscriber line (DSL), a telephone line, coaxial cable, a cellular telephone system, etc.).
The computer 400 also includes one or more mass storage devices 426 for storing software and data. Examples of such mass storage devices 426 include floppy disk drives, hard drive disks, compact disk drives and digital versatile disk (DVD) drives.
As an alternative to implementing the methods and/or apparatus described herein in a system such as the device of
Although certain example methods, apparatus, and articles of manufacture have been described herein, the scope of coverage of this patent is not limited thereto. On the contrary, this patent covers all methods, apparatus and articles of manufacture fairly falling within the scope of the appended claims either literally or under the doctrine of equivalents.
Number | Name | Date | Kind |
---|---|---|---|
6421775 | Brock et al. | Jul 2002 | B1 |
20030033512 | Austen et al. | Feb 2003 | A1 |
20050015581 | Chen | Jan 2005 | A1 |
20050216720 | Michaelis et al. | Sep 2005 | A1 |
20070300299 | Zimmer et al. | Dec 2007 | A1 |
20080244598 | Tolopka et al. | Oct 2008 | A1 |
Number | Date | Country | |
---|---|---|---|
20070234031 A1 | Oct 2007 | US |