May 10 ’10

Windows on System z

by Philip H. Smith III in z/Journal

For more than four decades, various incarnations of IBM’s popular Virtual Machine mainframe hypervisor—VM/370, VM/SP, VM/XA, VM/ESA, and now z/VM, plus mutations such as High Performance Option (HPO)—have provided unparalleled virtualization of mainframe operating systems for testing, resource sharing, and all the other uses for which virtualization has become trendy. 

In the late ’80s, VM/XA introduced the CP SET MACHINE command to set each virtual machine’s architecture to the original 370, XA, or (later) Enterprise System Architecture (ESA). Eventually, 370 emulation was removed; but the feature led VM customers to speculate on what would be required to add “SET MACHINE INTEL” to run PC applications under VM. Of course, everyone realized such a feature would require a huge effort and was probably impossible. 

Everyone, that is, except the intrepid programmers at Mantissa Corp. They investigated PC emulation under VM in 1993. At the time, they concluded the chip speed relationships between PCs and mainframes were “all wrong” and the project was shelved. In late 2006, they reconsidered. With the raw processor speed of the z10 and other advances (faster networking, among others), it was time. 

They weren’t strictly the first to consider such heresy: In 2001, Adam Thornton (who at the time worked for Sine Nomine Associates) ran the open source Bochs Intel emulator under Linux under VM on a Multiprise 3000. With the relatively modest processor speed of the Multiprise and the number of layers of software involved, this was beyond slow. He managed to start Windows and display the Exchange Server logo, but that last step alone took several minutes. Clearly, the technology wasn’t yet adequate for the challenge. 

Enter z/VOS 

In 2008, Mantissa announced on the IBMVM discussion list they were creating an Intel-on-z/VM product called z/VOS. The news generated restrained excitement. Intel machines had seriously threatened the mainframe’s existence for decades, so embracing the newly hosted platform wasn’t necessarily attractive. Yet, replacing dozens or hundreds of “squatty little boxes” with virtual machines under z/VM was an exciting concept and could further aid the resurgence of the mainframe, as has Linux on System z. 

Over the next few months, little news came from Mantissa. A SHARE presentation in early 2009 that had promised a demonstration was anticlimactic; it was only a canned demo. People suspected the project was a failure—until recently, when Mantissa detailed the product’s status and why it went dark for so long. The product, now named z86VM, is nearing market-ready status, following a year of re-architecting. 

Some may wonder why x86 on z makes sense. Mantissa points to the traditional strengths of System z server consolidation: 

In other words, the same motivations for Linux on System z apply to x86 on System z—perhaps more so, in some ways, since many Windows (and other x86 operating systems) applications aren’t available for Linux on System z. 

Real-Time Translation 

z86VM provides Intel emulation through a real-time binary translation engine that performs a single-pass translation of Intel x86 binary (executable) code to its z/Architecture equivalent. This is even more complex than it sounds. The relationship between instruction sets is far from one-to-one (the Intel equivalent of the 1,144-page Principles of Operation runs about 4,000 pages!) and the System z and x86 memory, interrupt, and instruction privilege models are quite different. 

In Mantissa’s original approach, programs ran under Conversation Monitor System (CMS), the familiar, robust, and mature single-user environment provided with VM since its first release. Since CMS offers multi-tasking, it seemed like an obvious platform upon which to build. However, after investing 18 months, Mantissa concluded that CMS limitations in 64-bit capability and multi-tasking were unacceptable and abandoned that platform. This resulted in the extended “dark” period with no news. 

This change also meant that a new multi-tasking environment was required—a new hypervisor between VM and the guest operating system (Windows, Linux, et al.). This hypervisor must be lightweight to minimize overhead. It also must do much more than translate binary instructions. For example, a non-privileged x86 instruction can alter the entire real-to-virtual address translation environment, completely changing the processor’s view of memory. 

The result is a new operating system, which IPLs like CMS or any other System z operating system. The desired x86 guest operating system loads after the z86VM hypervisor finishes IPLing. A Binary Translator Engine (BTE) translates code segments; a cache manager then loads them as appropriate/possible. A reference to a given code segment may or may not require a translation, depending on whether a translated copy exists in cache. 

The z86VM hypervisor manages interrupts, timers, I/O, memory, task dispatching, and provides a sparse backing file system (i.e., a given allocation uses only the space actually filled). 

The question quickly arises: “How do you drive a screen with this thing?” Obviously, you can’t attach dozens or hundreds of monitors to a z10! The solution is through the same Remote Desktop Protocol (RDP) that Windows Terminal Services uses. This protocol provides graphical remote access, and an open source version, rdesktop, is available for many platforms. So anyone can access a virtualized x86 image running under z/VM by pointing an RDP client at the appropriate target. Once you connect using RDP, it’s “just like being there,” although, of course, subject to network latency. RDP or equivalent is common for server access—“headless” servers are common in many shops—so this is perfectly reasonable. 

Multiple Patents 

Mantissa is filing multiple patents from this project, in areas such as: 

It remains to be seen whether z86VM will come to market, but System z fans should find it an intriguing project! For more information, visit