Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Microsoft Windows wikipedia , lookup
Windows Phone wikipedia , lookup
Windows Mobile wikipedia , lookup
Criticism of Windows Vista wikipedia , lookup
Mobile operating system wikipedia , lookup
Copland (operating system) wikipedia , lookup
Windows Phone 8.1 wikipedia , lookup
Hypervisors Leverage Multicore Processors for Embedded Systems The ability to run an RTOS with real-time control processes on the same multicore processor as a human interface OS like Windows, is made possible by an embedded hypervisor working in conjunction with on-chip virtualization technology. by Kim Hartman, TenAsys Corp. The newest multicore processors contain hardware-assisted virtualization features that enable hypervisors to be constructed in such a way that they can support multiple operating systems of different types to be hosted on an embedded system platform. Now real-time OSs can readily be hosted along with general-purpose OSs on the same platform. This has huge positive implications on the embedded computing industry because applications that previously required multiple processor platforms in order to guarantee determinism (typically a PC-compatible processor and another real-time computer that may or may not be PC-compatible), can now be implemented with greater ease on a single platform. Besides enabling lower system costs, the consolidation of platforms can also increase system performance and reliability by removing inter-platform communication bottlenecks that may have existed in multi-platform implementations. Running multiple operating systems on the same processor/platform requires software, sometimes called a hypervisor or virtual machine manager (VMM), which implements virtualization of the platform, whereby each operating system is presented with its own separate version of the underlying machine’s software architecture. Traditional virtualization consisted of virtualizing the entire machine, including its I/O for each OS, but this causes serious performance limitations in embedded applications that have real-time constraints. It may still work in office and server applications that don’t have real-time processing requirements, but for real-time functions, this virtualization approach is impractical. What has worked instead in real-time applications is a technique called embedded virtualization, whereby using an embedded virtualization manager (eVM), each operating system is presented with a software interface that is similar to the underlying machine, but is not identical. This is in order to allow each OS to access its I/O in a manner that serves the performance requirements of its applications. At first this was done with para-virtualization, a software-intensive technique that remaps the memory used by a particular RTOS to allow it to run in a system with another OS. The advent of new CPUs has simplified the implementation of multi-OS systems by remapping memory at runtime using hardware address translators. The latest Intel processors contain architectural features called VT-x and VT-d extensions that replace some of the para-virtualization techniques with hardware. Hardware-assisted virtualization features like VT-x do away with much of the complexity of software paravirtualization by providing hardware address translators built into the chipset that ensure that any memory address issued by a guest OS is automatically adjusted by a constant value called a loadoffset. Likewise, the hardware assisted virtualization feature called VT-d automatically adjusts the memory accesses generated by DMA bus mastering I/O devices according to the load-offset of the particular guest. Some platforms feature processors supporting VT-x but don’t have chipset support with VT-d. In those cases, software para-virtualization techniques must still be used. There are instances where para-virtualization may still have to be implemented, such as the re-routing of interrupts serviced by the guest OS when sharing the platform with Windows. These need to be altered by the VMM at load time according to rules setup by the user prior to load time. Some embedded VMM implementations require that the guest operating systems, drivers and middleware be modified, or para-virtualized in order to work together. This is costly and risky since the customization work needs to be reimplemented and verified every time a new version of one of the OSs and/or a driver is released. To avoid the expense and risk of maintaining customized OS and VMM software environments, a better solution is to use an embedded VMM that can run standard OS and application software without modification. To do this, the VMM should leverage the hardware virtualization support provided in Intel processors to enable PC-based RTOSs to run alongside Windows without requiring any modifications to Windows or the RTOS. It should dedicate a thread/core to each OS and use the processor’s VT-x feature to map the memory, making use of the processor’s VT-d extensions when the guest RTOS needs to interface directly to DMA bus mastering I/O devices. In addition, the optimal embedded VMM technology should enable users to work with an offthe-shelf copy of Windows that runs directly on the platform (bare-metal), supporting all of the latest devices and drivers that Windows employs. Since no modifications to the guest RTOS are required with this type of system, legacy application software will also run on the new platform without modification. The advantage of being able to preserve legacy code while consolidating platforms can’t be overemphasized. It can make or break the attractiveness of a new embedded system project. For example, Command Alkon of Birmingham, Alabama has millions of dollars invested in its control software for bulk construction materials plants. They have used the QNX 4 real-time OS since 1985 and have thousands of installations in place worldwide. The company is in the process of migrating from a dual-platform control system product that runs Windows on a PC and QNX on a separate real-time embedded PC “brick” to a single-platform system that runs both QNX and Windows on the same PC (Figure 1). “Combining the platforms was a natural evolution for us,” said Randy Willaman, senior manager of business expansion at Command Alkon. “We are able to simplify system maintenance and reduce the component count while maintaining reliability.” Before moving to a hypervisor, Willaman did a survey of available virtualization solutions. “One option that we looked at was virtualizing the entire machine and consequently, this solution couldn’t guarantee that our real-time control software would maintain its deterministic responsiveness,” said Willaman. “Another alternative was to rewrite our I/O drivers in order to get the system to work, but we couldn’t get source code from our OS vendor and we didn’t want to pay the cost. In the end, we chose eVM for Windows from TenAsys Corp. of Beaverton, Oregon, which gave us the performance we needed without requiring us to change our QNX application code.” In the Command Alkon implementation, the embedded virtualization manager (eVM) partitions the machine to separate resources for exclusive use by each operating system. This is done by configuring Windows to limit the number of hardware threads and memory that it uses. Windows boots first and runs normally within remaining allocated resources. Since it’s running on the bare machine rather than on an emulating software layer, Windows tasks execute with maximum performance. After Windows boots, the RTOS and real-time application software are loaded into memory that has been allocated for the real-time portion of the application, and the RTOS is loaded from a Windows driver and begins executing application code in its dedicated hardware environment. With access to its own performance-critical I/O devices, the real-time application will run completely independent of Windows. So that the real-time environment may use resources such as native drivers, they are provided for that purpose. When Windows and real-time tasks need to communicate, or the real-time application needs to use Windows resources, the two environments communicate via emulated communications links in shared memory (Figure 2). The Command Alkon system described above uses an emulated virtual Ethernet channel, but an emulated serial interface could also have been used. Real-time I/O devices are configured via a generic device driver on the Windows side and real-time interrupts are configured to be delivered to the virtual machine manager and not to Windows. Command Alkon may be at the leading edge of the embedded system consolidation trend, but their experience will be shared by thousands of embedded system designers who will use the latest hypervisor technology to decrease system costs. At the same time, they will increase performance while improving system reliability by combining real-time and Windows platforms on the same multicore processor. TenAsys, Beaverton, OR. (503) 748-4720. [www.tenasys.com]. Command Alkon, Birmingham, AL. (205) 879-3282. [www.commandalkon.com].