MVM/DOS personality

This is an infrastructure for running VM's with unmodified OS's

MVM server

The MVM server is a central server of the MVM personality – the infrastructure for running multiple virtual machines on top of L4 microkernel. It is almost separate from OS/2 personality, but can be controlled by OS/2 programs via DosOpenVDD/DosCloseVDD/DosRequestVDD API's.

So, the MVM server exposes some interfaces to other OS personalities to be controlled by them. Also, it starts VM's, which are executed in the context of a VM monitor, running a guest OS (DOS, for example). The VM environment is defined by the VDD's 1) loaded. The MVM server loads VDD's, which are a kind of plugins. Also, it exports some helper API's for VDD's via MVDM.DLL.

Virtual Device Drivers (VDD's)

A VDD is like a plugin for MVM Server, and it can communicate with outside programs via request API (DosRequestVDD for OS/2 programs). On the other side, from the VM point of view, the VDD emulates some BIOS services/Option ROM's, a hardware devices of guest platform. It installs interrupt handlers, catches I/O ports or MMIO registers accesses from inside the guest OS. A VDD implements its services based on VDD helpers API, served by the MVM server.

Originally, the MV(D)M were used to emulate a 8086 machine with BIOS and DOS/Win 3.1. But now it is a trend for many OS'es to have the kernel virtual machines, like kvm in Linux or VirtualPC in WinNT. Our MVM personality is our solution of the same kind, but it not so monolithic like qemu/kvm – it decomposed to several parts, in best IBM solutions design traditions. The VDD's are like plugins for MVM server, allowing to extend the MVM environment. They're loadable modules (DLL's).

Also, as we're told previously, to share the screen with OS/2 apps and apps of other personalities, IBM created the solution of “Seamless WinOS/2”. This is the possibility for Win 3.1 programs to share the same screen with OS/2 PM ones.

This is done with a special VDD's, like VVIDEO (VVGA, VSVGA, etc) implementiing a video mode support in a DOS window (or fullscreen). The DOS window is implemented as a special DLL (pmvdmp.dll) which was loaded by PM. It communicates with a VM via DosRequestVDD and implement the video functions via GPI calls (for windowed mode, so it is a PM application, based on VIO Shield (pmviop.dll), working via BVH drivers, like bvhwndw.dll for windowed OS/2 and DOS sessions, or bvhvga.dll+bvhsvga for fullscreen OS/2 or DOS sessions).

For windowed WinOS/2 sessions, it existed the solution of using a so-called PM shield (seamless.dll) and WinOS/2 shield (winsheld.exe). The 1st one is an “avatar” of Windows application in OS/2 PM world. And vice versa, the WinOS/2 shield is a representative of a PM app in WinOS/2 world.

Also, the second solution exists, based on GRADD video driver model. It works via VVMI (vmanwin.sys in the Intel OS/2). It is the VDD related to the communication of windows video driver (ifgdi2vm.drv for fullscreen, isgdi2vm.drv for seamless mode) with GRADD's VMAN 2). The special thread in VMAN polls the VVMI driver to communicate with Windows driver. So, the Windows driver is a generic one, but it communicates with a “real” driver. This results in WinOS/2 and OS/2 PM shared the same screen using access to a common video driver. See the GRADD-related section for more details about multiple graphics engines sharing the same screen/video driver.

Virtual Machine Monitor

The VMM 3) is a program implementing the environment of guest hardware platform, with help of VDD's. It maintains the contexts of all VM's, and handles the traps redirecting them to the needed VDD, loads the IST 4) for different processor instruction sets, utilizes the hardware emulation features of the CPU, like VM86, AMD SVM, Intel VT-x etc.

It maintains the address space layout of a VM application, loads a firmware (for BIOS, the SeaBIOS can be used) and DOS emulation kernel.

The DOS emulation kernel (doskrnl)

The DOS emulation kernel is a special rehosted DOS kernel working via OS/2 (or PN 5)) services. For example, file system API's of int 21h are implemented via OS/2 (or PN) file API's.

Instruction Set Translator (IST)

The IST is a DLL, emulating the instructions of Guest hardware via Host CPU instructions. It exports a set of entry points, each correspoinding the emulated instruction.

The similar component exist in QEMU – but it is linked statically with the emulator binary.

VM86 on Intel, and Hardware-assisted virtualization

Some processors implement special compatibility modes (VM86 allows creation of special task in protected mode, which emulates a virtual i8086 processor) or special instruction to assist the Virtual Machine Monitors creation. (Like “hypercall” to change context to a hypervisor, to execute its service and exit “hypervisor” mode). Also, the very new processors implement the IOMMU (a hardware support for sharing a hardware).

These extensions can be used to run unmodified OS'es on top of a hypervisor (it is supported in newer versions of Xen, VBox, VMWare, VPC).

Microkernels as Hypervisors

Microkernels and Hypervisors are very similar things. Microkernels implement similar features. For example, the Fiasco.OC microkernel supports SVM and VT-x and allows to run unmodified Linux in very thin VM's. This feature can be utilized in our MVM personality too.

1) Virtual Device Drivers
2) Video Manager
3) Virtual Machine Monitor
4) Instruction Set Translator
5) Personality Neutral


Sven, 2016/01/05 05:47


I was wondering if there is any example how to use DosOpenVDD in Warp 3?

Is it possible to have support for int 21h inside a OS/2 16 bit process?

valerius, 2016/02/04 00:00

Hello, Sven, didn't seen you for a long time, glad to see you again! How are you?

There is a description and a small example of use of DosOpenVDD/DosRequestVDD/DosCloseVDD API's in OS/2 Warp 4.5 toolkit (it is supplied with eComStation, and I can give it you separately, if needed). The idea is: you open a driver by its name, get a handle, then use it to send requests, and finally, close a handle. It is like IOCtl, but with some specifics.

#include <os2.h>

HVDD      hvdd;      /*  The handle of a VDD returned by a previous call to DosOpenVDD. */
SGID      sgid;      /*  The identifier of a specific DOS session, or null. */
ULONG     cmd;       /*  A function code that is specific to a virtual device. */
ULONG     cbInput;   /*  The length, in bytes, of the application data in pInput. */
PVOID     pInput;    /*  The address of the command-specific information. */
ULONG     cbOutput;  /*  The length, in bytes, of pOutput. */
PVOID     pOutput;   /*  The address of the buffer where the VDD returns the information for the specified command. */
APIRET    ulrc;      /*  Return Code. */

ulrc = DosRequestVDD(hvdd, sgid, cmd, cbInput,
         pInput, cbOutput, pOutput);

– So, you specify a handle (hvdd), a VDM ID (sgid, a screeen group ID), a VDD-specific command (cmd), Input packet, output packet, and their sizes.

The API is the same for Warp 3 or newer versions. Also, I think, the examples should be available in OS/2 DDK in vddref and VDD sources (I also can share it with you, if needed). And I saw some usage examples in disassembled OS/2 DLL's like pmviop.dll, pmvdmp.dll, pmvdmh.dll. And yes, I think, it's possible to have some small VDD which installs a int 21h handler, with a logic moved to an OS/2 program, which will send DosRequestVDD commands to a VDD (not necessarily 16-bit, but any 32-bit OS/2 program).

WBR, valery

Enter your comment. Wiki syntax is allowed:

en/docs/general/mvm.txt · Last modified: 2016/02/03 05:02 by valerius