[Qemu-devel] Intel HDA and ALSA audio driver hogging event loop

[Stefan Hajnoczi <stefanha@gmail.com>]

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