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.

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.

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.