Bug 1000176 - Windows XP guest uses 100% guest CPU
Windows XP guest uses 100% guest CPU
Status: CLOSED WORKSFORME
Product: Fedora
Classification: Fedora
Component: qemu (Show other bugs)
19
x86_64 Linux
unspecified Severity medium
: ---
: ---
Assigned To: Fedora Virtualization Maintainers
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-08-22 17:10 EDT by Ferry Huberts
Modified: 2013-08-31 11:42 EDT (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-08-31 11:42:37 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Ferry Huberts 2013-08-22 17:10:54 EDT
Description of problem:
I have installed a new Windows XP guest from scratch but it's using 100% guest CPU time, all the time.

I traced it the processor:
I had copy the host CPU info (Intel SandyBridge) into the VM definition. This caused the CPU usage.
When I changed the processor to Core2Duo it worked as expected (only CPU usage when needed).

Version-Release number of selected component (if applicable):
qemu-1.4.2-7.fc19.x86_64

How reproducible:
always
Comment 1 Ferry Huberts 2013-08-22 17:17:10 EDT
ah, some more info:
kernel-3.10.7-200.fc19.x86_64

Lenovo Thinkpad W520, 16GB memory

/proc/cpuinfo:
processor	: 7
vendor_id	: GenuineIntel
cpu family	: 6
model		: 42
model name	: Intel(R) Core(TM) i7-2860QM CPU @ 2.50GHz
stepping	: 7
microcode	: 0x29
cpu MHz		: 1975.000
cache size	: 8192 KB
physical id	: 0
siblings	: 8
core id		: 3
cpu cores	: 4
apicid		: 7
initial apicid	: 7
fpu		: yes
fpu_exception	: yes
cpuid level	: 13
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid
bogomips	: 4984.00
clflush size	: 64
cache_alignment	: 64
address sizes	: 36 bits physical, 48 bits virtual
power management:


Guest is running virtio drivers, but that actually doesn't matter, since the CPU usage bug is also there without these drivers.
Comment 2 Cole Robinson 2013-08-31 10:25:54 EDT
Can you grab the qemu command line from /var/log/libvirt/qemu/$vmname.log for the working configuration and the non-working configuration?

Does windows even correctly boot, or just start spinning at 100% soon after starting the VM?
Comment 3 Ferry Huberts 2013-08-31 10:55:17 EDT
(In reply to Cole Robinson from comment #2)
> Can you grab the qemu command line from /var/log/libvirt/qemu/$vmname.log
> for the working configuration and the non-working configuration?
> 

/usr/bin/qemu-system-x86_64 -machine accel=kvm -name xp -S -machine pc-i440fx-1.4,accel=kvm,usb=off -cpu core2duo,+osxsave,+pcid,+pdcm,+xtpr,+tm2,+est,+smx,+vmx,+ds_cpl,+dtes64,+pbe,+tm,+ht,+ss,+acpi,+ds -m 2048 -smp 2,sockets=2,cores=1,threads=1 -uuid 2c9e37a3-d16c-1246-2696-99e9ec540c34 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/xp.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime -no-shutdown -boot order=c,menu=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 -drive file=/home/data/kvm/xp-qcow2.img,if=none,id=drive-virtio-disk0,format=qcow2,cache=none -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=drive-virtio-disk0,id=virtio-disk0 -drive if=none,id=drive-ide0-1-0,readonly=on,format=raw,cache=none -device ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -netdev tap,fd=24,id=hostnet0,vhost=on,vhostfd=25 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:74:11:a5,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -device usb-tablet,id=input0 -spice port=5900,addr=127.0.0.1,disable-ticketing,seamless-migration=on -vga qxl -global qxl-vga.ram_size=67108864 -global qxl-vga.vram_size=67108864 -device AC97,id=sound0,bus=pci.0,addr=0x4 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6

> Does windows even correctly boot, or just start spinning at 100% soon after
> starting the VM?

it boots and runs correctly as far as i can see.
today it started spinning after about a minute. windows show svchost.exe and and the system idle process both at 50% (the VM has 2 CPUs), so 1 of the 2 CPUs is fully loaded.
Comment 4 Cole Robinson 2013-08-31 10:58:14 EDT
Hi Ferry, thanks for the quick response. Is that the broken command line? Please also show the working command line so we can compare (the 'core2duo' one mentioned in Comment #0).

Also, are there any error messages after the qemu command line in the log file? Feel free to just post the whole log file if you want, though it will help to specifically point out the working configuration.
Comment 5 Ferry Huberts 2013-08-31 11:29:30 EDT
I poked around a bit more and it appears that the CPU is not to blame.
the cmdline above is also problematic, which uses a core2duo cpu. setting it back to sandybridge show the same behaviour.

I'm unsure as to how to proceed here.

I also have an old Windows XP VM that does run ok under KVM, so I was (and am) stumped why the new one shows this strange behaviour.
Comment 6 Cole Robinson 2013-08-31 11:32:15 EDT
How about removing the <cpu> section from the VM XML altogether? sudo virsh edit $vmname to do that.

How did you verify that the bug exists without the virtio drivers? Actually uninstall the drivers and switch the disk/net models back to their defaults, or something else?
Comment 7 Ferry Huberts 2013-08-31 11:37:28 EDT
(In reply to Cole Robinson from comment #6)
> How about removing the <cpu> section from the VM XML altogether? sudo virsh
> edit $vmname to do that.
> 

no difference

> How did you verify that the bug exists without the virtio drivers? Actually
> uninstall the drivers and switch the disk/net models back to their defaults,
> or something else?

I switched the VM device to their non-virtio variants.
then the virtio driver within the guest are not active
Comment 8 Ferry Huberts 2013-08-31 11:41:14 EDT
I think I should just drop this bug.
As far as I'm concerned it appears to be a problem within the guest.

I have no problem if you close this bug
Comment 9 Cole Robinson 2013-08-31 11:42:37 EDT
Okay, thanks for the info, will close this

Note You need to log in before you can comment on or make changes to this bug.