Gleb Natapov wrote: > On Tue, Oct 20, 2009 at 09:50:45AM +0200, Chris Lalancette wrote: >> If we fail to handle a VMEXIT for some reason, print out a lot >> more debugging information about the state of the GUEST VMCS >> area. This does not fix a bug, but helps a lot when trying to >> track down the cause of a VMEXIT/VMENTRY failure. >> >> Signed-off-by: Chris Lalancette <[email protected]> >> --- >> arch/x86/kvm/vmx.c | 38 ++++++++++++++++++++++++++++++++++++++ >> 1 files changed, 38 insertions(+), 0 deletions(-) >> >> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c >> index 311afd4..37b1682 100644 >> --- a/arch/x86/kvm/vmx.c >> +++ b/arch/x86/kvm/vmx.c >> @@ -3452,6 +3452,14 @@ static int (*kvm_vmx_exit_handlers[])(struct kvm_vcpu >> *vcpu) = { >> static const int kvm_vmx_max_exit_handlers = >> ARRAY_SIZE(kvm_vmx_exit_handlers); >> >> +#define PRINT_GUEST_SEGMENT(seg) do { >> \ >> + printk(KERN_DEBUG #seg ": SELECTOR 0x%lx, BASE 0x%lx, LIMIT 0x%lx, AR >> 0x%lx\n", \ >> + vmcs_readl(GUEST_##seg##_SELECTOR), \ >> + vmcs_readl(GUEST_##seg##_BASE), \ >> + vmcs_readl(GUEST_##seg##_LIMIT), \ >> + vmcs_readl(GUEST_##seg##_AR_BYTES)); \ >> + while(0) >> + >> /* >> * The guest has exited. See if we can fix it or if we need userspace >> * assistance. >> @@ -3512,6 +3520,36 @@ static int vmx_handle_exit(struct kvm_vcpu *vcpu) >> else { >> vcpu->run->exit_reason = KVM_EXIT_UNKNOWN; >> vcpu->run->hw.hardware_exit_reason = exit_reason; >> + >> + printk(KERN_DEBUG "GUEST STATE:\n"); >> + printk(KERN_DEBUG "CR0: 0x%lx\n", vmcs_readl(GUEST_CR0)); >> + printk(KERN_DEBUG "CR3: 0x%lx\n", vmcs_readl(GUEST_CR3)); >> + printk(KERN_DEBUG "CR4: 0x%lx\n", vmcs_readl(GUEST_CR4)); >> + printk(KERN_DEBUG "VMENTRY CONTROL: 0x%lx\n", >> + vmcs_readl(VM_ENTRY_CONTROLS)); >> + printk(KERN_DEBUG "DR7: 0x%lx\n", vmcs_readl(GUEST_DR7)); >> + printk(KERN_DEBUG "SYSENTER ESP: 0x%lx\n", >> + vmcs_readl(GUEST_SYSENTER_ESP)); >> + printk(KERN_DEBUG "SYSENTER EIP: 0x%lx\n", >> + vmcs_readl(GUEST_SYSENTER_EIP)); >> + >> + PRINT_GUEST_SEGMENT(CS); >> + PRINT_GUEST_SEGMENT(SS); >> + PRINT_GUEST_SEGMENT(DS); >> + PRINT_GUEST_SEGMENT(ES); >> + PRINT_GUEST_SEGMENT(FS); >> + PRINT_GUEST_SEGMENT(GS); >> + PRINT_GUEST_SEGMENT(TR); >> + PRINT_GUEST_SEGMENT(LDTR); >> + >> + printk(KERN_DEBUG "GDTR: BASE 0x%lx, LIMIT 0x%lx", >> + vmcs_readl(GUEST_GDTR_BASE), >> + vmcs_readl(GUEST_GDTR_LIMIT)); >> + printk(KERN_DEBUG "IDTR: BASE 0x%lx, LIMIT 0x%lx", >> + vmcs_readl(GUEST_IDTR_BASE), >> + vmcs_readl(GUEST_IDTR_LIMIT)); >> + printk(KERN_DEBUG "RIP: 0x%lx\n",vmcs_readl(GUEST_RIP)); >> + printk(KERN_DEBUG "RFLAGS: 0x%lx\n",vmcs_readl(GUEST_RFLAGS)); >> } >> return 0; > Move this to separate function may be? vmx_handle_exit() will be hard > to read with this blob in the middle.
The blob is at the end, so I don't think it is terrible, but I see what you mean. I'm happy to move it to a function; I'll repost with that change after seeing if there are other comments. Thanks, -- Chris Lalancette -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
