Hi Marcelo, Thanks for the patch. I put it into my kernel source tree and tested the freshly build kernel in my testing environment. The problem is now - almost - gone. The only suspicious message (ONE occurrence immediate after starting the Server 2008 R2 VM) in syslog is now:
BUG: scheduling while atomic: qemu/3674/0x00000002 Modules linked in: tun bridge stp llc ext3 jbd uhci_hcd snd_hda_codec_realtek snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_timer snd soundcore snd_page_alloc i915 drm_kms_helper drm i2c_algo_bit video output i2c_i801 i2c_core ide_pci_generic ide_core button intel_agp ehci_hcd thermal e1000e iTCO_wdt iTCO_vendor_support processor usbcore kvm_intel evdev sg psmouse pcspkr serio_raw kvm rtc_cmos rtc_core rtc_lib ext4 mbcache jbd2 crc16 dm_mod sr_mod cdrom sd_mod ata_generic pata_acpi ahci libata scsi_mod Pid: 3674, comm: qemu Not tainted 2.6.33.2-KVM_patch #4 Call Trace: [<ffffffff8133d414>] ? schedule+0x544/0xa60 [<ffffffffa01839ad>] ? mmu_zap_unsync_children+0x17d/0x200 [kvm] [<ffffffff8133e612>] ? __mutex_lock_slowpath+0x162/0x350 [<ffffffff8133e809>] ? mutex_lock+0x9/0x20 [<ffffffffa016cc87>] ? kvm_ioapic_set_irq+0x47/0x160 [kvm] [<ffffffffa016d914>] ? kvm_set_irq+0xf4/0x190 [kvm] [<ffffffffa016d9b0>] ? kvm_set_ioapic_irq+0x0/0x50 [kvm] [<ffffffffa016da00>] ? kvm_set_pic_irq+0x0/0x50 [kvm] [<ffffffffa018587f>] ? paging64_walk_addr+0x25f/0x750 [kvm] [<ffffffff8133e70d>] ? __mutex_lock_slowpath+0x25d/0x350 [<ffffffffa016e905>] ? kvm_assigned_dev_ack_irq+0x35/0x90 [kvm] [<ffffffffa016d771>] ? kvm_notify_acked_irq+0x71/0x120 [kvm] [<ffffffffa016ce13>] ? kvm_ioapic_update_eoi+0x73/0xd0 [kvm] [<ffffffffa0192689>] ? apic_reg_write+0x569/0x700 [kvm] [<ffffffffa0192939>] ? apic_mmio_write+0x69/0x70 [kvm] [<ffffffffa0178fec>] ? emulator_write_emulated_onepage+0xac/0x1b0 [kvm] [<ffffffffa018d9c5>] ? x86_emulate_insn+0x1d25/0x4d20 [kvm] [<ffffffffa018b98e>] ? x86_decode_insn+0x96e/0xba0 [kvm] [<ffffffffa018442c>] ? kvm_mmu_unprotect_page_virt+0xec/0x100 [kvm] [<ffffffffa0178c13>] ? emulate_instruction+0xd3/0x380 [kvm] [<ffffffff8133fe3e>] ? __down_read+0xce/0xd0 [<ffffffffa0191c69>] ? apic_update_ppr+0x29/0x70 [kvm] [<ffffffffa01fcc08>] ? handle_apic_access+0x18/0x40 [kvm_intel] [<ffffffffa017ba7d>] ? kvm_arch_vcpu_ioctl_run+0x3ad/0xcf0 [kvm] [<ffffffff81081af7>] ? wake_futex+0x37/0x70 [<ffffffffa0168d5c>] ? kvm_vcpu_ioctl+0x53c/0x910 [kvm] [<ffffffff81013ab3>] ? __switch_to_xtra+0x163/0x1a0 [<ffffffff810088b1>] ? __switch_to+0x271/0x340 [<ffffffff81121405>] ? vfs_ioctl+0x35/0xd0 [<ffffffff811215c8>] ? do_vfs_ioctl+0x88/0x570 [<ffffffff8133d1c9>] ? schedule+0x2f9/0xa60 [<ffffffff81121b30>] ? sys_ioctl+0x80/0xa0 [<ffffffff810cf4ea>] ? fire_user_return_notifiers+0x3a/0x70 [<ffffffff8100a042>] ? system_call_fastpath+0x16/0x1b kvm: emulating exchange as write Honestly my knowledge of the kvm internals is not sufficient to decide if this bug report still belongs to my problem or is something different. So if you need more information or additional testing please let me know.. Best regards Ralf Bonenkamp -----Ursprüngliche Nachricht----- Von: Marcelo Tosatti [mailto:mtosa...@redhat.com] Gesendet: Dienstag, 20. April 2010 17:54 An: kvm Cc: Ralf Bonenkamp; Chris Wright; Yang, Sheng Betreff: *** GMX Spamverdacht *** [UNTESTED] KVM: do not call kvm_set_irq from irq disabled section The assigned device interrupt work handler calls kvm_set_irq, which can sleep, for example, waiting for the ioapic mutex, from irq disabled section. https://bugzilla.kernel.org/show_bug.cgi?id=15725 Fix by dropping assigned_dev_lock (and re-enabling interrupts) before invoking kvm_set_irq for the KVM_DEV_IRQ_HOST_MSIX case. Other cases do not require the lock or interrupts disabled (a new work instance will be queued in case of concurrent interrupt). KVM-Stable-Tag. Signed-off-by: Marcelo Tosatti <mtosa...@redhat.com> -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
