From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Yang, Sheng" Subject: Re: [UNTESTED] KVM: do not call kvm_set_irq from irq disabled section Date: Wed, 21 Apr 2010 15:51:38 +0800 Message-ID: <201004211551.38817.sheng.yang@intel.com> References: <20100420155401.GA12982@amt.cnet> Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Marcelo Tosatti , kvm , Chris Wright To: "Bonenkamp, Ralf" Return-path: Received: from mga11.intel.com ([192.55.52.93]:26233 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752486Ab0DUHv6 convert rfc822-to-8bit (ORCPT ); Wed, 21 Apr 2010 03:51:58 -0400 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: On Wednesday 21 April 2010 05:49:11 Bonenkamp, Ralf wrote: > Hi Marcelo, >=20 > Thanks for the patch. > I put it into my kernel source tree and tested the freshly build kern= el in > my testing environment. The problem is now - almost - gone. The only > suspicious message (ONE occurrence immediate after starting the Serv= er > 2008 R2 VM) in syslog is now: >=20 > 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 s= nd_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 iT= CO_wdt > iTCO_vendor_support processor usbcore kvm_intel evdev sg psmouse pcs= pkr > serio_raw kvm rtc_cmos rtc_core rtc_lib ext4 mbcache jbd2 crc16 dm_m= od > 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: > [] ? schedule+0x544/0xa60 > [] ? mmu_zap_unsync_children+0x17d/0x200 [kvm] > [] ? __mutex_lock_slowpath+0x162/0x350 > [] ? mutex_lock+0x9/0x20 > [] ? kvm_ioapic_set_irq+0x47/0x160 [kvm] > [] ? kvm_set_irq+0xf4/0x190 [kvm] > [] ? kvm_set_ioapic_irq+0x0/0x50 [kvm] > [] ? kvm_set_pic_irq+0x0/0x50 [kvm] > [] ? paging64_walk_addr+0x25f/0x750 [kvm] > [] ? __mutex_lock_slowpath+0x25d/0x350 > [] ? kvm_assigned_dev_ack_irq+0x35/0x90 [kvm] > [] ? kvm_notify_acked_irq+0x71/0x120 [kvm] Seems this time is kvm_notify_acked_irq() with RCU. --=20 regards Yang, Sheng > [] ? kvm_ioapic_update_eoi+0x73/0xd0 [kvm] > [] ? apic_reg_write+0x569/0x700 [kvm] > [] ? apic_mmio_write+0x69/0x70 [kvm] > [] ? emulator_write_emulated_onepage+0xac/0x1b0 [k= vm] > [] ? x86_emulate_insn+0x1d25/0x4d20 [kvm] > [] ? x86_decode_insn+0x96e/0xba0 [kvm] > [] ? kvm_mmu_unprotect_page_virt+0xec/0x100 [kvm] > [] ? emulate_instruction+0xd3/0x380 [kvm] > [] ? __down_read+0xce/0xd0 > [] ? apic_update_ppr+0x29/0x70 [kvm] > [] ? handle_apic_access+0x18/0x40 [kvm_intel] > [] ? kvm_arch_vcpu_ioctl_run+0x3ad/0xcf0 [kvm] > [] ? wake_futex+0x37/0x70 > [] ? kvm_vcpu_ioctl+0x53c/0x910 [kvm] > [] ? __switch_to_xtra+0x163/0x1a0 > [] ? __switch_to+0x271/0x340 > [] ? vfs_ioctl+0x35/0xd0 > [] ? do_vfs_ioctl+0x88/0x570 > [] ? schedule+0x2f9/0xa60 > [] ? sys_ioctl+0x80/0xa0 > [] ? fire_user_return_notifiers+0x3a/0x70 > [] ? system_call_fastpath+0x16/0x1b > kvm: emulating exchange as write >=20 > Honestly my knowledge of the kvm internals is not sufficient to decid= e if > this bug report still belongs to my problem or is something differen= t. So > if you need more information or additional testing please let me kno= w.. >=20 > Best regards > Ralf Bonenkamp >=20 > -----Urspr=FCngliche Nachricht----- > Von: Marcelo Tosatti [mailto:mtosatti@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 >=20 >=20 > The assigned device interrupt work handler calls kvm_set_irq, which > can sleep, for example, waiting for the ioapic mutex, from irq disabl= ed > section. >=20 > https://bugzilla.kernel.org/show_bug.cgi?id=3D15725 >=20 > 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). >=20 > KVM-Stable-Tag. > Signed-off-by: Marcelo Tosatti >=20