IT Management

Windows on System z

2 Pages

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: 

  • Dynamic code segment demarcation
  • Low-overhead determination of storage alteration
  • x86 to System z address correlation
  • Sparse allocation disk emulation
  • Prioritizing and sequencing of guest x86 interrupts
  • Staging, aging, and de-staging translated x86 code segments
  • Establishing ring-based x86 storage protection. 

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 www.mantissa.com.

2 Pages