Re: [Qemu-devel] Fwd: Guest VM debug (Int 3 panic)

[Hu Yaohui]

Hi Jan,

I am working on some Nested VM related projects. Some other teammates have made the modifications to the kvm module. Most of my work depends on his. If I could not use Qemu Debug method. Could you please suggest some other debugging methods to debug the L2 guest OS(printk, hijack kernel function, or something else)? 

Thanks for your time!

Best Wishes,

Yaohui Hu

On Thu, Sep 26, 2013 at 1:26 PM, Jan Kiszka <address@hidden> wrote:

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 <address@hidden> 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
>>
>>
>>
>