Method, computer program product and data processing system with bridging function between Virtual Machine Monitor and Bare-Metal Boot Process

Abstract

Method in a data processing unit for performing a bare-metal boot operation for the bare-metal boot of a control program, comprising: Booting the data processing unit into a hypervisor ownership phase of the bare-metal boot process, wherein during the hypervisor ownership phase of the bare-metal boot process a hypervisor is loaded and controls and manages platform hardware in the data processing unit; Booting the data processing unit from the hypervisor ownership phase of the bare-metal boot process into a transition phase of the bare-metal boot process, in which the hypervisor releases control and management of the data processing unit's platform hardware to the control program; and Booting the data processing unit from the transition phase into a control program ownership phase of the bare-metal boot process, in which the control program has full control and manages the platform hardware, performing the bare-metal boot process without restarting the data processing unit. wherein during the hypervisor ownership phase of the bare-metal boot process, a bootstrap execution of the control program is performed using the hypervisor, the hypervisor providing control program access to a hardware platform of the data processing unit, so that the control program discovers units of the hardware platform and loads appropriate unit drivers into a unit driver stack of the control program.

Description

BACKGROUND

[0001] The present invention relates generally to an improved method, an improved computer program product and an improved data processing system with a bridging function between Virtual Machine Monitor and Bare-Metal Boot Process.

[0002] Using a hypervisor, also known as a "virtual machine monitor" (VMM), multiple operating systems can run simultaneously on a single system, such as a host computer or a server that provides data processing services to host systems. This feature is often referred to as "hardware virtualization." The hypervisor can provide a virtual platform for guest operating systems and monitor their execution. In this way, multiple operating systems, including multiple instances of the same operating system, can share the hardware resources of a data processing system, either as a standalone data processing system or as a distributed data processing system.

[0003] Hypervisors are classified as either Type 1 or Type 2. A Type 1 hypervisor (or native bare-metal hypervisor) runs directly on the host hardware to control the hardware and monitor guest operating systems. A guest operating system therefore runs on a separate operating system environment, with the hypervisor layer representing a separate second software layer and the guest operating systems running on a different layer above the hardware. US Patent 2005 / 0091365 A1 discloses a virtual machine monitor that is inserted between computer hardware and an operating system at runtime.

[0004] From US 2009 / 0 164 990 A1, a mechanism is known which determines which input / output mechanism each virtual machine should use, based on the available input / output resources of the virtual machines, the number of running virtual machines and their input / output requirements, and the input / output requirements of the virtual machine in question.

[0005] US 4 887 202 A discloses an I / O control system comprising an identification section for identifying an I / O device requesting a change to a direct I / O execution mode, an evaluation section for evaluating a mode change condition, and a mode selection section for selecting a mode.

[0006] The object of the present invention is to provide an improved method, an improved computer program product and an improved data processing system with a bridging function between Virtual Machine Monitor and Bare-Metal Boot Process.

[0007] This problem is solved by the subject matter of main claim 1 and dependent claims 10 and 19, which define the present invention.

[0008] Preferred embodiments of the present invention are the subject of the dependent claims. SUMMARY

[0009] In an illustrative embodiment, a data processing unit (DPU) provides a method for performing a bare-metal boot operation to bare-metal boot a control program. The method includes booting the DPU into a hypervisor ownership phase of the bare-metal boot operation. During the hypervisor ownership phase, a hypervisor is loaded and controls and manages the DPU's platform hardware. The method further includes booting the DPU from the hypervisor ownership phase into a transition phase of the bare-metal boot operation, in which the hypervisor releases control and management of the DPU's platform hardware to the control program.Furthermore, the procedure involves booting the data processing unit from the transition phase into a control program ownership phase of the bare-metal boot process, in which the control program has complete control and manages the platform hardware. Moreover, the bare-metal boot process is performed without a software restart or power cycling of the data processing unit.

[0010] In other illustrative embodiments, a computer program product is provided that includes a computer-usable or computer-readable medium containing a computer-readable program. When executed on a data processing unit, the computer-readable program causes the data processing unit to perform various operations or combinations thereof, as outlined above in relation to the embodiment illustrating the method.

[0011] In yet another illustrative embodiment, a system / device is provided. The system / device may include one or more processors and a memory connected to the one or more processors. The memory may contain instructions which, when executed by the one or more processors, cause the one or more processors to perform various operations or combinations thereof, as outlined above in relation to the embodiment illustrating the method.

[0012] These and other features and advantages of the present invention are described in light of the following detailed description of exemplary embodiments of the present invention, or will be made understandable to the person skilled in the art. Brief description of the different views in the drawings

[0013] The invention, as well as a preferred mode of use and further objectives and advantages of the invention, will, however, best become clear with reference to the following detailed description of illustrative embodiments in conjunction with the accompanying drawings, wherein: Fig. 1 A block diagram of a system for activating a hypervisor is illustrated in order to effectively assume control in a cloud computing environment according to embodiments of the present invention; Fig. 2 illustrates a block diagram of the host system 104 according to one or more embodiments of the present invention; Fig. 3 is an exemplary block diagram of the main operating elements of the data processing unit according to an illustrative embodiment in a bootstrap initial phase of a bare-metal control program; Fig. 4 an exemplary block diagram of the main operating elements of a data processing unit according to an illustrative embodiment during runtime operation, after a bare-metal boot operation has been performed to boot a bare-metal control program; Fig. 5 is a flowchart that outlines an exemplary functional sequence of a dynamic transition into a bootloader mode according to an illustrative embodiment; Fig. 6 is a flowchart that outlines an exemplary functional sequence of a fixed transition to a bootloader mode according to an illustrative embodiment; Fig. 7 is a flowchart that outlines an exemplary functional sequence of a bootloader operating mode according to an illustrative embodiment. DETAILED DESCRIPTION

[0014] During a computer system's boot process, the computer system itself can start and initialize, and then boot a control program such as an operating system or a hypervisor. The initial boot of a Type 1 hypervisor is a "bare-metal" boot process because the hypervisor is in a state of direct control of the hardware platform. The term "bare-metal" means that the hypervisor does not need to access the underlying hardware resources through another software layer. A "non-bare-metal" boot process of code means that the code must communicate with another software layer that exists logically between the code and the underlying hardware resources. Booting guest operating systems, i.e., virtual machines, is a virtual "non-bare-metal" boot process because the guest operating systems boot on top of the Type 1 hypervisor.

[0015] The data processing unit (DPU) initially starts with a bare-metal boot process. The DPU hardware is designed to automatically initiate code execution in system firmware. The firmware performs preliminary hardware initialization operations, such as properly configuring the DPU's processors, cache, and memory subsystems. The firmware then proceeds to discover and initialize the input / output units, and finally, it locates a boot device and performs a bootstrap operation. The software being booted utilizes the firmware for a relatively short period to assist with its own bootstrap process.Normally, this means that the booted software uses the firmware to load only as much of itself (unit drivers and the like) as is necessary to be self-sufficient and no longer requires the firmware. A very limited set of firmware services is provided and intended to operate for the lifetime of the booted software. One such firmware service is defined, for example, by the ACPI specification (ACPI = Advanced Configuration and Power Interface).

[0016] In some situations, it may be necessary to perform a bare-metal boot with a different hypervisor or operating system than the one currently running on the computer system. For example, suppose a system administrator, management application, or similar entity determines at some point during the operation of the computer system that the system should be used for other purposes, to perform different functions, provide different services, or the like. To perform the bare-metal boot with a different hypervisor or operating system, the computer system must go through its firmware initialization phase (e.g., an initialization phase of a BIOS layer (BIOS = Basic Input / Output System), UEFI layer (UEFI = Unified Extensible Firmware Interface), and / or an open firmware layer), and in a bootstrap load operation, the new control program must be loaded.The new hypervisor or the new operating system. This requires a relatively long time to accomplish. Furthermore, such an operation requires the presence of firmware to perform it.

[0017] As the authors of the present invention have determined, it would be advantageous to perform a bare-metal boot operation with a control program without having to repeat the firmware restart process, power cycle the data processing unit, or otherwise restart a control program. The illustrative embodiments described herein provide mechanisms for performing such a bare-metal boot operation of a control program, e.g., a hypervisor, operating system, virtual machine manager, or the like, without having to repeat the firmware restart process, i.e., without using platform firmware such as BIOS, UEFI, Open Firmware, or the like.The mechanisms of the illustrative embodiments significantly improve the times for changing the purpose of the computer system by providing mechanisms to perform a bare-metal boot of a control program without resetting the computer system and passing through the platform firmware for restart, and make it possible to perform such functionality on computer systems that do not have such firmware, i.e., in a “firmware-free” computer platform environment.

[0018] It will be clear to those skilled in the art that aspects of the present invention may be embodied in the form of a system, method, or computer program product. Accordingly, aspects of the present invention may take the form of an embodiment implemented entirely in hardware, an embodiment implemented entirely in software (including firmware, resident software, microcode, etc.), or an embodiment combining software and hardware aspects, which are collectively referred to herein as a "circuit," "module," or "system." Furthermore, aspects of the present invention may take the form of a computer program product embodied in one or more computer-readable media on which computer-usable program code is embodied.

[0019] Any combination of one or more computer-readable media can be used. The computer-readable medium can be a computer-readable signaling medium or a computer-readable storage medium. Computer-readable storage media can include, but are not limited to, an electronic, magnetic, optical, or electromagnetic system, an infrared or semiconductor system, or a device or unit of this kind, or any suitable combination thereof.More specific examples (incomplete list) of computer-readable storage media include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), an optical fiber, portable read-only storage in the form of a compact disc (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer-readable storage medium can be any tangible medium capable of containing or storing a program that can be used by or in conjunction with a system, device, or unit for instruction execution.

[0020] A computer-readable signal medium may, among other things, comprise a data signal transmitted in a baseband or as part of a carrier wave, containing computer-readable program code. Such a transmitted signal may take any variety of forms, including, but not limited to, electromagnetic or optical forms, or any suitable combination thereof. A computer-readable signal medium may be any computer-readable medium other than a computer-readable storage medium that is capable of transmitting, sending, or carrying a program that can be used by or in conjunction with a system, device, or unit for instruction execution.

[0021] Computer code embodied on a computer-readable medium may be transmitted using any suitable medium, including, but not limited to, wireless or wired media, optical fibers, radio frequency (RF) communication, etc., or using any suitable combination thereof.

[0022] Computer program code for performing operations on aspects of the present invention can be written in any combination of one or more programming languages, including an object-oriented programming language such as Java™, Smalltalk™, C++, or the like, and conventional procedural programming languages ​​such as "C" or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on the remote computer or server.In the latter scenario, the remotely located computer can be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection can be made to an external computer (for example, via the Internet using an Internet Service Provider).

[0023] The following describes aspects of the present invention with reference to flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to the illustrative embodiments of the invention. It is understood that each block of the flowcharts and / or block diagrams, and combinations of blocks in the flowcharts and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a specialized computer, or other programmable data processing device to create a machine such that the instructions executed by the processor of the computer or other programmable data processing device provide means for implementing the functions / actions specified in a block or blocks of the flowchart and / or block diagram.

[0024] These computer program instructions may also be stored in a computer-readable medium that can instruct a computer, other programmable data processing devices, or other units to function in a certain manner, such that the instructions stored in the computer-readable medium create a product that has the instructions that implement the function / action specified in a block or blocks of the flowchart and / or block diagram.

[0025] The computer program instructions can also be loaded into a computer, other programmable data processing devices, or other units to cause a series of operations to be performed on the computer, other programmable devices, or other units to create a computer-implemented process, such that the instructions executed on the computer or other programmable devices provide processes for realizing the functions / actions specified in a block or blocks of the flowcharts and / or block diagrams.

[0026] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to the various embodiments of the present invention. Accordingly, each individual block in the flowcharts or block diagrams can represent a module, a segment, or a portion of the code that includes one or more executable instructions for implementing the specified logic function(s). It should also be noted that in some alternative implementations, the functions specified in the block may be executed in a different order than that shown in the figures.For example, two consecutively listed blocks may indeed be executed essentially simultaneously, or the blocks may sometimes be executed in reverse order depending on the functionality involved. Furthermore, it should be noted that each block in the presented block schemes and / or flowchart, as well as combinations of blocks in the presented block schemes and / or flowchart, can be implemented using purpose-built hardware systems to perform the specified functions or actions, or using combinations of purpose-built hardware and computer instructions.

[0027] Therefore, the illustrative embodiments can be used in many different types of data processing environments. In principle, any computer system that uses bare-metal booting of a control program such as a hypervisor, operating system, or the like can utilize the mechanisms of the illustrative embodiments described herein. For the sake of illustration, however, this description assumes that a computer system has a "firmware-free" computing platform environment such as that described in the also pending U.S. patent application serial number 12 / 861,780 entitled "Methods and Systems for Enabling Control to a Hypervisor in a Cloud Computing Environment," in which we are co-owners and which was filed on August 23, 2010.In this computer system, a host computer is designed to provide a cloud computing environment, which is described below with reference to the . Fig. 1 and Fig. 2 is described. It should be clear that the mechanisms of the illustrative embodiments are not limited to these, but can be used in any computer system, as explained above. Fig. 1 and Fig. 2 are merely examples and are not intended as a limitation of the scope of protection of the illustrative embodiments of the present invention.

[0028] Fig. Figure 1 illustrates a block diagram of a system 100 for activating a hypervisor 102 to effectively assume control in a cloud computing environment according to embodiments of the present invention. With reference to Fig. In one embodiment, the system 100 can include a host system 104, which implements a cloud computing environment for one or more user systems 106. The host system 104 can exchange data with the user systems 106 via a network 108. In one or more embodiments, the host system 104 includes one or more servers, each with one or more processors (e.g., a CPU), which can read and execute instructions and process requests from user systems 106 in a cloud computing environment. Various applications can be run on the host system 104, and the system can serve as an application server, web server, and / or database server. The user systems 106 can be a desktop computer, a notebook computer, a multi-purpose computer, a smartphone, or any other suitable data processing unit with an interface for data exchange with the host system 104.Users can initiate various tasks on the host system 104 via user systems 106, for example, executing application programs. Although in . Fig. While Figure 1 depicts only a single host system, it is understood that multiple host systems can be implemented, each exchanging data with the others via a direct connection or through one or more networks. For example, multiple host systems can be interconnected via a distributed network architecture. The single host system 104 can also represent a group (cluster) of hosts that jointly execute processes, as described in more detail herein.

[0029] Network 108 can be any type of data exchange network known to a person skilled in the art. For example, Network 108 can be an intranet, an extranet, or a network such as the Internet, or a combination thereof. Network 108 can have wireless or wired connections, fiber optic connections, or other known or subsequently developed data exchange connections, utilizing any of the many different data exchange protocols and devices for connecting computer systems.

[0030] Host system 104 can access and store data on memory 110. Memory 110 can be any type of memory, which may include a secondary storage element, such as a hard disk drive, tape, or a storage subsystem, located inside or outside of host system 104. Types of data that can be stored on memory 110 include, for example, log files and databases. It should be clear that memory 110 is listed for the sake of simplicity and to facilitate explanation, and should not be interpreted as limiting the scope of protection. Memory 110 may consist of multiple storage units used by host system 104.

[0031] The host system 104 can run various applications, including the hypervisor 102 and multiple virtual machines 112. The hypervisor 102 can manage access to the host system 104's computing resources and act as a virtual machine monitor (VMM) to support the concurrent operation of multiple virtual machines 112 on the host system 104. Each virtual machine 112 can support specific guest operating systems and multiple user sessions for running software written for those guest operating systems. For example, one virtual machine 112 can support an instance of a particular operating system, while another virtual machine 112 runs an instance of a different operating system. Any suitable type of operating system known to a person skilled in the art can be supported by the hypervisor 102 through the virtual machines 112.

[0032] The data processing resources of the host system 104 can include any suitable hardware, software, and / or firmware, including the hardware, software, and / or firmware for enabling cloud computing services to be provided to the user systems 106. Some or all of these data processing resources can be used to facilitate the operation of the host system 104 (e.g., booting or powering on the host system) and to enable services for the user systems 106 in the cloud computing environment. Examples of data processing resources include, but are not limited to, memory 110, one or more input / output bus modules (I / O bus modules) 114, one or more processors 116, one or more I / O data exchange modules 117, a display adapter 118, a keyboard adapter 120, a mouse adapter 122, and the like.These and other data processing resources located in or accessible to the host system 104 can be used by the hypervisor 102 to enable a user system 106 to operate an assigned virtual machine 112.

[0033] The I / O data exchange modules 117 can be configured to send data exchange traffic to and receive data exchange traffic from the network 108. For example, the I / O data exchange modules 117 can manage the exchange of messages between user systems 106 and the host system 104. Such messages could include, for example, information relating to cloud computing services provided to user systems 106 by the host system 104, as will be clear to the person skilled in the art.

[0034] According to some illustrative embodiments, the host system 104 may include a platform initialization module 124. The platform initialization module 124 may be implemented by hardware, software, firmware, or combinations thereof to initialize the host system 104 in order to provide cloud computing services to one or more of the user systems 106. According to some illustrative embodiments described herein, the platform initialization module 124 may be used during booting or power-up to initialize data processing resources of the host operating system 104.

[0035] Apart from other data processing resources, in response to the booting or power-on of host system 104, some data processing resources may be detected as having a priority for initialization. These data processing resources may be necessary to enable services in the cloud computing environment for user systems. In response to the booting or power-on of host system 104, the platform initialization module 124 may initialize one or more of the detected data processing resources to effectively enable services for user systems. The detected data processing resources can be initialized in a predefined order.The detected data processing resources may include, but are not limited to, all or part of the memory 110, the I / O bus module 114, the processor 116, the display adapter 118, the keyboard adapter 120, the mouse adapter 122, various other data processing resources, and the like. Other data processing resources, such as, but are not limited to, another part of the memory 110, may be initialized after or simultaneously with the activation of services for the user systems 106.

[0036] Fig. Figure 2 illustrates a block diagram of the host system 104 according to one or more embodiments of the present invention. This exemplary block diagram refers, for illustrative purposes, to the diagram shown in Figure 2. Fig. 1. Host system 104 is referenced; the reference to the example from Fig. However, 1 should not be interpreted as a limitation. As in Fig. As shown in Figure 2, the host system 104 can have a variety of layers and functions to enable user systems 106 to use the virtual machines 112 in the cloud computing environment. The host system 104 can have a hardware layer 200 with the processor (e.g., a CPU) 116, a memory control unit 202, and the memory 110. The processor 116 can interact with the memory control unit 202, which can control writing data to and reading data from the memory 110. The memory 110 can have multiple memory modules, each of which can have multiple memory units, such as, but not limited to, RAM chips (RAM = Random Access Memory). The hardware layer 200 can also include other suitable hardware, such as, but not limited to, data exchange channels, I / O ports, a clock, bus systems, and control units.The processor 116 can be supported by a processor support module 203, which is located above hardware layer 200.

[0037] Hypervisor 102 resides above hardware layer 200 and supports the execution of virtual machines. For example, Hypervisor 102 can support the execution of guest operating systems 204 within the virtual machines. A virtualized boot service module 205 can provide boot functionality and support for the guest operating systems 204. Furthermore, Hypervisor 102 can be responsible for both sharing hardware resources and enforcing control rules, based on available hardware resources. In this example, Hypervisor 102 is a Type 1 hypervisor and therefore runs on bare metal in supervisor or privileged mode.

[0038] The host system 104 can have a driver stack 206, managed by the hypervisor 102, for controlling the operation of hardware resources. Furthermore, the host system 104 can have platform firmware tables such as, but not limited to, ACPI tables (ACPI = Advanced Configuration and Power Interface) and SMBIOS tables (SMBIOS = System Management Basic Input / Output System).

[0039] As mentioned above, the illustrative embodiments provide mechanisms for performing a bare-metal boot of a control program such as a hypervisor, operating system, another type of virtual machine manager (VMM), or the like, without repeating the firmware reboot process. In particular, the Hypervisor 102 is shown in Fig. 1 or another control program extended by the mechanisms of the illustrative embodiments to enable bare-metal booting of another control program using one or more from a bare-metal boot process in dynamic mode and / or a bare-metal boot process in fixed mode.

[0040] During bare-metal booting in dynamic mode, Hypervisor 102 operates normally, i.e., in a virtualized production environment, by hosting and managing a number of virtual machines. At some point during this normal operation, an administrator or management application determines that the purpose of the computing unit on which Hypervisor 102 is running needs to be changed to provide different functionality, a different service, or the like, which requires the execution of a different control program. For this bare-metal booting functionality in dynamic mode, Hypervisor 102 has logic, executed by the computing unit, to transition Hypervisor 102 into an operating mode that supports the bare-metal booting of a different control program.

[0041] During the bare-metal boot process in fixed mode, Hypervisor 102, because the data processing unit platform is initialized from a cold start or restart, has logic that loads Hypervisor 102 directly into an operating mode that supports bare-metal booting by another control program. In this operating mode, Hypervisor 102 does not manage multiple virtual machines.

[0042] Regardless of whether the bare-metal boot process operates in dynamic or fixed mode, Hypervisor 102 or any other control program has logic to enter and execute a bootloader mode. This allows the control program to boot via the bare-metal boot process and enables the control program, once booted via the bare-metal boot process, to detect the actual hardware resources. Hypervisor 102's bootloader mode causes it to emulate firmware services. Unlike the control program, which boots by accessing firmware services from the system firmware itself, Hypervisor 102 emulates the firmware services and handles calls to the firmware services' application programming interface (API), with input / output performed by the hypervisor's unit drivers.Furthermore, the bootloader operating mode of the Hypervisor 102 reveals to the control program, which is currently being booted via bare-metal boot, the true properties of the underlying hardware platform of the data processing unit, so that the bare-metal boot control program can load its corresponding unit drivers.

[0043] Once the booted bare-metal control program has completed its hardware unit detection, the loading of unit drivers, and its calls to firmware services (which are intercepted and served by the hypervisor, hypervisor unit drivers, and an API mapping function (mapper), as described in more detail below), the hypervisor provides logic to release control of the data processing unit's hardware platform to the control program. The booted bare-metal control program then completes its bootstrap process via its own unit driver stack through direct access to the physical hardware.Consequently, control of the data processing unit's hardware platform is transferred from control by the original hypervisor 102 to control by the booted bare-metal control program, which, due to the bare-metal boot process of this booted bare-metal control program, has direct access to the underlying hardware. The operation of the main elements of the illustrative embodiments will now be described in more detail with reference to the figures.

[0044] Fig. Figure 3 is an exemplary block diagram of the main operating elements of the data processing unit according to an illustrative embodiment in a bootstrap initial phase of a bare-metal control program. In the illustrated example, the bare-metal control program is a bare-metal operating system that is booted by the hypervisor using the mechanisms of the illustrative embodiments via a bare-metal boot process. This booting of the operating system via bare-metal bootstrap is accomplished without having to perform a software reset or power cycle the data processing unit. Furthermore, this allows the hardware platform environment to be "firmware-free" in the sense that the BIOS, UEFI, or open-firmware abstraction layer is not required to perform the bare-metal boot process of the subsequent control program.

[0045] As in Fig. As shown in Figure 3, a hypervisor 310, a VMM or other control program, and its associated unit driver stack 320 are executed on a hardware platform 330. The hypervisor 310 can be initialized and executed on the platform hardware 330 in a manner generally known in the art. As shown in Fig. As shown in Figure 3, the Hypervisor 310 has a logic 312 for bare-metal booting in dynamic mode, a logic 314 for bare-metal booting in fixed mode, a logic 316 for bootloader mode, and a firmware emulator logic 318. Logic 312 for bare-metal booting in dynamic mode is used to receive a request from an administrator or management application requesting the bare-metal booting of another control program, which in the illustrated example is a bare-metal operating system 360, and to perform operations to dynamically put the Hypervisor 310 into bootloader mode after the Hypervisor 310 is already running and managing virtual machines running on the data processing unit. The request might be received, for example, by an administrator or management application that...which sets the state of a mode or option value in an interface or the like. Logic 314 for the bare-metal boot process in fixed mode is used to initialize the hypervisor 310 into a bootloader mode when the hypervisor 310 is booted at the beginning.

[0046] Therefore, in response to a request to boot a different control program using bare-metal, logic 310 is used for the bare-metal boot operation in dynamic mode when hypervisor 310 is operating in "hypervisor mode," i.e., when hypervisor 310 manages virtual machines (not shown) running on the data processing unit. Logic 310 migrates or shuts down existing workloads currently running by the virtual machines managed by hypervisor 310. The actual migration and shutdown or termination of workloads is performed in a manner known in the art.Once these workloads are shut down or migrated, logic 312 for the bare-metal boot process in dynamic mode signals hypervisor 310 to enter a bootloader mode, which instructs hypervisor 310's bootloader mode logic 316 to perform the initial bare-metal boot of the bare-metal operating system 360 as described below. Signaling hypervisor 310 to enter a bootloader mode can be done, for example, by calling the hypervisor API at an administrative level.

[0047] On the other hand, during bare-metal boot in fixed mode, when Hypervisor 310 is to be initialized into a bootloader mode upon initial boot—that is, in response to powering on or resetting the data processing unit—logic 314 performs a check to determine if a boot-pass mode configuration structure indicates that Hypervisor 310 should boot into a bootloader mode. The boot-pass mode configuration structure might be stored, for example, in non-volatile system configuration RAM or similar memory. In response to the boot-pass mode configuration structure indicating that the hypervisor should boot into a bootloader mode, logic 314 signals Hypervisor 310 to enter bootloader mode.Otherwise, the hypervisor will be booted into a "hypervisor operating mode" so that bare-metal booting in dynamic mode can be performed at a later time.

[0048] As explained above, regardless of whether the bare-metal boot process is performed in dynamic or fixed mode, the hypervisor 310 is placed in a bootloader mode. This causes the bootloader logic 316 to handle the initial bare-metal boot of another control program, such as the bare-metal operating system 360. During bootloader mode, the bootloader logic 316 configures the data processing unit (DPU) so that the bare-metal operating system 360 can detect the actual platform hardware 330 and load its own DPU driver stack according to the detected platform hardware 330. The bootloader logic 316 enables this detection by setting a hypervisor present bit (HPB) 370 of the DPU to indicate that a hypervisor is not present.Guest control programs, such as the bare-metal operating system 360, can check the state of the hypervisor presence bit 370 to determine whether calls from the guest control program should be made to the hypervisor 310 or directly to the platform hardware 330 via the firmware services 340 and the guest operating system's own unit driver stack. If the hypervisor 310 is in hypervisor mode, it would set this hypervisor presence bit 370 to indicate that the hypervisor 310 is present, and therefore the guest operating system is loaded as a virtual machine managed by the hypervisor 310. However, during bootloader mode, the bootloader logic 316 sets or resets the state of the hypervisor presence bit 370 to indicate that the hypervisor 310 is not present.

[0049] Therefore, when the Bare-Metal OS 360 bootstrap operation is triggered, it reads the state of the hypervisor present bit 370 and determines that it will not load into a virtual machine, instead performing a bare-metal boot of itself. As a result, the Bare-Metal OS 360 passes firmware service API calls to the data processing unit's firmware services to perform operations for booting the Bare-Metal OS 360. Examples of such firmware services include a call to BIOS interrupt 13 (hex) to receive disk services such as reading disk blocks, a call to request an allocation of the system address space and associated RAM areas, and the like.However, with the mechanisms of the illustrative embodiments, the logic 340 of the firmware API mapping function is provided, for example, either as a separate component or as part of the hypervisor 310, which maps firmware service API calls from the bare-metal operating system 360 to emulated firmware services provided by the firmware emulator 318 of the hypervisor 310, so that the hypervisor 310 "intercepts" the firmware service API calls from the bare-metal operating system 360. Any input / output operations required as a result of the firmware service API calls from the bare-metal operating system 360, which are intercepted by the hypervisor 310, to perform the bootstrap operation to boot the bare-metal operating system 360, are performed by the hypervisor's unit drivers in the hypervisor's unit driver stack 320.

[0050] This means that the Hypervisor 310 provides a virtual hardware platform to the abstraction layer above the Hypervisor 310. As part of this virtual hardware platform, the Hypervisor 310 can provide a virtual BIOS layer. The Hypervisor 310 does not handle BIOS calls through a firmware BIOS, but rather through its own unit driver stack. In the case of bare-metal boot operations in the illustrative embodiments, the Hypervisor 310 can intercept a call to a firmware service, such as the BIOS call to read disks in the previously described example, and provide an appropriate set of actions for the firmware service call. This means that, in this illustrative embodiment, a BIOS disk call does not read directly from a real disk, but instead reads the corresponding block in a file, which represents a physical disk to the virtual machine.

[0051] Consequently, the already booted Hypervisor 310 handles the firmware service API calls using the emulated firmware services 318, instead of having to access the firmware services 350 in the firmware itself, which, depending on whether it is a firmware-free computing unit, may not actually be present in the computing unit. This means that although the bare-metal operating system 360 assumes it exchanges data with the firmware services 340 to perform operations for booting the bare-metal operating system 360, the firmware service API calls from the bare-metal operating system 360 are instead handled by the emulated firmware services 318 of the Hypervisor 310.

[0052] It should be noted that the Hypervisor 310 and its associated data structures, such as the global descriptor table, the interrupt descriptor table, and the like, reside in upper memory and are separate from the bare-metal operating system 360. This means that although the Hypervisor 310 provides bare-metal boot services, it must protect itself from the control program that is currently booting via bare metal. To function, the Hypervisor 310 must still own some of the basic hardware components, at least for a short period. Therefore, the Hypervisor 310 and its data structures reside in "upper memory" because it is usually easier to mislead a control program by suggesting that slightly less total system RAM is available than is actually present.The control program is tricked into believing that the "upper memory" doesn't even exist and is therefore inaccessible to the control program. This ensures that key areas of the overall system memory allocation are not reconfigured by the control program. Therefore, the term "upper memory" refers to a small sector of the address space above the memory allocation by the system RAM, which can be kept free from changes by the control program, which is currently booting via bare metal. Of course, other mechanisms that protect the Hypervisor 310 and its data structures can be used without deviating from the basic principle or scope of protection of the illustrative embodiments.

[0053] The bootstrap process to boot the bare-metal operating system 360 continues as the bare-metal operating system 360 performs operations to detect the underlying platform hardware 330 and make firmware service API calls to firmware services that have instead been mapped by logic 340 to the firmware API mapping function to emulated firmware services 318 in the hypervisor 310. This process continues to boot the key components of the bare-metal operating system 360 so that a sufficient portion of the operating system is loaded to be able to exit the firmware APIs and continue the bootstrap process using native (system-specific) components and drivers of the bare-metal operating system. For example, when a Microsoft Windows™ operating system begins to boot, it makes a series of disk read requests to the BIOS to load its core driver set.One of the core drivers is obviously the disk driver for the disk from which the operating system boots. Once drivers like these are in memory, Microsoft Windows™ stops using the BIOS and begins using its own driver stack. In another example, the UEFI has a special firmware call made by the control program that essentially states, "I'm finished with the firmware."

[0054] It should be noted that during this initial phase of operation, in which the bare-metal operating system 360 discovers the underlying platform hardware resources 360, such as memory, registers, processors, buses, etc., and makes firmware service API calls served by the hypervisor 310, the hypervisor 310 essentially "owns" the hardware platform 330 and controls / manages the hardware platform resources 330. Although the hypervisor 310 is positioned between the hardware platform 330 and the control program that is currently booting via bare metal—i.e., the bare-metal operating system 360—the hypervisor 310 allows the control program to "see" the hardware platform 330 as it truly is and still remains operational to complete the transition phase.To remain operational, the Hypervisor 310 makes the control program believe it is managing key resources, such as interrupts, at the hardware level, even though the Hypervisor 310 actually still controls / manages them. Essentially, during this phase of the bare-metal boot process, the Hypervisor 310 represents key hardware components, such as interrupts, based on their possible physical properties, but keeps them in a virtualized state to retain control of, or "ownership" of, the overall 310 hardware platform. Therefore, this phase is referred to as the "hypervisor ownership phase" of the bare-metal boot process.

[0055] Once the bare-metal operating system 360 loads enough components to exit the firmware service APIs, it enters the transition phase, during which the hypervisor 310 relinquishes control of, or ownership of, the hardware platform 330. Relinquishing control of, or ownership of, the hardware platform 330 involves the hypervisor 310 ceasing its processing of firmware service API calls via the firmware API mapping logic 340, for example, through a natural transition from using firmware service API calls to processing operations using the hypervisor's native stack. Additionally, the hypervisor 310 configures the hardware platform resources 330 to be used by the bare-metal operating system 360.This can include setting all control registers of the data processing unit to values ​​specified by the bare-metal control program, thereby disconnecting the hypervisor 310 from controlling the corresponding hardware platform resources 330. For example, the hypervisor 310 can take the virtual state of the remaining units (such as interrupts described earlier) and update the corresponding physical hardware so that it matches the remaining units.

[0056] Once the transition from the hardware platform 330, currently under the control and management of the hypervisor 310, to control and management by the bare-metal operating system 360 is complete, the operating system 360 can signal this completion to the hypervisor 310. This signaling can occur, for example, via an API call (as in the case of UEFI boot code) or a transition from a real processor mode to a protected processor mode (as in the case of BIOS boot code). In an illustrative embodiment, an optional supplemental software component 365 can be loaded on the bare-metal operating system 360 to report back to the hypervisor 310 that the transition of control of the hardware platform 330 from the hypervisor 310 to the bare-metal operating system 360 has been completed.

[0057] Furthermore, during the transition phase of the bare-metal boot process, after the hardware platform 330 control has been released and the completion of the transition from the hypervisor 310 to the bare-metal operating system 360 has been signaled, the hypervisor 310 can be reduced to a bare-bones hypervisor 310 that remains active to handle a small number of firmware API calls during runtime. For example, during the transition phase, the hypervisor 310 learns the addresses of the runtime routines via firmware service API calls. These addresses can be maintained by the bare-bones hypervisor and used to handle a small number of firmware calls from the control program, such as those described in the ACPI specification, which can still be made during runtime. The firmware API mapping logic 340 can also be discarded and not used further.Hypervisor 310 can reduce its size by marking memory areas no longer used by Hypervisor 310 as "free." To notify the control program, such as the bare-metal boot operating system 360, which is now started and running, that "more memory" is available, a "hot-add" event can be generated. The control program can then respond to this hot-add event by detecting it and adding the new memory areas to its own memory pool.

[0058] At this point in the bare-metal boot process, the bare-metal operating system 360, i.e., the control program booted via bare metal, takes control of and manages the platform hardware 330. Therefore, this phase of the bare-metal boot process, which follows the transition phase, is referred to as the "control program ownership phase," in which the control program in the illustrated example is the bare-metal operating system 360. During this phase of the bare-metal boot process, the bare-metal operating system 360 completes its bootstrap operation via its own unit driver stack by directly accessing the physical hardware of the platform 330.This means that during the hypervisor's ownership phase, the unit driver stack was built by the Bare Metal OS 360 by detecting the actual underlying Platform 330 hardware and loading the corresponding unit drivers. The Bare Metal OS 360 then uses this unit driver stack to complete its bootstrap process, which includes tasks such as disk reads, disk writes, network operations, initializing video and audio output, and so on. Once the Bare Metal OS 360 has completed its bootstrap process using its own unit driver stack, it takes control of the Platform 330 hardware and is ready to handle workloads, such as those resulting from running applications.

[0059] Fig. Figure 4 is an exemplary block diagram of the main operating elements of a data processing unit according to an illustrative embodiment during runtime operation, after a bare-metal boot operation has been performed to boot a bare-metal control program. As shown in Fig. Figure 4 shows the Hypervisor 310 in comparison to the Fig. 3 is reduced to a bare-metal hypervisor 410 and its associated unit driver stack 420. The firmware services 430 are minimized and used by the bare-metal hypervisor 410 to handle a small number of firmware calls by the bare-metal operating system 440. The bare-metal operating system 440 can exchange data and interact directly with the platform hardware 460 via the bare-metal operating system driver stack 450, without having to make calls to the hypervisor 310 or the bare-metal hypervisor 410. Therefore, with the exception of a small number of firmware API calls that can still be handled by the bare-metal operating system 440, the bare-metal hypervisor 410 is essentially not used to run workloads on the platform hardware 460.

[0060] Therefore, by providing mechanisms for performing a bare-metal boot of a control program without resetting the computer system (i.e., switching the power supply to the data processing unit off and on and running through the platform firmware to restart), the mechanisms of the illustrative embodiments significantly improve the time to change the use of the computer system. The mechanisms of the illustrative embodiments provide the functionality to transition from a hypervisor ownership phase of a boot process, in which the hypervisor controls and manages the hardware platform, to a control program ownership phase, in which control and management of the hardware platform are transferred from the hypervisor to a bare-metal booted control program, e.g., another operating system, another hypervisor, or another type of control program.Since this bare-metal boot process is performed using emulated firmware service APIs in the hypervisor and not using firmware service APIs provided by the firmware itself, the mechanisms of the illustrative embodiments further provide the ability to perform a bare-metal boot process on data processing units that do not have such firmware, i.e., in "firmware-free" computer platform environments.

[0061] To further illustrate the bare-metal boot process and summarize the details described above, reference will now be made to the Fig. Figures 5 to 7, which, according to an illustrative embodiment, outline exemplary operations of the main elements of a data processing unit during a bare-metal boot process. Fig. Figure 5 is a flowchart outlining an exemplary functional sequence of a dynamic transition into a bootloader mode according to an illustrative embodiment. Fig. Figure 6 is a flowchart outlining an exemplary functional sequence of a fixed transition to a bootloader mode according to an illustrative embodiment. Fig. Figure 7 is a flowchart that outlines an exemplary functional sequence of a bootloader operating mode according to an illustrative embodiment.

[0062] With reference to Fig. 5 can be in Fig. The five outlined operations can be implemented, for example, by logic 312 of hypervisor 310 for dynamic mode in Fig. 3, for example, during an initial phase of a bare-metal boot process to enter a bootloader operating mode, thus enabling the bare-metal boot of a control program. As in Fig. As shown in Figure 5, the dynamic mode begins with the hypervisor running in a hypervisor mode, where the hypervisor manages one or more virtual machines running on the data processing unit (Step 510). The hypervisor receives a request to instruct it to enter a bare-metal boot mode in order to boot another control program using bare metal (Step 520). As mentioned above, the request can be received from a system administrator, an administrative application, or the like.

[0063] In response to receiving the request, the hypervisor controls the virtual machines it manages to migrate or shut down the workloads currently running on those virtual machines (step 530). A decision is made as to whether all existing workloads have been migrated or shut down (step 540). If not, the operation returns to step 530 until all workloads have been migrated or shut down. Once all workloads have been migrated or shut down, the hypervisor enters a bootloader mode, which handles the bare-metal boot of the other control program according to the illustrative embodiments (step 550). The operation then terminates.

[0064] With reference to Fig. 6 can be in Fig. The 6 outlined operations can be implemented, for example, by the logic 314 of the hypervisor 310 for the fixed mode in Fig. 3, for example, during an initial phase of a bare-metal boot process to enter a bootloader operating mode, thus enabling the bare-metal boot of a control program. As in Fig. As shown in Figure 6, the dynamic mode begins with the power supply state of the data processing unit (DPU) being switched off and on, e.g., powering on or resetting the DPU (step 610). In response to the power supply switching, the hypervisor begins loading into the DPU (step 620). A boot-pass mode structure is checked to determine whether the hypervisor should be loaded in a boot-pass mode, where the hypervisor is configured to perform a bare-metal boot of another control program (step 630). If the boot-pass mode structure is in a state indicating that the hypervisor should not be loaded in a boot-pass mode (step 640), the full hypervisor is loaded in hypervisor mode (step 650).If the boot-through-mode structure has a state indicating that the hypervisor is to be loaded in a boot-through mode (step 640), the hypervisor is loaded in a bootloader mode that handles the bare-metal boot of the other control program according to the illustrative embodiments (step 660). The process then terminates.

[0065] Regardless of whether the hypervisor enters bootloader mode based on its dynamic or fixed mode, bootloader mode is used to perform a bare-metal boot of another control program without power cycling or firmware initialization. Fig. Figure 7 is a flowchart outlining a bootloader mode operation in which a bare-metal boot operation is performed using three phases of the operation: a hypervisor ownership phase, a transition phase, and a control program ownership phase.

[0066] As in Fig. As shown in Figure 7, a hypervisor ownership phase 710 begins with the hypervisor entering bootloader mode. This involves using bootloader logic to transfer platform ownership from the hypervisor to the bare-metal control program, which is currently booting using bare metal (step 711). During this phase 710, the hypervisor allows the bare-metal control program to discover the actual underlying hardware resources of the hardware platform (step 712). The new bare-metal control program then begins its bootstrap process (step 713), which includes sub-processes 714 through 717.

[0067] As shown, one of these sub-processes is that the control program attempts to access firmware services during its initial loading process by making firmware service API calls, which the control program assumes are served by the firmware of the data processing unit (step 714). However, these firmware service API calls from the control program are mapped by a mechanism of the firmware service API mapping function logic to firmware services emulated by the hypervisor (step 715). The hypervisor's emulated firmware services can then perform input / output operations using the hypervisor's unit drivers to realize the operations requested by the firmware service API calls from the control program (step 716).Furthermore, the control program can determine the hardware resources / units and load corresponding unit drivers into a unit driver stack of the control program (step 717).

[0068] At a certain point during the hypervisor ownership phase (step 710), the control program completes its use of firmware services (step 718), at which point the bare-metal boot process enters the transition phase (step 720). During the transition phase (step 720), the hypervisor relinquishes its control of the hardware platform (step 721). As in Fig.As shown in Figure 7, transition stage 720 includes the sub-process where the hypervisor stops receiving firmware service API calls via the firmware service API mapping function logic and also stops managing hardware resources. Additionally, the hardware resources are configured for direct use by the control program (step 722). The full hypervisor can then be removed from memory and replaced with a stub hypervisor, that is, a very small application with limited functionality that remains active to handle a small set of firmware service API calls at runtime (step 723).

[0069] Once the hypervisor releases control of the hardware platform (step 721), the bare-metal boot process transitions into a new control program ownership phase (step 730). In this phase, the newly booted control program completes its bootstrap operation using its own unit driver stack, which was established during the hypervisor ownership phase (step 710) (step 731). The control program thus has direct access to the physical hardware platform resources. When the control program completes its bootstrap operation, it has full control of the hardware platform and is ready to execute workloads (step 732). The process then concludes.

[0070] As mentioned above, it should be clear that the illustrative embodiments can take the form of an embodiment implemented entirely in hardware, an embodiment implemented entirely in software, or an embodiment that includes both hardware and software elements. In a preferred embodiment, the mechanisms of the illustrative embodiments are implemented in software or program code, which includes, but is not limited to, firmware, resident software, microcode, etc.

[0071] A data processing system suitable for storing and / or executing program code includes at least one processor, which is connected directly or indirectly to memory elements via a system bus. These memory elements can include local memory, used during the actual execution of the program code, mass storage, and cache memory, which provides temporary storage for at least a portion of the program code to reduce the number of code retrievals from mass storage during execution.

[0072] Input / output units, or I / O units (including but not limited to keyboards, displays, pointing devices, etc.), can be connected to the system either directly or via intermediate I / O control units. Network adapters can also be connected to the system, allowing the data processing system to be connected to other data processing systems, remote printers, or storage devices via intermediate private or public networks. Modems, cable modems, and Ethernet cards are just some of the types of network adapters currently available.

Claims

[1] Method in a data processing unit for performing a bare-metal boot operation for bare-metal booting of a control program, comprising: Booting the data processing unit into a hypervisor ownership phase of the bare-metal boot process, wherein during the hypervisor ownership phase of the bare-metal boot process a hypervisor is loaded and controls and manages platform hardware in the data processing unit; Booting the data processing unit from the hypervisor ownership phase of the bare-metal boot process into a transition phase of the bare-metal boot process, in which the hypervisor releases control and management of the data processing unit's platform hardware to the control program; and Booting the data processing unit from the transition phase into a control program ownership phase of the bare-metal boot process, in which the control program has full control and manages the platform hardware, performing the bare-metal boot process without restarting the data processing unit. wherein during the hypervisor ownership phase of the bare-metal boot process, a bootstrap execution of the control program is performed using the hypervisor, the hypervisor providing control program access to a hardware platform of the data processing unit, so that the control program detects units of the hardware platform and loads appropriate unit drivers into a unit driver stack of the control program. [2] Method according to claim 1, wherein the control program is either an operating system, another hypervisor or another virtual machine manager. [3] The method of claim 1, further comprising during the hypervisor ownership phase of the bare-metal boot process: through the hypervisor, the interception of firmware calls from the control program that are directed to the firmware of the data processing unit; and The hypervisor handles the firmware calls using emulated firmware services provided by the hypervisor. [4] Method according to claim 3, wherein the interception of firmware calls comprises redirecting firmware calls to the emulated firmware services of the hypervisor using logic of a firmware mapping function that assigns the firmware calls to a corresponding emulated firmware service of the hypervisor for processing the firmware call. [5] Method according to claim 3, wherein the operation of the firmware calls using the emulated firmware services comprises the use of a unit driver stack of the hypervisor to perform operations on a hardware platform of the data processing unit to operate the firmware calls. [6] Method according to claim 3, wherein the booting of the data processing unit comprises transitioning from the hypervisor ownership phase of the bare-metal boot process to a transition phase of the bare-metal boot process: Interrupting the interception of firmware calls from the control program by the hypervisor; Reconfiguring hardware resources of the hardware platform for direct use by the control program; and Reducing the hypervisor to a bare-bones hypervisor that provides logic to handle a subset of calls to the firmware application programming interface at runtime. [7] Method according to claim 1, wherein booting the data processing unit from the transition phase into a control program ownership phase comprises activating the control program to directly perform operations with the hardware platform of the data processing unit using the unit driver stack of the control program. [8] Method according to claim 1, further comprising: Booting the hypervisor into a bootloader operating mode in which, in response to a request regarding the bare-metal booting of the control program, the hypervisor performs the bare-metal boot process by booting the data processing unit through the hypervisor ownership phase, transition phase, and control program ownership phase. [9] Method according to claim 8, wherein booting the hypervisor into the bootloader mode comprises dynamically transitioning the hypervisor into the bootloader mode after the hypervisor is already running on the data processing unit, or performing a fixed boot operation of the hypervisor into the bootloader mode, in which the hypervisor is initially running in the bootloader mode on the data processing unit. [10] Computer program product comprising a computer-readable storage medium containing a computer-readable program stored therein, wherein the computer-readable program, when executed on a data processing unit, causes the data processing unit to: the data processing unit boots into a hypervisor ownership phase of the bare-metal boot process, whereby during the hypervisor ownership phase of the bare-metal boot process a hypervisor is loaded and controls and manages platform hardware in the data processing unit; the data processing unit boots from the hypervisor ownership phase of the bare-metal boot process into a transition phase of the bare-metal boot process, in which the hypervisor releases control and management of the data processing unit's platform hardware to the control program; and The data processing unit boots from the transition phase into a control program ownership phase of the bare-metal boot process, in which the control program has full control and manages the platform hardware, with the bare-metal boot process being performed without restarting the data processing unit. wherein during the hypervisor ownership phase of the bare-metal boot process, a bootstrap execution of the control program is performed using the hypervisor, the hypervisor providing control program access to a hardware platform of the data processing unit, so that the control program detects units of the hardware platform and loads appropriate unit drivers into a unit driver stack of the control program. [11] Computer program product according to Annex 10ch 11, wherein the control program is either an operating system, another hypervisor or another virtual machine manager. [12] Computer program product according to claim 10, wherein the computer-readable program further causes the data processing unit to: during the hypervisor ownership phase of the bare-metal boot process. through the hypervisor, firmware calls from the control program that are directed to the firmware of the data processing unit; and Firmware calls are made by the hypervisor using emulated firmware services provided by the hypervisor. [13] Computer program product according to claim 12, wherein the interception of firmware calls comprises redirecting firmware calls to the emulated firmware services of the hypervisor using logic of a firmware mapping function that maps the firmware calls to a corresponding emulated firmware service of the hypervisor for processing the firmware call. [14] Computer program product according to claim 12, wherein operating the firmware calls using the emulated firmware services comprises using a unit driver stack of the hypervisor to perform operations on a hardware platform of the data processing unit to operate the firmware calls. [15] Computer program product according to claim 12, wherein the computer-readable program further causes the data processing unit to boot from the hypervisor ownership phase of the bare-metal boot process by: Interrupting the interception of firmware calls from the control program by the hypervisor; Reconfiguring hardware resources of the hardware platform for direct use by the control program; and reducing the hypervisor to a bare-bones hypervisor that provides logic to handle a subset of calls to the firmware application programming interface at runtime. [16] Computer program product according to claim 10, wherein the computer-readable program further causes the data processing unit to be booted from the transition phase into a control program ownership phase by activating the control program to directly perform operations with the hardware platform of the data processing unit using the unit driver stack of the control program. [17] Computer program product according to claim 10, wherein the computer-readable program further causes the data processing unit to: boots the hypervisor into a bootloader operating mode in which, in response to a request regarding the bare-metal boot of the control program, the hypervisor performs the bare-metal boot process by booting the data processing unit through the hypervisor ownership phase, transition phase, and control program ownership phase. [18] Computer program product according to claim 17, wherein booting the hypervisor into the bootloader mode comprises dynamically transitioning the hypervisor into the bootloader mode after the hypervisor is already running on the data processing unit, or performing a fixed boot operation of the hypervisor into the bootloader mode, in which the hypervisor is initially running in the bootloader mode on the data processing unit. [19] Data processing system comprising: a processor; and a memory connected to the processor, wherein the memory contains instructions which, when executed by the processor, cause the processor to: the data processing unit boots into a hypervisor ownership phase of the bare-metal boot process, whereby during the hypervisor ownership phase of the bare-metal boot process a hypervisor is loaded and controls and manages platform hardware in the data processing unit; the data processing unit boots from the hypervisor ownership phase of the bare-metal boot process into a transition phase of the bare-metal boot process, in which the hypervisor releases control and management of the data processing unit's platform hardware to the control program; and The data processing unit boots from the transition phase into a control program ownership phase of the bare-metal boot process, in which the control program has full control and manages the platform hardware, with the bare-metal boot process being performed without restarting the data processing unit. wherein during the hypervisor ownership phase of the bare-metal boot process, a bootstrap execution of the control program is performed using the hypervisor, the hypervisor providing control program access to a hardware platform of the data processing unit, so that the control program discovers units of the hardware platform and loads the corresponding unit drivers into a unit driver stack of the control program. [20] Data processing unit according to claim 19, wherein the control program is either an operating system, another hypervisor or another virtual machine manager. [21] Data processing unit according to claim 19, wherein the instructions during the hypervisor ownership phase of the bare-metal boot process further cause the data processing unit to: through the hypervisor, firmware calls from the control program that are directed to the firmware of the data processing unit; and Firmware calls are made by the hypervisor using emulated firmware services provided by the hypervisor. [22] Data processing unit according to claim 21, wherein the interception of firmware calls comprises redirecting firmware calls to the emulated firmware services of the hypervisor using logic of a firmware mapping function that maps the firmware calls to a corresponding emulated firmware service of the hypervisor for processing the firmware call.

Images