Hide Forgot
Description of problem: Boot a windows 2k8R2 with intel-hda device, then play music with windows media player. CLI: # /usr/libexec/qemu-kvm -M rhel6.2.0 -enable-kvm -m 4096 -smp 4 -name win2k8r2sp1 -uuid 1b6c1dc5-e8f6-412d-9ce1-b3edefcdea36 -rtc base=localtime,clock=host,driftfix=slew -boot c -drive file=/mnt/stable-guest-ABI/win2k8r2sp1.qcow2,if=none,id=drive-ide-0-0,media=disk,format=qcow2,cache=none,werror=stop,rerror=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 -spice port=9000,disable-ticketing -vga qxl -monitor stdio -balloon none -device intel-hda,id=sound0,bus=pci.0 -device hda-duplex Version-Release number of selected component (if applicable): # rpm -q qemu-kvm qemu-kvm-0.12.1.2-2.183.el6.x86_64 # uname -r 2.6.32-188.el6.x86_64 How reproducible: 100% Steps to Reproduce: 1. 2. 3. Actual results: play music disjointedly Expected results: play music smoothly Additional info: hit same issue with -device intel-hda,id=sound0,bus=pci.0 -device hda-output
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.