44

According to the Oracle VirtualBox 6.0 manual, "Certain rare guest operating systems like OS/2 make use of very esoteric processor instructions that are not supported with our software virtualization. For virtual machines that are configured to contain such an operating system, hardware virtualization is enabled automatically." Any idea which "very esoteric processor instructions" would be meant by this?

6
  • 2
    I don't know the answers to your questions but I have OS/2 2.1 and OS/2 Warp both running under VirtualBox without issue. I didn't use any special settings.
    – Tim Locke
    Sep 6 at 14:44
  • 11
    @TimLocke that’s thanks to the hardware virtualisation in your system. Sep 6 at 15:32
  • 3
    OS/2 1.3, like WIndows 95 (ActiveX after 8b) used some instructions that were not intended to be used in production as Intel already had multi CPU and multi-core in mind. I know this because Cyrix did not even include those instructions and installing DirectX 8C required falling back to an Intel CPU. This was in the days when Windows hung after 49.7 days due to millisecond rollover. With more than one core where did the time come from, etc. OS/2 1.3 was a Microsoft product. They left a subsystem in Windows NT for a while.
    – mckenzm
    Sep 7 at 1:45
  • 3
    @mckenzm are you referring to LOADALL by any chance? (See LOADALL Strikes Again and How does the LOADALL instruction on the 80286 work?) That would have affected OS/2, at least 1.0 and 1.1, but not Windows 95 or NT. Do you have any references to Intel already having multi-CPU and multi-core in mind when they designed the 286? Sep 7 at 13:15
  • I'm thinking more of the time stamp counter, and quirks with the Cyrix MII as well as other Pentium equivalents at the time. My point being some of the opcodes were not intended to be used other than in bespoke system programmer type apps, and not compiled in to retail releases.
    – mckenzm
    Sep 7 at 14:19
67

As far as I’m aware the difficulty in virtualising OS/2 isn’t due to esoteric processor instructions, but rather esoteric processor features. Specifically, OS/2 uses all the protected mode features available on 286 (OS/2 1.x) and 386 (OS/2 2.0 and later) PCs: segment limits, paging, protection rings... The latter has commonly been given as the main difficulty in supporting OS/2: while most protected-mode PC operating systems use only rings 0 (kernel) and 3 (user-mode), OS/2 also uses ring 2 for privileged code which couldn’t touch the kernel but could access some pieces of hardware (for printers and displays).

Because support for x86-style rings other than 0 and 3 isn’t needed for many operating systems, it probably isn’t a priority for developers of virtualisation tools; bear in mind that most virtualisation tools are developed mostly by companies, and their goal is typically to support specific workloads rather than provide a complete emulation of the original hardware platform. By skipping some support for unused rings, they only lost support for operating systems such as OS/2, and some features of DR DOS (DPMS specifically). On top of that, at least some virtualisation tools rely on protection rings themselves to virtualise the operating system they’re running: if they can’t use hardware-assisted virtualisation, they’ll run their virtual machine manager in ring 0, and run the guest operating system in ring 1 (instead of ring 0). Doing that doesn’t leave much room for the guest operating system to do anything clever with protection rings itself.

This probably isn’t the only feature which causes issues. OS/2 runs in both 16-bit and 32-bit protected mode simultaneously, with frequent switches from one to the other, even when running 32-bit applications; this requires specific support in virtualisation environments and assistance from the host operating system (at least, on 64-bit PC operating systems). OS/2 1.x relies on triple-faulting to leave protected mode, and OS/2 in general uses call gates for system calls, both of which require specific handling in the virtual machine manager and are much easier to implement with hardware assistance. (Other operating systems also use call gates, so that’s not an OS/2-specific requirement.)

All this is specifically a problem when virtualising on x86 without hardware virtualisation (AMD-V and VT-x). The goal when virtualising is to set the host environment up such that the guest can run directly on the CPU, with no translation, but with all privileged operations intercepted by the “hypervisor”. “Software virtualisation” on x86 is deficient for these purposes, and requires a lot of work in the hypervisor to make up for the architecture’s deficiencies. Hardware-assisted hypervisors can run OS/2 without difficulty, relying on the hardware to provide a complete protected-mode virtualisation; as can emulators (such as Bochs and QEMU in non-KVM mode), relying on their CPU emulation to simulate the protected-mode environment. Keith Adams’ and Ole Agesen’s 2006 paper, A Comparison of Software and Hardware Techniques for x86 Virtualization, explains the complexity of x86 virtualisation in detail.

17
  • 3
    Dev: "So, which arcane features we'll use on our new SO?" Tech Lead: "Yes."
    – T. Sar
    Sep 6 at 16:04
  • 27
    @T.Sar they weren’t arcane features when OS/2 was in development ;-). Sep 6 at 16:07
  • 12
    In fact they were remarkable features! The protection system of Multics - more than the protection system of Multics - on a single chip microprocessor! (The GE645/H6180 systems did not have gates - call, task, or interrupt - and did all that through the segment hardware trapping on ring changes. I think gates were an improvement/optimization over that.)
    – davidbak
    Sep 6 at 16:29
  • 15
    @JörgWMittag this Super User Q&A gives some reasons why later OSs only used two rings. OS/2 was developed for 286s, where all four rings were equally useful (albeit still hard to use because of the limited number of segment descriptors); most later OSs were developed for 386s, where using more than rings 0 and 3 made less sense (if protection was provided by paging instead of segments). Sep 6 at 16:37
  • 8
    That makes sense. It looks like it's a combination of the facts that the earlier OSs were either too simple to need it, or too portable to make use of it, and the later ones were designed for 386+ where it doesn't make sense. OS/2 seems to have been designed in a sweet spot where neither the 386 nor PowerPC existed, IBM didn't intend to port it, and they were also used to lots of hardware assistance through very powerful instruction sets from RS/6000 and their mainframes. Sep 6 at 16:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.