All x86 Intel processors since the 386 have had four internal protection levels, 0 to 3. Chicago uses only two of these, 0 and 3. Ring 3 is where all applications and Windows drivers reside; ring 0 is where the most privileged code resides, such as the operating-system kernel, software with full access to I/O ports, disk read/writes, and the DSPRM (digital signal processor Resource Manager). A driver at ring 0 can trap I/O port accesses and redirect them, if needed, thereby emulating a piece of hardware such as a modem or sound card.
The code that does this is called a VxD (virtual device driver). The DSPRM itself is a VxD. The DSPRM provides services for platform drivers that register the driver's control function and list the platform driver as a Plug and Play enumerator. The DSPRM also provides an interfa
ce for other client VxDs to use its COM (Common Object Model) interfaces.
In Chicago, the system can set up multiple virtual machines, all in ring 3; each DOS application and each 32-bit application is its own ring 3 VM (virtual machine), but all 16-bit Windows applications share a single VM. Windows 3.1 applications share one ring 3 VM.
The majority of the functionality of the DSPRM and platform driver is in ring 0 code. This is a shift from earlier approaches. Microsoft elected a ring 0 focus for three reasons. First, the DSPRM must present its primary interface at ring 3 to device drivers and an equivalent interface at ring 0 for VxDs. By keeping the majority of implementation in ring 3, the ring 0 interface could not have used the COM interface. Second, if implemented at ring 3 (easier to program), either the DSPRM would have to perform additional ring transitions, thereby hindering performance, or all platform drivers and client VxDs would be required to have both a ring 0 and a ring 3 comp
onent to communicate with their appropriate counterparts in the DSPRM. Finally, full services in ring 0 allow for more appropriate and efficient servicing of platform driver callbacks and VxD service requests. For example, VxDs in ring 0 have low interrupt latencies, and advisements are very fast. Note that Microsoft's VCOMM port driver and Sound Blaster implementation are already ring 0 VxDs.
Under the new DSP architecture, hardware developers will need to provide a platform driver for ring 0. This requires a new level of programming skills. VxDs are powerful but unfriendly, and they are perhaps somewhat dangerous under Chicago's loose security structure. However, Chicago will support C and C++ language-based drivers for ring 0, making the job somewhat easier. This level of code has typically been written in assembly language in the past.
Figure: The Ring 3 Virtual Machine
The horizontal dashed line represents the divide between ring 0 and ring 3. The ring 3 VMs are separated by the dash
ed vertical lines. This figure illustrates a DOS application talking to code emulating a Hayes AT modem through the port virtualization VxD. The VxD then passes data to the VCOMM port driver, which is the AT command-set parser. A separate VM in the figure is a DOS game that interfaces to the games VxD (Sound Blaster emulation).
Virtual Device Driver Services
