All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kiszka <jan.kiszka@web.de>
To: Hu Yaohui <loki2441@gmail.com>
Cc: qemu-devel@nongnu.org, kvm <kvm@vger.kernel.org>
Subject: Re: Fwd: Guest VM debug (Int 3 panic)
Date: Thu, 26 Sep 2013 19:26:52 +0200	[thread overview]
Message-ID: <52446E5C.6040707@web.de> (raw)
In-Reply-To: <CAHqbYQsntBSFTjAAYM8EJK1vq5V7AXYUiTyfP_sfLB94bdD0qw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3000 bytes --]

On 2013-09-26 16:14, Hu Yaohui wrote:
> Hi Jan,
> Thanks for your reply.
> On Thu, Sep 26, 2013 at 2:08 AM, Jan Kiszka <jan.kiszka@web.de> wrote:
> 
>> On 2013-09-25 20:08, Hu Yaohui wrote:
>>> Hi All,
>>> I am trying to debug guest OS through qemu with kvm enabled.
>>> Following is what I have done:
>>> 1: fire the qemu-kvm
>>> <snip>
>>> sudo qemu-system-x86_64 -hda vdisk.img -m 4096 -smp 2 -vnc :2 -boot c -s
>>> </snip>
>>>
>>> 2: wait until login into guest OS (ubuntu 10.04)
>>>
>>> 3: fire gdb
>>> <snip>
>>> gdb vmlinux
>>> target remote :1234
>>> b do_fork
>>> set arch i386:x86-64
>>
>> "set arch" is unneeded. vmlinux already tells gdb that you are debugging
>> x86-64.
>>
>>> c
>>> </snip>
>>>
>>> 4: after I typed "ls" in guest OS. The guest OS paniced with some message
>>> related to "int 3 blah blah". Then crashed.
>>>
>>> Someone said we should use hardware breakpoint when kvm is enabled, or
>>
>> You can use hardware breakpoints as well but it is not required unless
>> the target code can be overwritten (e.g. due to a reset).
>>
>>> "monitor system_reset" after set the breakpoint, but it didn't work for
>> me.
>>> The hardware breakpoint could not been hit anyway.
>>>
>>> I have tried with "-no-kvm", it works normally with breakpoints. But I
>> want
>>> to debug the guest OS with kvm enabled. I don't know whether someone has
>>> met this similar situation.
>>
>> You didn't tell us which version of QEMU (or is it old qemu-kvm?) you
>> are using, what host kernel and which CPU type (AMD vs. Intel). Did you
>> try a recent version of all of them already? I'm currently not aware of
>> gdb problems with QEMU/KVM, I'm rather using it on an almost daily basis
>> (typically git head versions).
>>
> I am using a nested VM.

Oh, "minor" detail ;) - why nested? But this used to work for me with a
patched 3.9+ kernel some while ago.

> My CPU type is intel.
> On L0, the QEMU-KVM version is 1.0, host kernel version: 2.6.32.10,
> kvm-kmod version: 3.2

Try at least the latest kvm-kmod version, but there are even more fixes
in kvm.git. Not sure if any of them has direct impact on your scenario,
but it's generally better to use a recent kernel with this still
experimental feature (VMX nesting).

As this is likely a KVM issue, I'm also CC'ing the corresponding list

Jan

> On L1, the QEMU-KVM version is 1.2, kernel version: 3.2.2, kvm-kmod
> version: 3.2
> On L2, guest kernel version: 2.6.32.10
> I am trying to debug L2 guest kernel on L1 QEMU. It gives me "INT 3"
> related kernel oops.
> I also have tried to debug the L1 guest kernel through L0 QEMU which works
> fine.
> 
>>
>> If you want to debug your issue: there is ftrace to record what KVM
>> events happen, and you can switch gdb into verbose mode as well,
>> comparing the communication between KVM on/off: set debug remote 1.
>>
>> Thanks for your suggestion! I will give that a try.
> 
>> Jan
>>
>>
>>
> 



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Jan Kiszka <jan.kiszka@web.de>
To: Hu Yaohui <loki2441@gmail.com>
Cc: qemu-devel@nongnu.org, kvm <kvm@vger.kernel.org>
Subject: Re: [Qemu-devel] Fwd: Guest VM debug (Int 3 panic)
Date: Thu, 26 Sep 2013 19:26:52 +0200	[thread overview]
Message-ID: <52446E5C.6040707@web.de> (raw)
In-Reply-To: <CAHqbYQsntBSFTjAAYM8EJK1vq5V7AXYUiTyfP_sfLB94bdD0qw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3000 bytes --]

On 2013-09-26 16:14, Hu Yaohui wrote:
> Hi Jan,
> Thanks for your reply.
> On Thu, Sep 26, 2013 at 2:08 AM, Jan Kiszka <jan.kiszka@web.de> wrote:
> 
>> On 2013-09-25 20:08, Hu Yaohui wrote:
>>> Hi All,
>>> I am trying to debug guest OS through qemu with kvm enabled.
>>> Following is what I have done:
>>> 1: fire the qemu-kvm
>>> <snip>
>>> sudo qemu-system-x86_64 -hda vdisk.img -m 4096 -smp 2 -vnc :2 -boot c -s
>>> </snip>
>>>
>>> 2: wait until login into guest OS (ubuntu 10.04)
>>>
>>> 3: fire gdb
>>> <snip>
>>> gdb vmlinux
>>> target remote :1234
>>> b do_fork
>>> set arch i386:x86-64
>>
>> "set arch" is unneeded. vmlinux already tells gdb that you are debugging
>> x86-64.
>>
>>> c
>>> </snip>
>>>
>>> 4: after I typed "ls" in guest OS. The guest OS paniced with some message
>>> related to "int 3 blah blah". Then crashed.
>>>
>>> Someone said we should use hardware breakpoint when kvm is enabled, or
>>
>> You can use hardware breakpoints as well but it is not required unless
>> the target code can be overwritten (e.g. due to a reset).
>>
>>> "monitor system_reset" after set the breakpoint, but it didn't work for
>> me.
>>> The hardware breakpoint could not been hit anyway.
>>>
>>> I have tried with "-no-kvm", it works normally with breakpoints. But I
>> want
>>> to debug the guest OS with kvm enabled. I don't know whether someone has
>>> met this similar situation.
>>
>> You didn't tell us which version of QEMU (or is it old qemu-kvm?) you
>> are using, what host kernel and which CPU type (AMD vs. Intel). Did you
>> try a recent version of all of them already? I'm currently not aware of
>> gdb problems with QEMU/KVM, I'm rather using it on an almost daily basis
>> (typically git head versions).
>>
> I am using a nested VM.

Oh, "minor" detail ;) - why nested? But this used to work for me with a
patched 3.9+ kernel some while ago.

> My CPU type is intel.
> On L0, the QEMU-KVM version is 1.0, host kernel version: 2.6.32.10,
> kvm-kmod version: 3.2

Try at least the latest kvm-kmod version, but there are even more fixes
in kvm.git. Not sure if any of them has direct impact on your scenario,
but it's generally better to use a recent kernel with this still
experimental feature (VMX nesting).

As this is likely a KVM issue, I'm also CC'ing the corresponding list

Jan

> On L1, the QEMU-KVM version is 1.2, kernel version: 3.2.2, kvm-kmod
> version: 3.2
> On L2, guest kernel version: 2.6.32.10
> I am trying to debug L2 guest kernel on L1 QEMU. It gives me "INT 3"
> related kernel oops.
> I also have tried to debug the L1 guest kernel through L0 QEMU which works
> fine.
> 
>>
>> If you want to debug your issue: there is ftrace to record what KVM
>> events happen, and you can switch gdb into verbose mode as well,
>> comparing the communication between KVM on/off: set debug remote 1.
>>
>> Thanks for your suggestion! I will give that a try.
> 
>> Jan
>>
>>
>>
> 



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

  reply	other threads:[~2013-09-26 17:26 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-25 17:55 [Qemu-devel] Guest VM debug (Int 3 panic) Hu Yaohui
2013-09-25 18:08 ` [Qemu-devel] Fwd: " Hu Yaohui
2013-09-26  6:08   ` Jan Kiszka
2013-09-26 14:14     ` Hu Yaohui
2013-09-26 17:26       ` Jan Kiszka [this message]
2013-09-26 17:26         ` Jan Kiszka
2013-09-26 18:53         ` Hu Yaohui
2013-09-26 18:53           ` [Qemu-devel] " Hu Yaohui
2013-09-26 19:07           ` Jan Kiszka
2013-09-26 19:07             ` [Qemu-devel] " Jan Kiszka
2013-09-26 19:20             ` Hu Yaohui
2013-09-26 19:20               ` [Qemu-devel] " Hu Yaohui
2013-09-26 21:51               ` Hu Yaohui
2013-09-26 21:51                 ` [Qemu-devel] " Hu Yaohui

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=52446E5C.6040707@web.de \
    --to=jan.kiszka@web.de \
    --cc=kvm@vger.kernel.org \
    --cc=loki2441@gmail.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.