This is the final post in the VMKD series, a set of articles describing a program that greatly enhances the performance of kernel debugging in VMware virtual machines.
The following posts are members of the VMKD series:
- Fast kernel debugging for VMware, part 1: Overview
- Fast kernel debugging for VMware, part 2: KD Transport Module Interface
- Fast kernel debugging for VMware, part 3: Guest to Host Communication Overview
- Fast kernel debugging for VMware, part 4: Communicating with the VMware VMM
- Fast kernel debugging for VMware, part 5: Bridging the Gap to DbgEng.dll
- Fast kernel debugging for VMware, part 6: Roadmap to Future Improvements
- Fast kernel debugging for VMware, part 7: Review and Final Comments
At this point, the basic concepts behind how VMKD accelerates the kernel debugging experience in VMware should at the very least be vaguely familiar. This doesn’t mean that the story ends with VMKD, however. Many of the general, high-level concepts that VMKD uses to improve the performance of kernel debugging guests can be applied to other areas of the system.
That is to say, there are a number of implications outside of simply kernel debugging that are worth considering in the new reality that pervasive virtualization presents to us. Virtualization aware operating systems and applications present the potential for significant improvements in performance, user experience, and raw capabilities pretty much across the board as we move from seeing virtualization as a way to abstract interfaces intended to communicate with real hardware into a world where operating systems and drivers may more commonly be fully cognizent of the fact that they are operating in a VM. For example, one could conceivably imagine a time when 3D video performance approaches native performance on “bare metal”, thanks to virtualization awareness in display drivers and the interfaces they use to talk to the outside world.
In that respect, it seems logical to me that there may eventually become a time when virtualization is no longer simply about creating the virtual illusion of a physical machine. Instead, it may come to pass that virtualization ends up being more about providing an optimized “virtual platform” that does away with the constraints of hardware interfaces that are designed to be accessed by a single operating system at at time, in favor of a more abstract model where resources are natively accessed and shared by virtualized operating systems in a fashion that considers a virtual platform as a first class citizen rather than a mere echo of a physical machine.
Virtualization is here to stay. The sooner that it becomes accepted as a first class citizen in the operating system world, the better, I say.
Just wanted to say: I really enjoyed this series and will find a fast alternative to the serial port for kernel debugging a welcome relief.
I like to enable some fairly verbose logging while running a test series, to keep track of the events leading up to a bug. With the serial port, this takes forever.
The theory behind VMs and how VMWare is implemented was also very interesting.
I look forward to reading your future entries.
I’m curious about something… What if the virtual serial port in the guest VM wasn’t throttled to the speed of a real serial port? How much faster would the existing COM-port kernel debugger connection run?
@John:
From what I gather by reading Skywing’s articles, the unthrottled virtual serial interface would not be particularly fast because every byte written would involve a VM exit (a dumping of the virtualized register and memory TLB context) in addition to the expected context switch. You have to do this at every byte because that’s the granularity of the serial channel: there’s no in-built information about how long a transmission should be in total so that there could be some batching.
Skywing’s approach of trapping and exiting at a higher protocol layer is much better. Thanks for this series of articles. I hope your call to action is answered.
John: I never had much luck turning on the option to speed up the virtual serial port; last time I tried it, stuff started randomly breaking left and right. There’s some documentation if you want to try it yourself here:
http://www.vmware.com/support/ws4/doc/devices_serial_ws.html
…but I never really had a whole lot of luck with respect to reliable operation when greatly reducing the serial input delay. It might also be worth mentioning that when I was originally going the route of patching the internal KDCOM routines to send/receive one character from the serial port to bypass the serial I/O and use the OS not found I/O port (which is indeed faster), things would often get into a state where the target and KD would get stuck trying to resynchronize and you’d have to restart KD or sometimes even restart the target to get things working again. The KD protocol seems to have some unfortunate timing sensitive parts (especially during synchronization) that seemed to get unhappy about that.
[…] Skywing 最近在网站上å‘布了一个工具 vmkd（http://www.nynaeve.net/?page_id=168 ）å¯ä»¥è§£å†³ä¸Šé¢çš„é—®é¢˜ï¼Œè€Œä¸”è¿˜å†™äº†ä¸€ç³»åˆ—æ–‡ç« è¯´æ˜Žå®žçŽ°åŽŸç†ï¼ˆhttp://www.nynaeve.net/?p=174）。 […]