New synthetic device model in Hyper-V
Here’s another installment of my series on Hyper-V, this one around “Synthetic” device model.
Before I launch into an drill-down of the new synthetic device model in Hyper-V, let me make a couple of clarifications on terminology. First, Hyper-V vs hypervisor. Hyper-V is the name of the new virtualization technology in Windows Server 2008 (aka the virtualization “stack”) whereas the hypervisor specifically refers to the “microkernel” piece of the stack which I discussed in a previous blog. Understand that there are several hypervisor technologies out there: specifically you can have a Type 1 or Type 2 hypervisor, as well as a monolithic or microkernel-based hypervisor. Microsoft’s implementation is a Type 1 microkernel, which means it runs directly on the hardware (in a new layer known as “Ring –1”) and doesn’t include drivers in the hypervisor layer. BTW, here’s some trivia for you, the term hypervisor, actually dates back to 1972 and the IBM/370 platform. Second, you will hear about “enlightenments”, which are modifications to an OS that make it “hypervisor-aware” and thus work with the Hyper-V architecture which is designed to make virtualization more efficient and/or performant. Synthetic devices are enlightenments but are not the only enlightenments (hypercall APIs would be another). Hopefully that will clear up any confusion around those similar terms. Now for a discussion on the synthetic device model…
In Hyper-V there are 2 types of devices, synthetic and emulated. The new synthetic devices are loaded as part of the “Integration Components” (similar to the VM additions in VS/VPC). A synthetic device has "driver enlightenment," or a knowledge of native Windows drivers that exist in the parent partition, and are accessed via the VMBUS, which is implemented in the kernel level. Thus, synthetic devices do not correspond to a physical device and they use a logical communication channel (e.g. the VMBUS) to communicate with a physical device driver in the parent partition. An emulated device, on the other hand, requires access to parts of the virtualization stack in the User mode (e.g. the emulation, or legacy, driver that exists in the virtualization program such as Virtual Server), thus requiring “context switches” from the User mode to the kernel mode (and back) which is expensive from a processor perspective. The VMBUS, btw, is essentially the “pipe” between the Virtual Service Provider (VSP), which exists in the Parent partition, and Virtual Service Client (VSC) endpoints, which exist in the Child VM partitions, and could be network, disk, graphics, or other types of I/O.
So, to summarize, and re-state, when you hear about OSes that are “enlightened”, you should know that these natively understand and are designed to work with the Hyper-V architecture (incl the VMBUS for much faster device I/O). In the same vein, a synthetic driver is leveraged by the enlightened OS to utilize the Hyper-V stack (all kernel mode) to significantly enhance driver IO performance for the VM.
Hope this helps.