On Thu, Oct 20, 2016 at 9:40 AM, Stefan Hajnoczi <stefa...@gmail.com> wrote:
> Hi Gerd,
Gerd: Ping
> 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
