Bug 731235

Can you please repeat the test with win7 or winxp VM?
We need to see if it is guest specific or not.

In addition, please test it w/o spice, using local sound. Spice might be the cause for the interruptions.

Win7 (likely w2k8 too) uses a quite small ring buffer.  It's less than 4k, with sound data for 20 miliseconds fitting in.  Which implies that pretty much any latency bug in qemu will be noticable here.  It works reasonable for me with an idle guest.  Any disk I/O causes auditable dropouts.  Merging coroutines for qcow2 should improve the situation noticable.  There might be more issues latency lurking though.

There isn't much I can do about this in the intel-hda emulation code.

(In reply to comment #2)
> Can you please repeat the test with win7 or winxp VM?
> We need to see if it is guest specific or not.
> 
> In addition, please test it w/o spice, using local sound. Spice might be the
> cause for the interruptions.

I only tested win7 and win2k8r2 since no driver for winxp. Both win7 and win2k8r2 can reproduce this issue with local sound(no matter vnc or spice), but not every time. I noticed that qemu consumed 40% CPU and 70% MEM resource in my host when this issue reproduced.

CLI：
# /usr/libexec/qemu-kvm -M rhel6.2.0 -enable-kvm -m 4096 -smp 2 -uuid b5d1b5f3-6272-4c30-a080-ebb96fb1ec49 -rtc base=localtime,clock=host,driftfix=slew -boot dc -drive file=/root/bz731235/win7-x96_64.qcow2,if=none,id=drive-ide-0-0,media=disk,format=qcow2,cache=none,werror=stop -device ide-drive,drive=drive-ide-0-0,id=ide0-0-0 -netdev tap,id=hostnet1 -device rtl8139,netdev=hostnet1,id=net1,mac=64:31:50:41:e1:13 -usb -device usb-tablet,id=input1 -vga qxl -spice port=9000,disable-ticketing -monitor stdio -balloon none -device intel-hda,id=sound0,bus=pci.0 -device hda-output -drive file=/root/bz731235/en_windows_7_ultimate_with_sp1_x64_dvd_618240.iso,if=none,media=cdrom,readonly=on,format=raw,id=drive-cdrom -device ide-drive,drive=drive-cdrom,id=cdrom

(In reply to comment #3)
> Win7 (likely w2k8 too) uses a quite small ring buffer.  It's less than 4k, with
> sound data for 20 miliseconds fitting in.  Which implies that pretty much any
> latency bug in qemu will be noticable here.  It works reasonable for me with an
> idle guest.  Any disk I/O causes auditable dropouts.  Merging coroutines for
> qcow2 should improve the situation noticable.  There might be more issues
> latency lurking though.
>
I did nothing but played music when guest booted up.

Re #4: 40% CPU looks unusual high for an (almost) idle machine just playing music.  Worth looking where this comes from.  Any chance windows runs some background tasks?

(In reply to comment #6)
> Re #4: 40% CPU looks unusual high for an (almost) idle machine just playing
> music.  Worth looking where this comes from.  Any chance windows runs some
> background tasks?

Top shows 40% CPU consuming when windows booted up, and in guest, CPU usage is less than 5% when playing music

Can you please show what kvm_Stat and perf show on the host?

(In reply to comment #8)
> Can you please show what kvm_Stat and perf show on the host?

Please see the attachment.

Created attachment 523331 [details]
perf and kvm_stat info

Is there a significant load difference between playing and not playing music?
Or is the qemu-kvm load for a completely idle win7 machine unusual high too?
Which wakeup rate does powertop show for qemu-kvm?

(In reply to comment #12)
> Is there a significant load difference between playing and not playing music?
> Or is the qemu-kvm load for a completely idle win7 machine unusual high too?
> Which wakeup rate does powertop show for qemu-kvm?

Currently I can't reproduce this issue after I fresh installed this box, but will try more and update here

Looked at it with top and perf a bit.

In top you can enable thread display with Shift-H, you'll see at least three threads.  The first is the I/O thread, second is the vcpu (on a smp guest you'll have one thread per vcpu), third is the spice server thread.  There might be additional threads to serve disk I/O which are created and destroyed on demand.

perf allows to watch individual threads using the -t option in both 'perf top' and 'perf record'.

What I'm seeing here is alot of little things summing up:

  (1) First win7 doesn't use remote suspend for the usb tablet,
      so usb runs even with an inactive tablet and burns some CPU.
      Googled around a bit and didn't found a solution to that.

  (2) Windows itself (task manager) reports 10% cpu usage.

  (3) vcpu thread uses about 20% cpu.  Looks pretty high at first,
      but remember (see comment 3) that the buffer is pretty small.
      So we have a pretty high interrupt rate because of that and
      thus a high number of vmexits.  So a noticable overhead isn't
      surprising.  Also my laptop hasn't EPT, so there is softmmu
      overhead too.

  (4) The I/O thread does audio compression (celt codec) and needs
      some CPU for that.

In the end I see ~40% cpu load on my laptop (T500) too.

So while the cpu load looks pretty high at first it seems to be just the virtualization overhead.

That leaves the original issue of music playing disjointedly.  Not reproducable any more for the reporter according to comment #13, so I'll go close it.  Please reopen in case the bug shows up again.