Anonymous user
VMware: Difference between revisions
Jump to navigation
Jump to search
Add debugging information
| [unchecked revision] | [unchecked revision] |
(moved homepage link) |
(Add debugging information) |
||
Line 1:
'''VMWare''' is basically the rich man's Bochs. It can run any number of "Guest Operating Systems" and can boot from real media or image files. It is also a lot easier to configure than bochs.
Please note: VMware is not an emulator. There is lot of differnce between an emulator and a virtual machine monitor. Emulators, like Bochs, emulate each instruction, whereas VMWare (and Virtual PC) try to run most of the code on the host PC directly, and only emulate instructions that create invalid instruction faults or access system-level memory.
The VMware BIOS supports booting from a CD (use mkisofs to make a bootable CD, attach cdrom device to the .iso file) or a floppy drive (attach the floppy disk to a file), plus hard drives. These are the easiest options for loading your own kernel.
===Versions===
VMware's usefulness for hobbyists depends on the code's generation. Broadly:
* Workstation 5.0 (and previous). Not at all helpful for hobbyists. Error codes are designed for reporting to VMware, and there are no developer-centric features.
* Workstation 5.5 (Player 1.0, Server 1.0). Marginally more useful: a buggy guest operating system traces useful error messages. But in reality, go for something more modern. Supports SMP, if you are writing a multiprocessor kernel. Server and Player are free, which is a perk; go for Server.
* Workstation 6.0 (Fusion 1.0/1.1). Useful feature: gdb-based guest debug stub support. Useful feature: record-replay (though difficult to use), which might be helpful for reproducing race conditions.
* ??? (Server 2.0 beta in progress). Current generation; details unavailable.
===Guest debugging===
These options are valid in Workstation 6.0+, and should be set in the virtual machine's .vmx file.
* debugStub.listen.guest32 = "TRUE"
* debugStub.listen.guest64 = "TRUE"
If using these options, Workstation prints a message "VMware Workstation is listening for debug connection on port 8832." into the vmware.log file. Start a GDB session (using a copy of your kernel that includes debug information), then:
* target remote localhost:8832
Standard gdb commands work in this mode (e.g. printing memory, backtrace). Note that this is a debug stub attached to the KERNEL, not a userspace program.
Other useful options:
* debugStub.listen.guest32.remote = "TRUE" # Allows debugging from a different computer / VM instead of localhost.
* debugStub.listen.guest64.remote = "TRUE" # Same, but for 64-bit code
* monitor.debugOnStartGuest32 = "TRUE" # Breaks into debug stub on first instruction (warning: in BIOS!)
===Triple faults===
VMware products emulate a triple fault by resetting the machine. On beta products, however, a guest triple fault results in Bug 19580. Sometimes this represents a bug in VMware's emulation; usually, this represents a bug in your kernel.
==See Also==
===VMware Links===
* http://communities.vmware.com/index.jspa - Community forums. Engineers are present; if asked politely, some will provide very exact technical details
===External Links===
* http://www.pagetable.com/?p=25 - A description of a problem encountered using VMware on
▲* http://www.vmware.com/ - VMWare homepage
* http://stackframe.blogspot.com/2007/04/debugging-linux-kernels-with.html - VMware engineer describes how to debug Linux kernel with debug stub.
▲* http://www.pagetable.com/?p=25 - A description of a problem encountered using VMware on an AMD64 processor.
[[Category:Emulators]]
| |||