Re: KVM & Qemu crashed with infinite recursive kernel loop in the guest

[Chuck Ebbert <cebbert@redhat.com>]

On 02/28/2008 05:25 AM, Zdenek Kabelac wrote:

[cc: Avi]

> 
> While testing something inside the Qemu I've accidentally created
> infinite fast recursive loop with locked IRQ that instead of
> deadlocking guest kernel inside Qemu actually caused some troubles to
> the hosting system. (but the system survived)
> 
> Using 64bit kernels and git 2.6.25-rc3
> 
>  ------------[ cut here ]------------
>  WARNING: at arch/x86/kvm/x86.c:158 kvm_queue_exception_e+0x61/0x70 [kvm]()
>  Modules linked in: loop tun i915 drm ipt_MASQUERADE iptable_nat
> nf_nat nf_conntrack_ipv4 xt_s
> tate nf_conntrack ipt_REJECT xt_tcpudp iptable_filter ip_tables
> x_tables bridge llc nfsd lockd nfs_acl auth_rpcgss exportfs autofs4
> sunrpc bin
> fmt_misc dm_mirror dm_multipath dm_mod uinput kvm_intel kvm
> snd_hda_intel snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device
> snd_pcm_oss sn
> d_mixer_oss snd_pcm mmc_block arc4 ecb crypto_blkcipher cryptomgr
> sr_mod snd_timer crypto_algapi sdhci i2c_i801 cdrom snd psmouse
> rtc_cmos rtc
> _core serio_raw iwl3945 mac80211 cfg80211 soundcore iTCO_wdt
> iTCO_vendor_support e1000e snd_page_alloc ac intel_agp thinkpad_acpi
> hwmon backli
> ght rtc_lib i2c_core mmc_core evdev nvram button uhci_hcd ohci_hcd
> ehci_hcd usbcore [last unloaded: battery]
> Pid: 1856, comm: qemu-kvm Not tainted 2.6.25-rc3 #85
> 
> Call Trace:
>  [<ffffffff8103e54f>] warn_on_slowpath+0x5f/0x90
>  [<ffffffff8824a011>] ? :kvm:gfn_to_hva+0x11/0x90
>  [<ffffffff8824a2b2>] ? :kvm:kvm_read_guest_page+0x62/0x70
>  [<ffffffff81179160>] ? __down_read_trylock+0x20/0x60
>  [<ffffffff8824a308>] ? :kvm:kvm_read_guest+0x48/0x90
>  [<ffffffff81179160>] ? __down_read_trylock+0x20/0x60
>  [<ffffffff88253580>] ? :kvm:paging64_walk_addr+0x180/0x320
>  [<ffffffff8824efd1>] :kvm:kvm_queue_exception_e+0x61/0x70
>  [<ffffffff88250118>] :kvm:kvm_inject_page_fault+0x38/0x60
>  [<ffffffff882539fe>] :kvm:paging64_page_fault+0x27e/0x4d0
>  [<ffffffff88250370>] ? :kvm:emulator_write_emulated+0x70/0x90
>  [<ffffffff88254b22>] ? :kvm:x86_emulate_insn+0x3e2/0x4dd0
>  [<ffffffff8826aede>] ? :kvm_intel:vcpu_put_rsp_rip+0x2e/0x40
>  [<ffffffff8826aea5>] ? :kvm_intel:vmx_set_rflags+0x25/0x30
>  [<ffffffff88252cba>] :kvm:kvm_mmu_page_fault+0x1a/0xb0
>  [<ffffffff8826bfd5>] :kvm_intel:handle_exception+0x1e5/0x280
>  [<ffffffff8826a705>] :kvm_intel:kvm_handle_exit+0x75/0xc0
>  [<ffffffff8824f666>] :kvm:kvm_arch_vcpu_ioctl_run+0x286/0x760
>  [<ffffffff8824966e>] :kvm:kvm_vcpu_ioctl+0x38e/0x3a0
>  [<ffffffff812efe49>] ? mutex_unlock+0x9/0x10
>  [<ffffffff8108fcd4>] ? generic_file_aio_write+0x74/0xd0
>  [<ffffffff811161f6>] ? ext3_file_write+0x26/0xc0
>  [<ffffffff810bae01>] ? do_sync_write+0xf1/0x140
>  [<ffffffff8824aba5>] ? :kvm:kvm_vm_ioctl+0x85/0x220
>  [<ffffffff8110057c>] ? dnotify_parent+0x3c/0xa0
>  [<ffffffff810c95b1>] vfs_ioctl+0x31/0xa0
>  [<ffffffff810c98a3>] do_vfs_ioctl+0x283/0x2f0
>  [<ffffffff810c99a9>] sys_ioctl+0x99/0xa0
>  [<ffffffff8100c70a>] system_call_after_swapgs+0x8a/0x8f
> 
> And these were  repeated in the log many many time possible even mixed
> with some different back traces - but this should be the primary
> reason.
>