From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44810) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bx8u7-00027f-1l for qemu-devel@nongnu.org; Thu, 20 Oct 2016 04:40:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bx8u6-00024W-1f for qemu-devel@nongnu.org; Thu, 20 Oct 2016 04:40:47 -0400 Received: from mail-lf0-x230.google.com ([2a00:1450:4010:c07::230]:34474) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1bx8u5-00023k-Q5 for qemu-devel@nongnu.org; Thu, 20 Oct 2016 04:40:45 -0400 Received: by mail-lf0-x230.google.com with SMTP id b81so72440629lfe.1 for ; Thu, 20 Oct 2016 01:40:45 -0700 (PDT) MIME-Version: 1.0 From: Stefan Hajnoczi Date: Thu, 20 Oct 2016 09:40:42 +0100 Message-ID: Content-Type: text/plain; charset=UTF-8 Subject: [Qemu-devel] Intel HDA and ALSA audio driver hogging event loop List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: qemu-devel Hi Gerd, A RHEL 7.2 guest sometimes hangs when I play back a wav file on the Intel HDA emulated sound card using the QEMU ALSA audio driver. I can only trigger this with the GTK UI but I think that may be a timing issue. The GTK UI has a GSource .prepare() function that calls recvmsg(2) on a non-blocking UNIX domain socket for X11. I think this affects the timing and increases the chance of hanging the guest. Note that this problem occurs both with the default ALSA->PulseAudio software device and the physical soundcard (PulseAudio disabled on host): QEMU_AUDIO_DRV=alsa QEMU_ALSA_DAC_DEV=sysdefault:CARD=PCH QEMU_ALSA_ADC_DEV=sysdefault:CARD=PCH x86_64-softmmu/qemu-system-x86_64 -net none -enable-kvm -m 1024 -cpu host -drive if=virtio,file=test.img,format=raw -soundhw hda intel_hda_xfer() transfers samples between the emulated card and the QEMU audio subsystem. The following case causes a problem: if (st->ctl & (1 << 26)) { /* * Wait with the next DMA xfer until the guest * has acked the buffer completion interrupt */ return false; } If the guest hasn't acked the interrupt yet then Intel HDA returns without providing any samples. The QEMU ALSA driver keeps monitoring the file descriptor so the next event loop iteration will try to transfer samples again. If the guest hasn't acked the interrupt then the QEMU main loop spins. Depending on whether the main loop drops the global mutex and how long it executes for, we can starve the vcpu thread. The result is that performance is terrible and the guest appears hung. I think the QEMU ALSA sound driver should not be monitoring the playback file descriptor if the emulated sound card decides it needs to wait for the guest. Any thoughts on this issue? Should we add an AUD_plug_out()/AUD_unplug_out() interface to the QEMU audio subsystem so soundcards can suspend file descriptor monitoring? Stefan