* [PATCH] Print Guest VMCS state on vmexit failure
@ 2009-10-20 7:50 Chris Lalancette
2009-10-20 7:57 ` Gleb Natapov
2009-10-20 8:11 ` Avi Kivity
0 siblings, 2 replies; 8+ messages in thread
From: Chris Lalancette @ 2009-10-20 7:50 UTC (permalink / raw)
To: kvm; +Cc: Chris Lalancette
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 <clalance@redhat.com>
---
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;
}
--
1.6.0.6
^ permalink raw reply related [flat|nested] 8+ messages in thread* Re: [PATCH] Print Guest VMCS state on vmexit failure
2009-10-20 7:50 [PATCH] Print Guest VMCS state on vmexit failure Chris Lalancette
@ 2009-10-20 7:57 ` Gleb Natapov
2009-10-20 8:01 ` Chris Lalancette
2009-10-20 8:11 ` Avi Kivity
1 sibling, 1 reply; 8+ messages in thread
From: Gleb Natapov @ 2009-10-20 7:57 UTC (permalink / raw)
To: Chris Lalancette; +Cc: kvm
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 <clalance@redhat.com>
> ---
> 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.
--
Gleb.
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: [PATCH] Print Guest VMCS state on vmexit failure
2009-10-20 7:57 ` Gleb Natapov
@ 2009-10-20 8:01 ` Chris Lalancette
0 siblings, 0 replies; 8+ messages in thread
From: Chris Lalancette @ 2009-10-20 8:01 UTC (permalink / raw)
To: Gleb Natapov; +Cc: kvm
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 <clalance@redhat.com>
>> ---
>> 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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] Print Guest VMCS state on vmexit failure
2009-10-20 7:50 [PATCH] Print Guest VMCS state on vmexit failure Chris Lalancette
2009-10-20 7:57 ` Gleb Natapov
@ 2009-10-20 8:11 ` Avi Kivity
2009-10-20 8:42 ` Chris Lalancette
1 sibling, 1 reply; 8+ messages in thread
From: Avi Kivity @ 2009-10-20 8:11 UTC (permalink / raw)
To: Chris Lalancette; +Cc: kvm
On 10/20/2009 04:50 PM, 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.
>
register state can just as easily be examined in the qemu monitor.
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] Print Guest VMCS state on vmexit failure
2009-10-20 8:11 ` Avi Kivity
@ 2009-10-20 8:42 ` Chris Lalancette
2009-10-20 8:55 ` Nikola Ciprich
0 siblings, 1 reply; 8+ messages in thread
From: Chris Lalancette @ 2009-10-20 8:42 UTC (permalink / raw)
To: Avi Kivity; +Cc: kvm
Avi Kivity wrote:
> On 10/20/2009 04:50 PM, 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.
>>
>
> register state can just as easily be examined in the qemu monitor.
>
Ah, true. OK, forget this patch.
--
Chris Lalancette
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] Print Guest VMCS state on vmexit failure
2009-10-20 8:42 ` Chris Lalancette
@ 2009-10-20 8:55 ` Nikola Ciprich
2009-10-20 8:57 ` Chris Lalancette
0 siblings, 1 reply; 8+ messages in thread
From: Nikola Ciprich @ 2009-10-20 8:55 UTC (permalink / raw)
To: Chris Lalancette; +Cc: Avi Kivity, kvm, nikola.ciprich
Hi,
maybe it's stupid question, but is this available also when qemu/kvm
is started using libvirt & stuff? I think it uses monitor so it's
inaccessible for user no?
n.
On Tue, Oct 20, 2009 at 10:42:24AM +0200, Chris Lalancette wrote:
> Avi Kivity wrote:
> > On 10/20/2009 04:50 PM, 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.
> >>
> >
> > register state can just as easily be examined in the qemu monitor.
> >
>
> Ah, true. OK, forget this patch.
>
> --
> Chris Lalancette
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
-------------------------------------
Nikola CIPRICH
LinuxBox.cz, s.r.o.
28. rijna 168, 709 01 Ostrava
tel.: +420 596 603 142
fax: +420 596 621 273
mobil: +420 777 093 799
www.linuxbox.cz
mobil servis: +420 737 238 656
email servis: servis@linuxbox.cz
-------------------------------------
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] Print Guest VMCS state on vmexit failure
2009-10-20 8:55 ` Nikola Ciprich
@ 2009-10-20 8:57 ` Chris Lalancette
2009-10-20 9:08 ` Avi Kivity
0 siblings, 1 reply; 8+ messages in thread
From: Chris Lalancette @ 2009-10-20 8:57 UTC (permalink / raw)
To: Nikola Ciprich; +Cc: Avi Kivity, kvm, nikola.ciprich
Nikola Ciprich wrote:
> Hi,
> maybe it's stupid question, but is this available also when qemu/kvm
> is started using libvirt & stuff? I think it uses monitor so it's
> inaccessible for user no?
Yes and no. The monitor is inaccessible when using libvirt, but I totally
forgot that qemu dumps the register state to stderr before abort()'ing on an
unknown vm exit. Libvirt takes the output from stderr and stores it in
/var/log/libvirt/qemu/<guestname>. So you would still be able to see this
output when using libvirt.
--
Chris Lalancette
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] Print Guest VMCS state on vmexit failure
2009-10-20 8:57 ` Chris Lalancette
@ 2009-10-20 9:08 ` Avi Kivity
0 siblings, 0 replies; 8+ messages in thread
From: Avi Kivity @ 2009-10-20 9:08 UTC (permalink / raw)
To: Chris Lalancette; +Cc: Nikola Ciprich, kvm, nikola.ciprich
On 10/20/2009 05:57 PM, Chris Lalancette wrote:
> Nikola Ciprich wrote:
>
>> Hi,
>> maybe it's stupid question, but is this available also when qemu/kvm
>> is started using libvirt& stuff? I think it uses monitor so it's
>> inaccessible for user no?
>>
> Yes and no. The monitor is inaccessible when using libvirt, but I totally
> forgot that qemu dumps the register state to stderr before abort()'ing on an
> unknown vm exit. Libvirt takes the output from stderr and stores it in
> /var/log/libvirt/qemu/<guestname>. So you would still be able to see this
> output when using libvirt.
>
We've dropped the stderr part (IIRC), but nothing prevents libvirt from
accessing the register state and providing it to the user.
There's also the multiple monitor support which can be used for
debugging. Finally, you can connect with gdb (need to dynamically start
the gdb server via the monitor, again needs libvirt support).
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2009-10-20 9:09 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-10-20 7:50 [PATCH] Print Guest VMCS state on vmexit failure Chris Lalancette
2009-10-20 7:57 ` Gleb Natapov
2009-10-20 8:01 ` Chris Lalancette
2009-10-20 8:11 ` Avi Kivity
2009-10-20 8:42 ` Chris Lalancette
2009-10-20 8:55 ` Nikola Ciprich
2009-10-20 8:57 ` Chris Lalancette
2009-10-20 9:08 ` Avi Kivity
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).