Re: [UNTESTED] KVM: do not call kvm_set_irq from irq disabled section

["Yang, Sheng" <sheng.yang@intel.com>]

On Wednesday 21 April 2010 05:49:11 Bonenkamp, Ralf wrote:
> 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]

Seems this time is kvm_notify_acked_irq() with RCU.

-- 
regards
Yang, Sheng

>  [<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: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
> 
> 
> 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 <mtosatti@redhat.com>
>