WO2016014017A1

WO2016014017A1 - Operating system device access using a virtual machine

Info

Publication number: WO2016014017A1
Application number: PCT/US2014/047393
Authority: WO
Inventors: Richard A. Bramley Jr.; Thong Thai
Original assignee: Hewlett-Packard Development Company, L.P.
Priority date: 2014-07-21
Filing date: 2014-07-21
Publication date: 2016-01-28

Abstract

In one example, a driver copied from BIOS firmware is executed in a virtual machine responsive to a determination that an operating system requires access to a hardware device associated with the driver. The operating system accesses the hardware device via the copied driver copy executing in the virtual machine.

Description

OPERATING SYSTEM DEVICE ACCESS USING A VIRTUAL MACHINE

BACKGROUND

[0001] Computer operating systems generally access hardware via drivers. Drivers are instructions executed by a computer to provide access to a hardware device, such as a peripheral. For example, an operating system may access a computer's display hardware, audio hardware, disk hardware, user interface hardware, etc. via a driver designed to provide a specific operating system access to specific hardware features. As computer hardware and/or operating systems change, new drivers must be developed to support operating system access to the hardware.

BRIEF DESCRIPTION OF THE DRAWINGS

[0002] For a detailed description of various examples, reference will now be made to the accompanying drawings in which:

[0003] Figures 1 and 2 show block diagrams for systems for accessing computer hardware in accordance with various examples;

[0004] Figure 3 shows a diagram of computer hardware device access in accordance with various examples; and

[0005] Figures 4 and 5 show flow diagrams for methods for accessing computer hardware in accordance with various examples.

DETAILED DESCRIPTION

[0006] Certain terms are used throughout the following description and claims to refer to particular system components. As one skilled in the art will appreciate, different companies may refer to a component by different names. This document does not intend to distinguish between components that differ in name but not function. In the following discussion and in the claims, the terms "including" and "comprising" are used in an open-ended fashion, and thus should be interpreted to mean "including, but not limited to... ." Also, the term "couple" or "couples" is intended to mean either an indirect or direct wired or wireless connection. Thus, if a first device couples to a second device, that connection may be through a direct connection or through an indirect connection via other devices and connections. Further, the term "software" includes any executable instructions capable of running on a processor, regardless of the media used to store the software. Thus, instructions stored in memory (e.g., non-volatile memory), and sometimes referred to as "embedded firmware," is included within the definition of software. The recitation "based on" is intended to mean "based at least in part on." Therefore, if X is based on Y, X may be based on Y and any number of other factors.

[0007] While operating systems generally access computer hardware via drivers tailored to accommodate the operating system and hardware, in some situations, the information needed to develop drivers for a particular operating system may be unavailable. For example, hardware developers may have little incentive to provide the detailed information needed for driver development for use with operating systems having a relatively low level of use, such as LINUX. In other cases, the hardware developers may intend to thwart reverse engineering of the hardware by restricting access to drivers. Consequently, developing drivers for some operating systems may by inordinately difficult. Further, as an operating system is revised, existing drivers may require modification to interface with the operating system.

[0008] The hardware access system disclosed herein enables use of the drivers provided in the BIOS corresponding to given computer hardware to alleviate the difficulties associated with developing and maintaining operating system specific drivers for each hardware device. Implementations maintain a copy of driver code read from the BIOS after system initialization, and execute the copied driver code in a virtual machine to initialize the hardware and driver parameters when access to a hardware feature is requested by the operating system. In this manner, implementations advantageously provide access to hardware features when drivers specific to the operating system and hardware are not available.

[0009] Figures 1 and 2 show block diagrams for systems for accessing computer hardware in accordance with various examples. As shown in Figure 1 , the system 100 includes a processor 102, a computer hardware device 106, BIOS firmware 104, a first operating system 1 10, operating system control logic 1 12, and a driver copy 1 14. The processor 102 may be a general-purpose microprocessor, a digital signal processor, a microcontroller, or other device capable of executing instructions retrieved from a computer-readable storage medium. Processor architectures generally include execution units (e.g., fixed point, floating point, integer, etc.), storage (e.g., registers, memory, etc.), instruction decoding, instruction and data fetching logic, peripherals (e.g., interrupt controllers, timers, direct memory access controllers, etc.), input/output systems (e.g., serial ports, parallel ports, etc.) and various other components and sub-systems.

[0010] The computer hardware device 106 is coupled to the processor 102. The computer hardware device 102 may be a peripheral or other hardware subsystem included in a computing device. As shown in Figure 2, the hardware device 102 may be graphics subsystem 210 for generating images on a display device, a disk subsystem 212 for accessing a disk or other secondary storage device, an audio subsystem for sound generation, a user interface subsystem for accessing user interfaces devices, or other hardware device accessible by the processor 102 via a driver.

[0011] The BIOS firmware 104 is a set of instructions stored in non-volatile storage 208. The non-volatile storage 208 may include one or more non-volatile storage devices, such as FLASH storage devices, read-only-memory storage devices, etc. The BIOS firmware 104 is executed by the processor 102 to initialize the system 100 at start-up (i.e., system 100 power up or boot), and to pass control of the system 100 to higher lever instructions, such as an operating system. The BIOS 104 may be compatible with unified extensible firmware interface (UEFI) standards. The BIOS firmware 104 includes a driver that is executable by the processor 102 to access the hardware device 106. In conventional systems, the drivers of the BIOS firmware 104 are not used after control is passed from the BIOS to higher level logic that accesses the hardware device 106 via different drivers that are specific to the higher level logic.

[0012] The first operating system 1 10 is a set of instructions executable by the processor 102 to provide supervisory functionality for execution of application programs by the processor 102. Application programs executing under the control of the first operating system 1 10 access the hardware device 106 via the first operating system 1 10. The first operating system 1 10 may be a LINUX operating system that lacks drivers for interfacing the first operating system 1 10 to the hardware device 106.

[0013] The operating system control logic 1 12 is a set of instructions that controls the execution of the first operating system 1 10 and other programming executed by the processor 102. The operating system control logic 1 12 may be a hypervisor that provides a virtual machine environment in which the first operating system 1 10 and other programs execute.

[0014] In the system 100, the BIOS firmware 104 is executed by the processor 102 to initialize the system, and thereafter control may be passed to the operating system control logic 1 12. The operating system control logic 1 12, a boot loader 218 that initiates the operating system control logic, or other control logic included in the system 100 accesses the BIOS firmware 104 and copies a portion of the BIOS firmware 104 that includes a driver for accessing and operating the hardware device 106. The driver copy 1 14 retrieved from the BIOS firmware 104 is stored in the storage 108. The storage 108 is a non-transitory computer- readable storage medium suitable for storing instructions that are retrieved and executed by the processor 102 to perform the functions disclosed herein. The storage 108 may include volatile storage such as random access memory, nonvolatile storage (e.g., a hard drive, an optical storage device (e.g., CD or DVD), FLASH storage, read-only-memory), or combinations thereof.

[0015] Processors execute software instructions. Software instructions alone are incapable of performing a function. Therefore, in the present disclosure, any reference to a function performed by software instructions, or to software instructions performing a function is simply a shorthand means for stating that the function is performed by the processor 102 executing the instructions.

[0016] The operating system control logic 1 12 includes hardware access control logic 206 and virtual machine (VM) control logic 204. The virtual machine control logic 204 allows the operating system control logic 1 12 to create and manage virtual machines. For example, the VM control logic 204 may create a virtual machine for execution of the first operating system 1 10.

[0017] The hardware access control logic 206 includes instructions executable by the processor 102 that allow the first operating system 1 10 to access the hardware device 106 via the driver copy 1 14. The hardware access control logic 206 determines whether the first operating system 1 10 needs access to the hardware device 106. For example, the hardware access control logic 206 may determine that the first operating system 1 10 needs access to the hardware device 106 based on a request to access the hardware device 106 by the first operating system 1 10. If the first operating system needs to access the hardware device 106, then the hardware access control logic 206 instantiates a virtual machine (e.g., via the VM control logic 204). The hardware access control logic 206 executes the driver copy 1 14 in the virtual machine. Execution of the driver copy 1 14 in the virtual machine initializes the hardware device 106 (i.e., sets the hardware device 106 to a known state as from start-up of the system 100) and sets the parameters of driver copy 1 14 to a known or initial state. After initialization of the hardware device 106, the first operating system 1 10 and/or an application program executed in conjunction with the first operating system 1 10, accesses the hardware device 106 via the driver copy 1 14 that is executing in the virtual machine. When the first operating system 1 10 has completed access of the hardware device 106, the hardware access control logic 206 terminates the virtual machine in which the driver copy 1 14 is executing.

[0018] The hardware access control logic 206 may also provide a driver interface component (i.e., a sub-driver) through which the first operating system accesses the driver copy 1 14 executing in the virtual machine (i.e., the driver interface component connects the first operating system 1 10 to the driver copy 1 14 executing in the VM). The driver interface component may retrieve information from the driver copy 1 14 (e.g., display resolution, number and size of secondary storage devices, etc.) and provide the information to the first operating system 1 10. The driver interface component may call the driver copy 1 14 to perform operations (e.g., display operations, storage device read/write operations, etc.) in the hardware device 106. Translations may be applied to addresses of information passed to/from the driver copy 1 14 executing in the virtual machine because memory addresses used in the virtual machine may be different than those used by the first operating system 1 10. [0019] The storage 108 may also include a second operating system 202. The second operating system 202 may be executed by the operating system control logic 1 12 in a virtual machine. The second operating system 202 may be, for example, a WINDOWS operating system, and include a driver tailored to allow the second operating system 202 to access the hardware device 106. Accordingly, the second operating system 202 does not access the hardware device 106 via the driver copy 1 14. Access of the hardware device 106 by the second operating system 202 sets the hardware device 106 to an unknown state with respect to the first operating system. Consequently, the first operating system 1 10 cannot access the hardware device 106 unless the hardware device106 is set to a known state by execution of the driver copy 1 14 in a virtual machine.

[0020] Some implementations of the system 100 may be embodied in a computer as is known in the art. For example, the processor 102, storage 108, and hardware device 106 may be provided by a desktop computer, a rack-mount computer, a server computer, or other computer suitable for storing and executing instructions that provide the functionality described herein when executed.

[0021] Figure 3 shows a diagram of computer hardware device 106 access in accordance with various examples. The second operating system 202 accesses the hardware device 106 via the driver 304. The driver 304 is tailored to interface the second operating system 202 to the hardware device 106. The first operating system 1 10 lacks a driver specifically tailored to allow the first operating system 1 10 to access the hardware device 106. The first operating system 1 10 accesses the hardware device 106 via a portion of the BIOS firmware 104 (i.e., the driver copy 1 14) copied by the operating system control logic 1 12 after the BIOS firmware 104 passes control of the system 100 to the operating system control logic 1 12. The operating system control logic 1 12 executes the driver copy 1 14, copied from the BIOS firmware 104, in a virtual machine 302 responsive to the first operating system 1 10 requesting access to the hardware device 106. The driver copy 1 14 sets the hardware device 106, and parameters associated with the hardware device 106 to a known state. When the driver copy 1 14 has completed initialization of the hardware device 106, the virtual machine 302 passes the parameters and hardware state information associated with the hardware device 106 and the driver copy 1 14 to the operating system control logic 1 12. After the driver copy 1 14 is executing in the virtual machine 302, the first operating system 1 10 accesses the hardware device 106 via the driver copy 1 14.

[0022] Figures 4 and 5 show flow diagrams for methods for accessing computer hardware in accordance with various examples. Though depicted sequentially as a matter of convenience, at least some of the actions shown can be performed in a different order and/or performed in parallel. Additionally, some implementations may perform only some of the actions shown. In some implementations, at least some of the operations of the methods 400 and 500, as well as other operations described herein, can be implemented as instructions stored in the storage 108 and executed by the processor 102.

[0023] In block 402, the system 100 is booting. The processor 102 executes the BIOS firmware 104 stored in the non-volatile memory 208. The instructions of the BIOS firmware 104, when executed, initialize the system 100 and thereafter initiate execution of, and pass control to, the operating system control logic 1 12. The BIOS firmware 104 includes a driver for accessing/controlling the hardware device 106.

[0024] In block 404, the operating system control logic 1 12, or other logic of the system 100, copies a portion of the BIOS firmware 104 that includes the driver for accessing the hardware device 106. The copied portion of the BIOS firmware is stored as driver copy 1 14.

[0025] In block 502, the operating system control logic 1 12 executes the second operating system 202 in a virtual machine. The second operating system 202 includes a driver tailored to allow the second operating system 202 to access the hardware device 106. The driver used by the second operating system 202 is distinct and different from the driver included in the BIOS 104 or the driver copy 1 14.

[0026] In block 504, the second operating system 202 accesses the hardware device 106 via the second operating system specific driver. Accessing the hardware device 106 via the second operating system specific driver changes the parameters of the hardware device 106 and effectively makes the hardware device 106 inaccessible to the first operating system 1 10 because the first operating system 1 10 has no information regarding how the parameters of the hardware device 106 have been changed.

[0027] In block 406, the operating system control logic 1 12 executes the first operating system 1 10 in a virtual machine. The first operating system 1 10 lacks a driver tailored to allow the first operating system 1 10 to access the hardware device 106.

[0028] In block 506, the first operating system 1 10 needs access to the hardware device 106. In response to the need for access, the operating system control logic 1 12 instantiates a virtual machine that passes through the hardware device 106 (i.e., the VM is allowed direct access to the hardware device 106). In block 408, the operating system control logic 1 12 initiates execution of the copied portion of the BIOS firmware (i.e., the driver copy 1 14) in the virtual machine. Execution of the driver copy 1 14 in the virtual machine initializes the hardware device 106, thereby setting the hardware device 106 to a known state and enabling its use.

[0029] In block 508, the virtual machine in which the driver copy 1 14 is executing passes the parameters of the hardware device 106 to the operating system control logic 1 12 and the first operating system 1 10.

[0030] In block 410, the first operating system 1 10 communicates with driver copy 1 14 executing in the virtual machine to access the hardware device 106. For example, the first operating system 1 10 may access a frame buffer associated with the hardware device 106, and cause information to be displayed on a display device (e.g., a liquid crystal or other display) via the frame buffer access, pass commands to the driver that initiate operations (e.g., read or write operations) in the hardware device 106, etc..

[0031] In block 510, the first operating system 1 10 notifies the operating system control logic 1 12 that access to the hardware device 106 is complete, and the operating system control logic 1 12 terminates the virtual machine that is executing the driver copy 1 14. [0032] The above discussion is meant to be illustrative of the principles and various examples of the present disclosure. Numerous variations and modifications will become apparent to those skilled in the art once the above disclosure is fully appreciated. It is intended that the following claims be interpreted to embrace all such variations and modifications.

Claims

CLAIMS What is claimed is:

1 . A system, comprising:

a processor;

a hardware device coupled to the processor;

a first operating system executable by the processor;

BIOS firmware comprising a driver executable by the processor to access the hardware device; and

operating system control logic executable by the processor to control execution of the first operating system, the operating system control logic to:

maintain a copy of the driver separate from the BIOS; determine whether the first operating system requires access to the hardware device;

execute the copy of the driver in a virtual machine based on the first operating system requiring access to the hardware device, wherein execution of the copy of the driver initializes the hardware device and the driver;

wherein the first operating system is to access the hardware device via the copy of the driver responsive to notification of hardware device and driver initialization by the virtual machine.

2. The system of claim 1 , wherein the operating system control logic is to terminate the virtual machine based on notification from the first operating system that access to the hardware device is complete.

3. The system of claim 1 , further comprising a boot loader to initiate execution of the operating system control logic; wherein the boot loader is to copy a portion of the BIOS firmware comprising the driver after control of the system passes from the BIOS to the boot loader.

4. The system of claim 1 , further comprising a second operating system to access the hardware device independently of the driver; wherein access to the hardware device by the second operating system sets the hardware device to a state different than that expected by the first operating system.

5. The system of claim 1 , wherein the system control logic comprises a hypervisor.

6. The system of claim 1 , wherein the operating system control logic is to instantiate the virtual machine responsive to the first operating system needing access to the hardware device; wherein the virtual machine is to pass parameters describing a state of the hardware device set by execution of the copy of the driver to the operating system control logic.

7. The system of claim 1 , wherein the hardware device is a graphics controller.

8. A method, comprising:

executing BIOS firmware to initialize a computer;

copying, subsequent to execution of the BIOS firmware, a portion of the BIOS firmware comprising a driver executed to access a hardware device of the computer;

executing a first operating system subsequent to the copying;

determining whether the first operating system needs access to the hardware device;

executing the copied portion of the BIOS firmware in a virtual machine responsive to determining that the first operating system needs access to the hardware device; and

accessing, by the first operating system, the hardware device via the copied portion of the BIOS firmware executing in the virtual machine.

9. The method of claim 8, further comprising terminating the virtual machine responsive to notification by the first operating system that access to the hardware device is complete.

10. The method of claim 8, further comprising:

executing a second operating system; and

accessing, by the second operating system, the hardware device independently of the copied portion of the BIOS;

wherein accessing the hardware device by the second operating system sets the hardware device to a state different than that expected by the first operating system.

1 1 . The method of claim 8, further comprising:

instantiating the virtual machine responsive to the first operating system requesting access to the hardware device;

passing parameters describing a state of the hardware device set by execution of the copied portion of the BIOS from the virtual machine to operating system control logic that controls execution of the first operating system; and

applying the parameters to access the hardware device.

12. A non-transitory computer-readable medium encoded with instructions that when executed cause a processor to:

execute BIOS firmware to initialize a computer;

copy, subsequent to execution of the BIOS firmware, a portion of the BIOS firmware comprising a driver executed to access a hardware device of the computer;

execute a first operating system subsequent to the copying;

execute the copied portion of the BIOS firmware in a virtual machine responsive determination that the first operating system needs access to the hardware device; and access the hardware device via the copied portion of the BIOS firmware executing in the virtual machine.

13. The computer-readable medium of claim 12 encoded with instructions that when executed cause a processor to terminate the virtual machine responsive to notification by the first operating system that access to the hardware device is complete.

14. The computer-readable medium of claim 12 encoded with instructions that when executed cause a processor to:

execute a second operating system; and

access, via the second operating system, the hardware device independently of the copied portion of the BIOS;

15. The computer-readable medium of claim 12 encoded with instructions that when executed cause a processor to:

instantiate the virtual machine responsive to the first operating system requesting access to the hardware device;

pass parameters describing a state of the hardware device set by execution of the copied portion of the BIOS from the virtual machine to operating system control logic that controls execution of the first operating system; and

apply the parameters to access the hardware device.