* [Qemu-devel] Intel HDA and ALSA audio driver hogging event loop
@ 2016-10-20 8:40 Stefan Hajnoczi
2016-10-20 9:08 ` P J P
2016-11-04 10:35 ` Stefan Hajnoczi
0 siblings, 2 replies; 6+ messages in thread
From: Stefan Hajnoczi @ 2016-10-20 8:40 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [Qemu-devel] Intel HDA and ALSA audio driver hogging event loop
2016-10-20 8:40 [Qemu-devel] Intel HDA and ALSA audio driver hogging event loop Stefan Hajnoczi
@ 2016-10-20 9:08 ` P J P
2016-10-20 9:38 ` Stefan Hajnoczi
2016-11-04 10:35 ` Stefan Hajnoczi
1 sibling, 1 reply; 6+ messages in thread
From: P J P @ 2016-10-20 9:08 UTC (permalink / raw)
To: Stefan Hajnoczi; +Cc: Gerd Hoffmann, qemu-devel
Hello Gerd,
+-- On Thu, 20 Oct 2016, Stefan Hajnoczi wrote --+
| 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.
|
| 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.
I was looking at another loop issue in 'intel_hda_xfer'
-> https://lists.gnu.org/archive/html/qemu-devel/2016-10/msg04682.html
It does not address the above case, but maybe both could be fixed together.
Thank you.
--
Prasad J Pandit / Red Hat Product Security Team
47AF CE69 3A90 54AA 9045 1053 DD13 3D32 FE5B 041F
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [Qemu-devel] Intel HDA and ALSA audio driver hogging event loop
2016-10-20 9:08 ` P J P
@ 2016-10-20 9:38 ` Stefan Hajnoczi
0 siblings, 0 replies; 6+ messages in thread
From: Stefan Hajnoczi @ 2016-10-20 9:38 UTC (permalink / raw)
To: P J P; +Cc: Gerd Hoffmann, qemu-devel
On Thu, Oct 20, 2016 at 10:08 AM, P J P <ppandit@redhat.com> wrote:
> Hello Gerd,
>
> +-- On Thu, 20 Oct 2016, Stefan Hajnoczi wrote --+
> | 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.
> |
> | 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.
>
> I was looking at another loop issue in 'intel_hda_xfer'
> -> https://lists.gnu.org/archive/html/qemu-devel/2016-10/msg04682.html
>
> It does not address the above case, but maybe both could be fixed together.
These two issues are unrelated but I've reviewed your patch.
Stefan
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] Intel HDA and ALSA audio driver hogging event loop
2016-10-20 8:40 [Qemu-devel] Intel HDA and ALSA audio driver hogging event loop Stefan Hajnoczi
2016-10-20 9:08 ` P J P
@ 2016-11-04 10:35 ` Stefan Hajnoczi
2016-11-04 12:55 ` Gerd Hoffmann
1 sibling, 1 reply; 6+ messages in thread
From: Stefan Hajnoczi @ 2016-11-04 10:35 UTC (permalink / raw)
To: Gerd Hoffmann; +Cc: qemu-devel
On Thu, Oct 20, 2016 at 9:40 AM, Stefan Hajnoczi <stefanha@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
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [Qemu-devel] Intel HDA and ALSA audio driver hogging event loop
2016-11-04 10:35 ` Stefan Hajnoczi
@ 2016-11-04 12:55 ` Gerd Hoffmann
2016-11-04 13:01 ` Stefan Hajnoczi
0 siblings, 1 reply; 6+ messages in thread
From: Gerd Hoffmann @ 2016-11-04 12:55 UTC (permalink / raw)
To: Stefan Hajnoczi; +Cc: qemu-devel
Hi,
> > 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.
I think it should never monitor the file descriptor.
> > Should we add an AUD_plug_out()/AUD_unplug_out() interface to the QEMU
> > audio subsystem so soundcards can suspend file descriptor monitoring?
spiceaudio has a rate control which calculates the number of audio
samples based on time. That works pretty well and I think it is the
best way to handle it. The other audio drivers do the same.
Trying to keep the alsa audio buffers full (by watching the playback
file handle) does not only cause problems in case the guest hasn't
enough audio data to fill them, it also increases the latency in the
audio playback pipeline.
cheers,
Gerd
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] Intel HDA and ALSA audio driver hogging event loop
2016-11-04 12:55 ` Gerd Hoffmann
@ 2016-11-04 13:01 ` Stefan Hajnoczi
0 siblings, 0 replies; 6+ messages in thread
From: Stefan Hajnoczi @ 2016-11-04 13:01 UTC (permalink / raw)
To: Gerd Hoffmann; +Cc: qemu-devel
On Fri, Nov 4, 2016 at 12:55 PM, Gerd Hoffmann <kraxel@redhat.com> wrote:
>> > 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.
>
> I think it should never monitor the file descriptor.
>
>> > Should we add an AUD_plug_out()/AUD_unplug_out() interface to the QEMU
>> > audio subsystem so soundcards can suspend file descriptor monitoring?
>
> spiceaudio has a rate control which calculates the number of audio
> samples based on time. That works pretty well and I think it is the
> best way to handle it. The other audio drivers do the same.
>
> Trying to keep the alsa audio buffers full (by watching the playback
> file handle) does not only cause problems in case the guest hasn't
> enough audio data to fill them, it also increases the latency in the
> audio playback pipeline.
Okay, then the ALSA backend needs to be changed. Thanks for explaining.
I probably won't have time to look into this issue.
Stefan
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2016-11-04 13:01 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-10-20 8:40 [Qemu-devel] Intel HDA and ALSA audio driver hogging event loop Stefan Hajnoczi
2016-10-20 9:08 ` P J P
2016-10-20 9:38 ` Stefan Hajnoczi
2016-11-04 10:35 ` Stefan Hajnoczi
2016-11-04 12:55 ` Gerd Hoffmann
2016-11-04 13:01 ` Stefan Hajnoczi
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).