summary refs log tree commit diff stats
path: root/results/classifier/118/none/1914667
diff options
context:
space:
mode:
Diffstat (limited to 'results/classifier/118/none/1914667')
-rw-r--r--results/classifier/118/none/1914667103
1 files changed, 103 insertions, 0 deletions
diff --git a/results/classifier/118/none/1914667 b/results/classifier/118/none/1914667
new file mode 100644
index 000000000..3e89cef1d
--- /dev/null
+++ b/results/classifier/118/none/1914667
@@ -0,0 +1,103 @@
+user-level: 0.800
+peripherals: 0.764
+device: 0.752
+graphic: 0.727
+register: 0.719
+PID: 0.711
+permissions: 0.702
+assembly: 0.677
+network: 0.671
+ppc: 0.631
+socket: 0.630
+hypervisor: 0.629
+semantic: 0.625
+files: 0.625
+virtual: 0.603
+architecture: 0.602
+performance: 0.601
+risc-v: 0.597
+debug: 0.579
+vnc: 0.577
+kernel: 0.566
+VMM: 0.544
+mistranslation: 0.539
+boot: 0.521
+x86: 0.509
+arm: 0.508
+KVM: 0.506
+TCG: 0.477
+i386: 0.455
+
+High cpu usage when guest is idle on qemu-system-i386
+
+When running Windows XP in qemu-system-i386, the cpu usage of QEMU is about 100% even when the guest CPU usage is close to 2%. The host cpu usage should be low when the guest cpu usage is low.
+
+Command: qemu-system-i386 -hda <Windows XP HD image>
+
+Using this command also shows around 100% host CPU usage:
+qemu-system-i386 -m 700 -hda <Windows XP HD image> -usb -device usb-audio -net nic,model=rtl8139 -net user -hdb mountable.img -soundhw pcspk
+
+Using the Penryn CPU option also saw this problem:
+qemu-system-i386 -hda <Windows XP HD image> -m 700 -cpu Penryn-v1
+
+Using "-cpu pentium2" saw the same high host cpu usage.
+
+
+My Info:
+M1 MacBook Air
+Mac OS 11.1
+qemu-system-i386 version 5.2 (1ba089f2255bfdb071be3ce6ac6c3069e8012179)
+Windows XP SP3 Build 2600
+
+
+
+Just to compare notes I ran my same Windows XP image on an older version of QEMU. This is version 2.10.1. It was built for the x86_64 architecture. The host CPU architecture is aarm64. The host CPU usage was actually very low when the guest CPU usage was low. The guest was using about 8% and the host usage was around 14%.
+
+For version 5.2 of qemu-system-i386 the instruction the guest is busy executing over and over again is this: addb %al, (%eax)
+
+For version 2.10.1 this is the instruction that is being executed when the guest is idle:
+add %al,(%eax)
+
+
+After updating QEMU to 1214d55d1c41fbab3a9973a05085b8760647e411, I reinstalled Windows XP and the host CPU usage at idle was normal. My guess is that I picked a bad commit to reinstall Windows XP.
+
+I tried using "-smp 4". Windows XP started up to a black screen. When I restarted the problem with high CPU usage at idle was back. I did not use the "-smp 4" option after restarting.
+
+When I first specified the '-smp 4' option I saw Windows install something then have the computer restarted.
+
+
+
+I found a way to fix the high host cpu usage issue. To fix this issue click on Start->All Programs->Accessories->System Tools->System Restore. Then pick a restore point that is set before you tried the smp option. After the VM restarts the high CPU usage issue will be gone :)
+
+The QEMU project is currently moving its bug tracking to another system.
+For this we need to know which bugs are still valid and which could be
+closed already. Thus we are setting the bug state to "Incomplete" now.
+
+If the bug has already been fixed in the latest upstream version of QEMU,
+then please close this ticket as "Fix released".
+
+If it is not fixed yet and you think that this bug report here is still
+valid, then you have two options:
+
+1) If you already have an account on gitlab.com, please open a new ticket
+for this problem in our new tracker here:
+
+    https://gitlab.com/qemu-project/qemu/-/issues
+
+and then close this ticket here on Launchpad (or let it expire auto-
+matically after 60 days). Please mention the URL of this bug ticket on
+Launchpad in the new ticket on GitLab.
+
+2) If you don't have an account on gitlab.com and don't intend to get
+one, but still would like to keep this ticket opened, then please switch
+the state back to "New" or "Confirmed" within the next 60 days (other-
+wise it will get closed as "Expired"). We will then eventually migrate
+the ticket automatically to the new system (but you won't be the reporter
+of the bug in the new system and thus you won't get notified on changes
+anymore).
+
+Thank you and sorry for the inconvenience.
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+