summary refs log tree commit diff stats
path: root/classification_output/01/instruction/0966902
diff options
context:
space:
mode:
authorChristian Krinitsin <mail@krinitsin.com>2025-06-01 14:53:08 +0200
committerChristian Krinitsin <mail@krinitsin.com>2025-06-01 14:53:08 +0200
commit0d401089e9e72a8d9fb9b41d920126aa9fb23b05 (patch)
treee9ccc55b62498cf41023895880be55252227dc5b /classification_output/01/instruction/0966902
parent6d37f43e58f3ab6595d8769f3c5204ee164eafef (diff)
downloadqemu-analysis-0d401089e9e72a8d9fb9b41d920126aa9fb23b05.tar.gz
qemu-analysis-0d401089e9e72a8d9fb9b41d920126aa9fb23b05.zip
first classification of mail-threads
Diffstat (limited to 'classification_output/01/instruction/0966902')
-rw-r--r--classification_output/01/instruction/096690239
1 files changed, 39 insertions, 0 deletions
diff --git a/classification_output/01/instruction/0966902 b/classification_output/01/instruction/0966902
new file mode 100644
index 000000000..80cdabd29
--- /dev/null
+++ b/classification_output/01/instruction/0966902
@@ -0,0 +1,39 @@
+instruction: 0.803
+semantic: 0.775
+mistranslation: 0.718
+other: 0.715
+
+[Bug] "-ht" flag ignored under KVM - guest still reports HT
+
+Hi Community,
+We have observed that the 'ht' feature bit cannot be disabled when QEMU runs
+with KVM acceleration.
+qemu-system-x86_64 \
+  --enable-kvm \
+  -machine q35 \
+  -cpu host,-ht \
+  -smp 4 \
+  -m 4G \
+  -drive file=rootfs.img,format=raw \
+  -nographic \
+  -append 'console=ttyS0 root=/dev/sda rw'
+Because '-ht' is specified, the guest should expose no HT capability
+(cpuid.1.edx[28] = 0), and /proc/cpuinfo shouldn't show HT feature, but we still
+saw ht in linux guest when run 'cat /proc/cpuinfo'.
+XiaoYao mentioned that:
+
+It has been the behavior of QEMU since
+
+  commit 400281af34e5ee6aa9f5496b53d8f82c6fef9319
+  Author: Andre Przywara <andre.przywara@amd.com>
+  Date:   Wed Aug 19 15:42:42 2009 +0200
+
+    set CPUID bits to present cores and threads topology
+
+that we cannot remove HT CPUID bit from guest via "-cpu xxx,-ht" if the
+VM has >= 2 vcpus.
+I'd like to know whether there's a plan to address this issue, or if the current
+behaviour is considered acceptable.
+Best regards,
+Ewan.
+