System and method for the logical substitution of processor control in an emulated computing environment

ES 2 336 892 T3

DESCRIPTION

Logical replacement of processor control in an emulated computing environment.

The present invention relates, in general, to the field of computer system emulation and, more particularly, to a method for transparently decoupling the host operating system from the computer system processor in favor of control by the processor by part of the guest operating system.

Computers include general-purpose central processing units (CPUs) that are designed to execute a specific set of system instructions. A group of processors that have similar architectural or design specifications can be considered members of the same processor family. Examples of current processor families include the Motorola 680X0 family of processors, manufactured by Motorola, Inc. of Phoenix, Arizona, USA. USA; the Intel 80X86 family of processors, manufactured by Intel Corporation of Sunnyvale, California, USA; and the PowerPC family of processors, manufactured by Motorola, Inc. and used in computers manufactured by Apple Computer, Inc. of Cupertino, California, USA. Although a group of processors may be in the same family due to similar architectural and design considerations, processors can vary widely within a family based on their clock speed and other performance parameters.

Each family of microprocessors executes instructions that are unique to the family of processors. The collective set of instructions that a processor or family of processors can execute is known as the processor's instruction set. As an example, the instruction set used by the Intel 80X86 processor family is incompatible with the instruction set used by the PowerPC processor family. The Intel 80X86 instruction set is based on the Complex Instruction Group Computer (CISC) format. The Motorola PowerPC instruction set is based on the Small Instruction Set Computer (RISC) format. CISC processors use a large number of instructions, some of which can carry out quite complicated functions, but which generally require many clock cycles to execute. RISC processors use fewer available instructions to carry out a simpler set of functions that are executed at a much higher speed.

Typically, the uniqueness of the processor family between computer systems also results in incompatibility between the other elements of the hardware architecture of computer systems. A computer system built with an Intel 80X86 processor family will have a hardware architecture that is different from the hardware architecture of a computer system built with a PowerPC processor family processor. Due to the uniqueness of the processor instruction set and the hardware architecture of a computer system, application computer programs are written to run on a particular computer system running a particular operating system.

A computer manufacturer will want to maximize its market share by having more rather than fewer applications running on the family of microprocessors associated with the computer manufacturer's production line. To expand the number of operating systems and application programs that can run on a computer system, a field of technology has been developed in which a given computer having one type of CPU, called a host, ("HOST") will include a host. An emulator program that allows the host computer to emulate instructions from an unrelated type of CPU, called a guest (“GUEST”). Thus, the host computer will run an application that will cause one or more host instructions to be called in response to a given guest instruction. Thus, the host computer can run both software designed for its own hardware architecture and software written for computers having an unrelated hardware architecture. As a more specific example, a computer system manufactured by Apple Computer, for example, may run operating systems and programs written for PC-based computer systems. It may be possible to use an emulator program to run multiple incompatible operating systems concurrently on a single CPU. In this arrangement, although each operating system is incompatible with the other, an emulator program can host one of the two operating systems, allowing the otherwise incompatible operating system to run concurrently on the same computer system.

When a host computer system is emulated on a host computer system, the guest computer system is said to be a virtual machine, since the host computer system only exists as a software representation of the operation of the hardware architecture of the host computer system. The terms emulator and virtual machine are sometimes used interchangeably to denote the ability to mimic or emulate the hardware architecture of a complete computer system. As an example, Virtual PC software created by Connectix Corporation of San Mateo, California, USA emulates a complete computer that includes an Intel 80X86 Pentium processor and various motherboard and card components. The operation of these components is emulated in the virtual machine that is running on the host machine. An emulator program that is running on the hardware and software architecture of the host computer's operating system, such as a computer system that has a PowerPC processor, mimics the operation of the entire host computer system. The emulator program acts as the exchange between the hardware architecture of the host machine and the instructions transmitted by the software running in the emulated environment.

ES 2 336 892 T3

A hypervisor is a control program that exists near the kernel level of a host operating system and that functions to allow one or more secondary operating systems, other than the host operating system, to use the computer system hardware, including the system processor. computer scientist. A hypervisor of an operating system emulates the operating environment of the secondary operating system, so that the secondary operating system believes that it is running in its normal hardware and / or operating system environment and that it has logical control of the computer system, when it can be actually operating in other hardware and / or operating system environment and the host operating system may have logical control of the computer system. Many operating systems work in such a way that the operating system must function as if it had exclusive logical control of the computer system hardware. For multiple operating systems to run simultaneously on a single computer system, the hypervisor for each operating system must function to mask the presence of the other operating systems, so that each operating system functions as if it had exclusive control of the entire computer system .

If it is desired to emulate the full hardware architecture of the guest system, it is often useful or desirable to make maximum use of the hardware in the host computer system, including, for example, the memory management unit, the context switching hardware, the exception handling vectors, the pointers to the interrupt routines, and the floating point units of the host processor, and the memory of the host computer system. However, this hardware is typically under the control of the host operating system and is protected from access at the user level or by application software. An exception is a case that occurs in the computer system that cannot be resolved by the processor. An interrupt is a request sent to the processor to temporarily interrupt the current stream of instructions to carry out some other operation.

One option to avoid this difficulty is to use an emulation program that does not attempt to use the low-level hardware of the host computer system. This type of approach is often used in the case of an emulation program that resides as an application program and runs on the host computer system. Of course, these emulation application programs are subject to the performance penalties of being an application program running on the host operating system of a host computer system. Also, these emulation application programs only gain access to hardware features that are exposed to the emulation application program by the host operating system. As an example, an emulation program that runs as an application on the host operating system may include an exception handler. The difficulty is that the exception handler of the emulation program is separated from the host computer system's processor by several layers of software, which create a latency between the moment the host processor throws an exception and the moment it is identified. the exception to the exception handler of the emulation program. Another option is for the emulation program to share hardware with the host operating system, assuming that support for sharing an operating system by an emulation program can be written on the host operating system's hypervisor.

Another difficulty of using a hypervisor in an emulated computing environment is managing the memory space of the emulated computer system along with the memory space of the hypervisor itself. To improve the performance of the emulated computer system, the hypervisor will typically seek to manipulate the page tables of the host computer system so that the page tables of the host computer system largely mirror the page tables of the guest operating system. One difficulty with this approach is that the hypervisor code and its associated data are not mapped in the guest operating system page tables. This is necessarily the case, since the emulated computer system is not aware that a hypervisor is running the system on the hardware of the host computer system. As such, the hypervisor page table does not fully match the host computer system page table. The hypervisor page table includes mapping the code and data from the hypervisor itself.

The mirroring of the guest OS page tables by the hypervisor raises the possibility that the guest OS address mapping will conflict with the hypervisor address mapping as the guest OS address mapping can include mapping of addresses in the hypervisor's own data and code mapped locations. One solution to this problem of conflicting page mappings is to alter the guest operating system page table when mapping the guest operating system logical memory conflicts with the mapping dictated by the nearly identical page table of the guest operating system. hypervisor. However, altering the page table of the emulated computer system is undesirable because it would introduce an unexpected change to the emulated computer system to its page tables, possibly introducing other incompatibilities or glitches in the guest operating system.

DE 42 17 444 A describes a system of a virtual machine having a plurality of virtual machines, in which each virtual machine can be relocated to a new main storage area without interfering with any other virtual machines. Relocation is accomplished by move instructions issued by a service processor upon receipt of a relocate instruction. These instructions pass control to a control section that instructs a logical instruction processor that controls the section to temporarily stop the logical instruction processor of the particular virtual machine. This is followed by a check using the resource management section to determine if the virtual machine can be moved. Once it has been verified, the virtual machine is relocated to the main storage area according to an address designated by the relocate instruction and the control section restores the operation of the virtual machine.

ES 2 336 892 T3

FR-A-2587519 deals with a virtual machine system in which a mode switch arrangement is used to change the operating mode of the system. A mode memory is used to store data to indicate one of three different modes, namely a non-virtual machine mode, a virtual machine monitoring mode, or a virtual machine operating system mode. An instruction register provides an instruction to select one of the data so that it is then loaded into a mode register so as to operate the virtual machine system in the mode indicated by the mode data stored in the mode register. mode.

It is an object of the present invention to provide a method for an emulator to logically decouple a host operating system from a host computer system from the host computer system processor.

The objective is solved by the content of the independent claim. Preferred embodiments of the present invention are defined by the dependent claims.

The present invention relates to a technique for logically decoupling a host operating system from a computer system processor. In accordance with the method of the present invention, a hypervisor of an emulator program read in a set of processor settings of the processor. These processor settings are stored by the hypervisor in main memory. The hypervisor replaces these processor configurations with a set of processor configurations associated with software routines or data structures provided by the guest operating system. These software routines or data structures can include interrupt and exception handling routines and page tables. As a result of the replacement of the processor configurations, the host operating system is decoupled from the processor control in the sense that at least some of the processor processor configurations are associated with the software routines or data structures provided by the guest operating system, and are no longer associated with the software routines or data structures provided by the host operating system. To reattach the host operating system to the processor, the hypervisor reads the saved processor settings from memory and writes these processor settings to the appropriate processor registers.

During the period that the hypervisor is coupled to the processor, the hypervisor page table largely mirrors the guest operating system page table, the main difference being that the hypervisor page table includes the mapped locations of the hypervisor's own code . To avoid conflicts between the guest OS page tables and the hypervisor page tables, the hypervisor page table is reallocated if a change to the guest OS page table results in the mapped location in memory in the guest operating system it overlaps with the mapped location of the hypervisor code and the hypervisor page table.

The undocking and redocking procedure disclosed herein is advantageous in that it allows the guest operating system to be more closely aligned with the processor for some functionality that can be provided by the guest operating system. In this way, calls to the exception handler, calls to the interrupt handler, and calls to memory management do not need to be passed from the processor to the host operating system before they are passed to the guest operating system. Rather, these processor calls are passed directly to the guest operating system via the emulation program's hypervisor.

The method disclosed herein is also advantageous in that the hypervisor or the decoupling tool from the emulation program does not have to have access to the source code of the host operating system. Rather, the hypervisor decouples the host operating system from the processor in a way that is transparent to the host operating system, which is unaware that it has been decoupled or reattached to the processor.

The method disclosed herein is advantageous also in the sense that if the host operating system is decoupled from the processor with respect to some functionality normally provided by the host operating system, the host operating system remains coupled to the host processor during the process. rest of the host processor functionality. During this period, the host operating system continues to manage much of the hardware functionality of the computer system, allowing the guest operating system to route a print request through the host operating system.

An advantage of remapping the hypervisor page table in the event of a conflict with the guest computer system is that page table remapping allows the hypervisor page table to be a copy of the guest operating system page table, while, at the same time, the code of the hypervisor itself is correlated. In this environment, changes to the guest operating system page table do not result in a conflict between the guest operating system and hypervisor page tables. Additionally, the hypervisor page table remapping is transparent to the guest operating system, avoiding the possibility of creating system-level conflicts in the guest operating system.

Other technical advantages of the present invention will be very apparent to one of ordinary skill in the art from the following figures, descriptions, and claims.

ES 2 336 892 T3

Brief description of the drawings

A more complete understanding of the present invention and the advantages thereof can be achieved by referring to the following description taken in conjunction with the accompanying drawings, in which like reference numerals indicate similar characteristics, and in which:

Figure 1 is a diagram of the logical relationship of the elements of an emulated computer system running on a host computer system;

Figure 2 is a flow chart of the procedure for logically coupling a hypervisor of an emulation program to the processor of the computer system;

Figure 3 is a diagram of a logical relationship of the elements of an emulated computer system in which a hypervisor is logically coupled to the processor of the computer system; and Figure 4 is a flow chart of a procedure for mapping the page tables of a guest operating system.

Detailed description of the invention

The present invention provides an emulation environment that enables access by emulation software to lower-level hardware components of the host computer system. The invention involves an emulation program that includes a hypervisor that is transparent to the host operating system. The emulation program's hypervisor logically disconnects or decouples the operating system from a dedicated control of the host computer system for brief periods, during which time the emulation program's hypervisor is placed in control of the host computer's hardware, allowing it to the emulation program is logically close, for short periods, to certain hardware characteristics of the host computer system.

The processor processor state is a dynamic copy of all processor settings at a single point in time. These settings include both data that the processor is manipulating and the counters, pointers, and other program operational indicators used by the processor. Because the data that is being manipulated by the processor and many other processor configurations can change with each processor cycle, the state of the processor can change with each processor cycle as well, and can change as often as many millions of times. per second.

A subset of the processor state is the user state. Taken together, the data that is being manipulated by the processor and the processor's program counter comprise the user state of the processor. The state of the user is so named because the values ​​that comprise the state of the user can be manipulated by an application-level program. The rest of the processor state settings of the processor comprise the supervisory state or the privileged state of the processor. Supervisor status values ​​can only be changed by software that is part of the computer system's operating system. The Supervisor State or Privileged State settings of the processor state cannot be accessed through an application-level program. The separation of the processor settings between a user state, which can be accessed by application-level programs, and a supervisory state, which cannot be accessed by application-level programs, allows the operating system remains functional even if the application-level program dies or causes a fatal error.

In general, processor supervisory state settings fall into one of several categories. One category of processor supervisory status is processor mode flags, which include settings that instruct the processor to operate in one of several modes to support certain computational situations, exception behavior, program support backward compatibility, or other selective use of newer processor features. Another category of processor health settings are settings that control external hardware access. Processors often support various operational configurations for communication between the processor and hardware external to the processor, such as caches, memory, and other input and output devices. Because these operating settings, including communication speed and bandwidth, for example, can only be modified by code at the privileged or supervisor level, they are considered part of the processor's supervisory state.

Another category of processor privileged state settings are exceptions and pointers to interrupt routines. When the processor encounters an exception or an interrupt is requested, the processor stops execution at the current program counter address and begins execution at a predetermined exception routine address. The locations of these exception routines are identified through the use of pointers to exception routines. For some processors, the exception routines are located in hard-coded memory addresses. However, in most processors their locations are programmable and the values ​​of these locations are considered part of the processor's supervisory state.

ES 2 336 892 T3

A set of pointers to data structures forms another category of the processor's privileged state. Because some processor state data structures are too large to be stored in the processor, these data structures are stored in main memory and a pointer to the data structure is stored in the processor. An example of this type of large data structure is processor page tables. These tables define for the processor the logical-to-physical conversion of memory addresses that are required for the conversion of virtual memory accesses to physical memory locations. Both the page table and the pointer to the page table, which is stored in the processor, are considered part of the processor's supervisory state. Another example of a processor monitor state data structure that is stored in main memory is a table of pointers to exception routines. Instead of storing the pointer for each exception routine in the processor, a single pointer stored in the processor can point to a table of pointers to exception routines. The pointer to the exception or vector table will include a list of pointers to addresses to the exception handlers that the processor will be able to access. Both the pointer to the exception routine that is stored in the processor and the table of pointers to exception routines are considered part of the monitor state.

Typically, the host operating system sets the vectors or pointers to the interrupt handler routines and exceptions for the processor. For example, if the processor is instructed to process a set of instructions that will cause the processor to divide by zero, the processor will call the exception handler routine that handles the divide by zero exception. By doing so, the processor can call an exception handler routine that is pointed to by a vector stored in the processor. Alternatively, the processor can examine the exception vector table for the correct exception handler for the exception condition and then call the exception handler using the exception vector or pointer associated with the applicable exception handler.

When the host operating system has logical control of the host processor, the host operating system defines for the host processor the exception vectors and all other vectors that will be needed by, and supported by, the host processor. If the processor encounters an exception condition or needs to access another routine that is referenced by a vector, such as page table routines and page table vector, the processor executes the host operating system's exception handler.

In the case of an emulated computer system, an emulation program provides an emulated operating environment on the host computer system. Figure 1 shows a diagram of the logical layers of the hardware and software architecture for an emulated operating environment on a computer system 10. An emulation program 14 runs on a host operating system running on the hardware or on the host computer system processor 11. The emulation program 14 emulates a host computer system 16, including a guest operating system 18. The guest application programs are capable of running on the guest operating system 18. In the emulated operating environment of Figure 1, due to the operation of the emulation program 14, the guest application 20 can run on the computer system 10 even though the guest application 20 is designed to run on an operating system that is generally incompatible with the computer system. host operating system 12 and host computer system hardware 11. In the architecture of Figure 1, the guest operating system 18 is separated from the hardware 11 of the host computer system into several logical and software layers, including the host operating system 12. This logical separation introduces latency and performance difficulties in those cases where those in which the guest operating system tries to communicate directly with the hardware 11 of the host computer system.

In the example of Figure 1, the host operating system 12 has exclusive operational control of the host computer system hardware 11, including the host computer system processor. The host operating system will have set a number of the processor state settings for the host computer system's processor. For example, host operating system 12 may have a set of exception handler vectors established, either located in a vector table or host processor registers, a set of interrupt handlers, and a vector from the interrupt table. pages. Thus, when the processor makes calls to the exception handler, calls to the interrupt handler, or calls to memory management, the processor settings for these calls are provided exclusively by the host operating system. Because the host operating system established the processor's supervisory or privileged state settings, the host operating system is said to have logical control of the host computer system's processor.

In accordance with the emulation technique of the present invention, the emulation program itself includes a hypervisor that is capable of logically disconnecting or decoupling the host operating system from exclusive control of the processor and other hardware 11 of the host computer system. The hypervisor of the emulation program 14 accomplishes the logical disconnect step by reading in and saving to a memory location the vectors and other pointers to addresses that are used by the host processor. Figure 2 shows a flow chart of the steps taken by the hypervisor to logically disconnect the host operating system from exclusive control of the host computer system and to logically connect or couple the hypervisor from the emulation program to the computer system. host. When the hypervisor of the emulation program wants to exert control over at least some of the processor settings of the processor, the hypervisor read in, in step 24, some or all of the settings of the supervisory or privileged state of the processor . According to an embodiment of the invention, the processor reads in the pointers to addresses of the applicable registers of the processor, including the exception vectors or the pointer to the table of exception vectors, the pointers

ES 2 336 892 T3 to interrupts or the pointer to the interrupt routine table, and the pointer to the page table. In step 26, the hypervisor saves these processor settings, along with an identification of their associated storage location on the host processor, in memory. The hypervisor then overrides, in step 28, the user-level processor state of the guest operating system and the privileged-level hypervisor state of the emulation program. As a result, the host processor processor settings are overridden with a combination of the user-level processor state of the guest operating system and the privileged-level state associated with the emulation program hypervisor. In doing so, the hypervisor stores the vectors and other address pointers to the exception handlers, interrupt routines, and hypervisor page maps of the emulation program and the guest operating system in the appropriate processor registers.

Because the processor settings superseded by the emulation program hypervisor are supervisor or privileged level settings, the emulation program hypervisor has logical control of the processor for all superseded processor configurations. In this way, the emulated computer system has logical control of the hardware functionality of the host computer system for the functionality governed by the superseded configurations of the processor. A diagram of the logical relationship of the emulation program 14 after replacement of the processor configurations is shown in Figure 3. In Figure 3 the hypervisor 22 is shown as a component of the emulation program 14, shown as having a logical communication link with the processor and host hardware 11.

As an example of the logic control of the host hardware emulation program 11, if an exception occurred during this period, the processor would call an exception handler provided by the emulation program's hypervisor. Similarly, if the processor is called to convert a virtual memory address to a physical memory address, the processor will access the page table associated with the guest operating system. Thus, many configurations of processor states have been replaced, such that the processor is calling or accessing software or data structures provided directly by the guest operating system. This allows the guest operating system to logically align itself more closely with the computer system processor, and eliminates the latency caused by separating the guest operating system from the computer system processor in the host operating system. In the case of an exception, the exception handler in the hypervisor can handle the exception itself or the exception handler in the hypervisor can invoke the exception handler of the guest operating system, allowing the guest operating system to directly handle the exception without the need the exception call goes through the software layer of the host operating system.

As shown in Figure 3, the host operating system 12 is not permanently disconnected from the hardware of the host computer system. The logical control exerted by the hypervisor over a set of processor configurations does not result in the hypervisor 22 assuming responsibility for all hardware interaction in the computing system. During those periods when the host operating system is handling a feature request related to the hardware of the computer system, the host operating system must have logical control of the computer system. To accomplish this, the host operating system must be temporarily logically re-coupled to the hardware of the computer system. After the host operating system has completed the functions requested by the emulation program, the emulation program can regain logical control over the exception and interrupt handlers associated with the emulation program's processor configuration.

Referring to the flow chart of Figure 2, in step 30, the hypervisor 22 returns logical control over the processor settings to the host operating system. The hypervisor 22 retrieves from memory the vectors and other pointers that were stored in memory. These addresses are written back to the appropriate registry locations, returning logical control over these processor settings to the host operating system. During the period that the host operating system is logically disconnected from the processor, for the host operating system 12 the logical disconnection of the host operating system 12 is not evident. The host operating system 12 is not aware that an assembly has been replaced of processor settings, which results in the transfer of logical control of some hardware functionality to the emulation program. When logic control is returned to host operating system 12, similarly, host operating system 12 is not aware that logical control of a set of hardware calls has been returned to it.

Replacing some processor settings from the processor supervisory state results in higher performance of the emulation program compared to the option of program management of exceptions, interrupts, and memory management such as as they are filtered through the host operating system. In those cases where the emulation program functions as an application program residing on the host operating system, logically disengaging the host operating system from exclusive control over processor functionality is a performance advantage of the computer system. emulated. Once the host operating system has been logically decoupled from at least some of the processor functionality, the emulation program, by substituting its processor settings for the host operating system's processor settings, can work much more closely with the host operating system. host processor. Once the processor settings have been replaced, the emulation program can direct the processor to the entire program itself for emulating exception vectors, interrupt routines, and page tables, thereby avoiding latency problems caused when the Host operating system separates the processor from the emulation program.

ES 2 336 892 T3

The hypervisor functions of the present invention for interrupt and exception handling also allow for the handling of exceptions and interrupts by the guest operating system, as you would expect. An operating system can choose to handle certain exceptions at the operating system level without passing these exceptions to the application that raised the exception. An example is the divide by zero exception, which is often handled by the operating system without being passed to the application program that raised the exception. The emulation program's hypervisor can continue to pass exceptions to the guest operating system without the need to start an exception handler on the hypervisor. Thus, unsurprisingly, when a guest application program raises a divide-by-zero exception at a time when the emulation program has logical control of the processor with respect to the superseded processor configurations, the hypervisor of the emulation program is capable of passing the exception to the guest operating system.

Figure 4 shows a flow chart of a procedure for mapping the page tables of a guest operating system. In step 40, the hypervisor identifies a write to the guest operating system page table. In step 42, the hypervisor determines whether writing to the guest operating system page table resulted in a mapping conflict between the guest operating system page tables and the hypervisor page table. The hypervisor page table closely mirrors the guest operating system page table, the main difference being that the hypervisor page table maps hypervisor code and data into its page table. The hypervisor determines that there is a conflict, for example, if the mapped pages in the guest operating system page table overlap with the mapped hypervisor locations in the hypervisor page tables.

If the hypervisor determines that there will be no conflict caused by the change to the guest operating system page tables, then no change to the hypervisor page tables is necessary (step 44). If the hypervisor determines that a change to the guest operating system's page table causes a conflict with the host computer's page table, the hypervisor reallocates its page table in step 46 so that the page table is moved or mapped. code and data from the hypervisor itself in another location in the hypervisor's page table. This procedure of identifying a change to the guest operating system page table and, if necessary, re-mapping in response of the hypervisor page table is transparent to the operation of the guest operating system. After the hypervisor page table has been reallocated, if necessary, the guest operating system page table no longer conflicts with the hypervisor page table.

The present invention is not limited in its application to the emulation of a particular computer system architecture, in particular the Intel 80X86 architecture. Rather, the emulation technique disclosed herein can be applied whenever it is desirable for a host operating system to be transparently disconnected from the processor with respect to at least some of the processor's processor configurations.

Although the present invention has been described in detail, it will be understood that various changes, substitutions and alterations can be made without departing from the scope of the invention as defined in the appended claims.