To extend battery lifetime and improve the user experience, most modern operating systems (OSs) employ low-power operating modes that change diverse system behaviors according to battery status, such as the charging/discharging condition and remaining energy. In addition, to protect user and critical system data, most systems automatically save their memory contents to permanent storage devices, suspending their operations until the battery systems are recharged. This is called hibernation.
As the importance of battery management in mobile cyber-physical systems is ever increasing, such battery-related software components are becoming more powerful, complicated, and error-prone. Although many debuggers and profilers for application development have been introduced, there are relatively few tools for system software development; therefore, testing and resuscitating specific behaviors exhibited by system software or device drivers remain difficult problems.
Emerging virtualization technology significantly relieves this difficulty. By making target systems run on virtual machines (VMs) and by manipulating these VMs, developers can easily observe the behavioral characteristics of target systems as they react to hardware status changes.
In addition, virtualized target systems enable developers to run multiple target systems or to capacity, latest fully charged capacity, and remaining charge of the battery system. The driver also provides interfaces to adjust low-battery warning trip points through the controller so that the controller signals when the battery discharges below that point.
In the case of Linux, the standard ACPI driver collects current values for capacity, voltage, temperature, and many other measurements. This information is regularly updated in human-readable files in the proc file system.
Virtual Battery, our battery emulation layer, is designed to be ACPI-compliant so that any OS with ACPI battery drivers can easily accommodate it. In addition, Virtual Battery is targeted for full vir- tualization platforms so that guest OSs do not need to be modified to use it. To satisfy these requirements, the prototype is designed to fit into VirtualBox , an open-source, type II full virtualization platform.
The ACPI driver of VirtualBox is implemented as two separate drivers: a front-end driver and a back-end driver. The front-end driver is embedded in the VM code, while the back-end driver is located in the VMM code. The front-end driver merely transfers I/O requests to the back-end driver, which actually handles the requests in the host system. The ACPI drivers of guest OSs recognize the front-end driver as a standard ACPI controller.
Because the ACPI driver simply transfers status information for the host system’s battery, all VMs always share the same information. To provide independent battery status to each VM, the back- end driver manages VM battery status information. A part of the Virtual Battery emulation layer is also included in the back-end driver.
This creates a Virtual Battery file that contains information about fully charged capacity, present remaining capacity, current voltage, and many other measurements when a VM is initialized. Each VM has its own Virtual Battery file. As a result, the battery status of a VM no longer depends on either the host battery or the batteries of other VMs.
The function provided by the battery emulation layer is relatively simple in comparison to other types of devices. The battery status is changed not in response to OSs, but by user behavior, such as connecting the system to an AC power source.
Therefore, the back-end Virtual Battery device driver only handles inquiries for battery status. While the original back-end driver regularly polls host battery information through the host ACPI driver, the Virtual Battery back-end driver regularly fetches virtual battery information from the Virtual Battery status files. The Virtual Battery manager is a GUI application that displays and manipulates the status of Virtual Batteries.
The proposed scheme is suitable for testing procedures for battery- and power-related OS or application features. Therefore, it will be helpful in improving the energy efficiency of software. In addition, when end users run multiple VMs for various purposes, our scheme can be used to control VM energy consumption by setting the remaining charge for each VM.
The prototype currently supports only x86-based VMs since the virtualization platform that the prototype was built upon is dedi- cated for x86 virtualization. However, considering the growing popularity of mobile embedded systems, porting VirtualBox to virtualization platforms for embedded hardware architecture, such as ARM or MIPS, is highly desirable.
We believe that QEMU, a platform-independent virtualization tool, would be an appropriate base for this purpose, and we also expect that porting Virtual Battery to QEMU would require marginal effort since QEMU supports ACPI emulation and the ACPI emulation component of QEMU is well modularized similarly to VirtualBox.
To read more of this external content, download the complete paper from the online open archives at Sungkyunkwan University.