I would like to set up a virtual machine monitor using Microsoft Hyper-V, VMware vSphere/ESX, Xen, or any other alternative hypervisor solution that is able to monitor the execution of a guest OS (a VM within the VMM).
In particular, I'd like to be able to view the guest OS' instructions before they are run by the virtual CPU. Additionally, I'd also like to be able to set monitors on some of the guest OS' CPU registers so if they are modified (e.g. on write with a MOV instruction), the guest's state will be suspended at the location where the write occurred (and the rip/eip will point to that instruction).
I've been searching for a VMM solution that exposes a way to accomplish my goals, but I couldn't find anything.
Does anyone know what the best way of approaching such a thing is? Any recommendations on the hypervisor that I should be using? (I'm guessing that Xen would probably be easiest to modify and debug since it's open source)
Thanks a lot.
EDIT: I'll try to explain myself better. I'm attempting to debug code running in kernel-mode (x86-64). Right now, I'm using WinDbg to debug the ring0 code in a virtual machine (VMware).
If I could, I would be more than happy in setting a hardware breakpoint (ba) on a memory location and seeing what reads/writes to it. The problem is that my hardware breakpoints are being disabled by the code running in ring0. Basically, this code is saving the contents of the dr7 register off, clearing it, accessing the memory that I'm watching (the memory I set the hardware breakpoint on), and finally is restoring the dr7 register after access. Thus, my hardware breakpoint is never hit. This means I never figure out where the memory was being manipulated from. Suffice it to say that software breakpoints are not an acceptable alternative. Additionally, I've also tried mucking around with the general-detect bit in dr7 and installed my own trap handler to understand if someone's screwing with my hardware breakpoints. However, this code is quite smart and handles this attempt nicely (re: restores the old hook before accessing any of the debug registers).
I hope you now see my conundrum. I need to be running at a lower level than ring0 to deal with this code running at ring0. The only way to do that is in a hypervisor.
I would like to monitor the contents of say the dr7 register and see what's accessing it (read/writes). If I find the RIP of the faulting code, I'll be able to step through it and understand more of what it's doing.