OSDev.org

iansjack wrote:

I've done some reading and USB seems far easier than network.

I wouldn't be too sure about that.

Providing you have a documented NIC it is relatively simple to write a workable network driver; it is then trivial to implement a custom protocol to transfer your debug information to another machine.

Yeah, once you can send Ethernet frames it doesn't really matter if you don't have layers 3 and above. Stick a cable in, capture packets on another machine in Wireshark. I'm sure you can write a custom dissector for your format too, they're usually just plugins written in C if I'm not mistaken.

I also plan to have a in-guest driver that will allow me to actually use the guest's command line to send and receive data from the hypervisor (well, it will be user mode component <> driver <> hv), but that's another story and is of no use while the guest is booting or if I crash it in one way or another. I think it's worth mentioning it.

Is USB more general than NICs? For network I might need different drivers for different cards. Can I get in a similar situation with USB?

For network I might need different drivers for different cards. Can I get in a similar situation with USB?

I would imagine that is the case. (I say "imagine" because USB is so complicated that I haven't yet got it working on any computer or VM, let alone different chipsets.) In addition you will need a driver for the hardware in the bridged cable that you use (or USB->serial, USB->Ethernet, whatever) and it might be difficult to obtain documentation of that. A number of Ethernet NICs, on the other hand, are well documented and comparatively easy to program and you just need a passive crossover cable for the connection.

However, if you have already successfully implemented USB with, say, a keyboard and you can get the documentation for your USB intermediary device(s) then give it a go.

I'm using bochs built in debugger in development of intel hypervisor, SimNow 4.6.2 public for AMD hypervisor. They both are slow in emulation but that does not hurt as capabilities of their debuggers are much more important for me. Bochs also prints some usefull output into log file when it detects something wrong in VMX settings - sometimes it is enough to look into log file and no need to use bochs debugger.
On baremetal, I also rarely use PS/2 keyboard LEDs and halting points by jmp $ instructions to observe whether hang by jmp $ or problem occurs and decode settings of 8 possible combinations of 3 LEDs which point passed and which not. I also have serial ports at all my developmental PCs connected by null modem cable but OS usually reprograms serial port or uses it for its own purposes and then I cannot use it.

feryno wrote:I'm using bochs built in debugger in development of intel hypervisor, SimNow 4.6.2 public for AMD hypervisor. They both are slow in emulation but that does not hurt as capabilities of their debuggers are much more important for me. Bochs also prints some usefull output into log file when it detects something wrong in VMX settings - sometimes it is enough to look into log file and no need to use bochs debugger.
On baremetal, I also rarely use PS/2 keyboard LEDs and halting points by jmp $ instructions to observe whether hang by jmp $ or problem occurs and decode settings of 8 possible combinations of 3 LEDs which point passed and which not. I also have serial ports at all my developmental PCs connected by null modem cable but OS usually reprograms serial port or uses it for its own purposes and then I cannot use it.

I really started by testing everything on a real machine and got used to it. I think this is the reason I started to implement a lot of debugging capabilities. I remember that I tried once to make bochs usable on my Windows 8.1 PC and got mad really fast. Sometimes I use qemu for the parts prior to the vmxon (but I only started to do this after a lot of the early days gotchas and mistakes were past me).
For Windows you can make it not use the serial by deleting (I recommend just renaming) some registry keys (I can't remember the exact location, but their name goes something like sercx, ser*something*). I'd have to get home and look into it.

I use audio output through the PC speaker for debugging. I've written a simple set of C code routines that will output binary data through the PC speaker and a format not dis-similar to a conventional serial link, and then I can record it on my phone and process the recording with a utility that I wrote to run on my development machine to extract the data. It works surprisingly well.