Re: KVM host kernel hang

Alexander Graf
2009-01-07T13:02:42Z

On 07.01.2009, at 11:15, Avi Kivity wrote:

> Alexander Graf wrote:
>> Hi,
>>
>> while trying to run a current openSUSE in VMWare ESX in KVM (using
>> NPT),
>> some KVM code seems to be stuck in an endless loop. The qemu process
>> hangs, I can't attach gdb to it and the kernel module seems to be
>> hanging in a place where I don't see any looping code. One CPU is
>> definitely stuck in sys at 100% though.
>>
>> This is running git as of yesterday with some minor ESX modifications
>> that should not touch any of these parts (userspace and MSRs).
>>
>> Maybe one of you guys has a clue what's going on here. You'll find a
>> snippet of a t-sysrq trace with all qemu relevant parts below. The
>> registers (incl. IP) of these don't change over time.
>>
>> Alex
>>
>> qemu-system-x D ffff810001025280 0 27900 9501
>> ffff8101000e5c58 0000000000000082 0000000000000000 ffff8101000e5c1c
>> ffff81011446e728 ffffffff807e6280 ffffffff807e6280 ffff8100388ca680
>> ffffffff80601890 ffff8100388ca9c0 0000000000200200 ffff8100388ca9c0
>> Call Trace:
>> [<ffffffff804485ec>] __mutex_lock_slowpath+0x72/0xa9
>> [<ffffffff8044847a>] mutex_lock+0x1e/0x22
>> [<ffffffff88d7f630>] :kvm:kvm_arch_vm_ioctl+0x30e/0x5ae
>> [<ffffffff88d7c78e>] :kvm:kvm_vm_ioctl+0x744/0x777
>> [<ffffffff802acada>] vfs_ioctl+0x2a/0x78
>> [<ffffffff802acd6f>] do_vfs_ioctl+0x247/0x261
>> [<ffffffff802acdde>] sys_ioctl+0x55/0x77
>> [<ffffffff8020bffa>] system_call_after_swapgs+0x8a/0x8f
>> [<00007f2f3b15eb67>]
>>
>>
>
> Waiting for kvm->lock, so can't kill or strace.
>
>> qemu-system-x R running task 0 27908 9501
>> 0000000000000000 ffffffff88d7d3ad 0000000000000390 ffff810100120040
>> ffff810116491000 00000000fee00390 0000000000000000 0000000000000000
>> ffff81011b361d08 ffffffff88d7f1fb 0000000000000000 0000000100000000
>> Call Trace:
>> Inexact backtrace:
>>
>> [<ffffffff88d7d3ad>] :kvm:kvm_get_cs_db_l_bits+0x27/0x3e
>> [<ffffffff88d7f1fb>] :kvm:emulate_instruction+0x199/0x266
>> [<ffffffff88d86700>] :kvm:kvm_mmu_page_fault+0x49/0x86
>> [<ffffffff88a3ebe8>] :kvm_amd:pf_interception+0xa8/0xb1
>> [<ffffffff88a3e1b4>] :kvm_amd:handle_exit+0x218/0x221
>> [<ffffffff88d810f6>] :kvm:kvm_arch_vcpu_ioctl_run+0x600/0x81a
>> [<ffffffff88d7a4f0>] :kvm:kvm_vcpu_ioctl+0xf6/0x485
>> [<ffffffff802acada>] vfs_ioctl+0x2a/0x78
>> [<ffffffff802acd6f>] do_vfs_ioctl+0x247/0x261
>> [<ffffffff802a13a3>] fget_light+0x1/0x83
>> [<ffffffff802acdde>] sys_ioctl+0x55/0x77
>> [<ffffffff802a0b48>] sys_writev+0x60/0x94
>> [<ffffffff8020bffa>] system_call_after_swapgs+0x8a/0x8f
>>
>
> But the mutex is not taken here. Looks like we lost it, maybe
> CONFIG_LOCKDEP can find out where.

I have CONFIG_LOCKDEP_SUPPORT=y. How do I make it detect that it's
actually locking itself up?
Btw: The issue seems to be easily reproducible :-)

Alex