path: root/llm-chats/chatgpt

If the tiny code generator of qemu makes an error in the binary translation, when emulating an instruction set architecture, we call it a semantic mistranslation bug. Here are three gitlab issues in the toml format. Tell me, if they describe a semantic mistranslation bug. Answer only with yes and no.

1. issue:
id = 1371
title = "x86 BLSMSK semantic bug"
state = "closed"
created_at = "2022-12-16T06:43:29.794Z"
closed_at = "2023-03-01T01:08:38.844Z"
labels = ["Closed::Fixed", "accel: TCG", "target: i386"]
url = "https://gitlab.com/qemu-project/qemu/-/issues/1371"
host-os = "Windows 10 20H2"
host-arch = "x86"
qemu-version = "7.1.90 (v7.2.0-rc0)"
guest-os = "None"
guest-arch = "x86"
description = """The result of instruction BLSMSK is different with from the CPU. The value of CF is different."""
reproduce = """1. Compile this code
void main() {
    asm("mov rax, 0x65b2e276ad27c67");
    asm("mov rbx, 0x62f34955226b2b5d");
    asm("blsmsk eax, ebx");
}

2. Execute and compare the result with the CPU.
    - CPU
        - CF = 0
    - QEMU
        - CF = 1"""
additional = """This bug is discovered by research conducted by KAIST SoftSec."""

2. issue:
id = 1057
title = "AArch64: ISV is set to 1 in ESR_EL2 when taking a data abort with post-indexed instructions"
state = "closed"
created_at = "2022-06-02T20:50:04.695Z"
closed_at = "2022-07-18T16:47:38.098Z"
labels = ["accel: TCG", "target: arm", "workflow::In Progress"]
url = "https://gitlab.com/qemu-project/qemu/-/issues/1057"
host-os = "MacOS 12.4"
host-arch = "ARM64"
qemu-version = "QEMU emulator version 7.0.0"
guest-os = "Custom - BedRock Hypervisor running with the NOVA microkernel"
guest-arch = "ARMv8"
description = """I think that I have a Qemu bug in my hands, but, I could still be missing something. Consider the following instruction:
0x0000000000000000:  C3 44 00 B8    str   w3, [x6], #4

notice the last #4, I think this is what we would call a post-indexed instruction (falls into the category of instructions with writeback). As I understand it, those instructions should not have ISV=1 in ESR_EL2 when faulting.

Here is the relevant part of the manual:

For other faults reported in ESR_EL2, ISV is 0 except for the following stage 2 aborts:
• AArch64 loads and stores of a single general-purpose register (including the register specified with 0b11111, including those with Acquire/Release semantics, but excluding Load Exclusive or Store Exclusive and excluding those with writeback).


However, I can see that Qemu sets ISV to 1 here. The ARM hardware that I tested gave me a value of ISV=0 for similar instructions.

Another example of instruction: 0x00000000000002f8:  01 1C 40 38    ldrb  w1, [x0, #1]!"""
reproduce = """1. Run some hypervisor in EL2
2. Create a guest running at EL1 that executes one of the mentioned instructions (and make the instruction fault by writing to some unmapped page in SLP)
3. Observe the value of ESR_EL2 on data abort

Unfortunately, I cannot provide an image to reproduce this (the software is not open-source). But, I would be happy to help test a patch."""
additional = "n/a"

3. issue:
id = 2106
title = "QEMU build fail on Solaris 11.4 because \"FSCALE\" #defined by sys/param.h"
state = "opened"
created_at = "2024-01-16T19:39:42.479Z"
closed_at = "n/a"
labels = ["Build System", "target: arm"]
url = "https://gitlab.com/qemu-project/qemu/-/issues/2106"
host-os = "Solaris 11.4"
host-arch = "sparc"
qemu-version = "n/a"
guest-os = "n/a"
guest-arch = "n/a"
description = """Building target/arm/tcg/translate-sve.c fails on Solaris 11.4 because system's
/usr/include/sys/param.h has #define FSCALE (1 << FSHIFT) which results
in DO_ZPZZ_FP(FSCALE, aa64_sve, sve_fscalbn) at translate-sve.c:3864
attempting to expand the #define substitution instead of the text FSCALE.<p>I have not determined what the sequence of includes was that brought in sys/param.h<p>A workaround is to #undef FSCALE, but that may not be an appropriate long-term fix."""
reproduce = """1. mkdir build && cd build
2. ../configure --disable-docs --disable-rdma --enable-slirp
3. gmake"""
additional = """Full diagnostic output:
[1865/5402] Compiling C object libqemu-aarch64-softmmu.fa.p/target_arm_tcg_translate-sve.c.o
FAILED: libqemu-aarch64-softmmu.fa.p/target_arm_tcg_translate-sve.c.o 
cc -Ilibqemu-aarch64-softmmu.fa.p -I. -I.. -Itarget/arm -I../target/arm -Isubprojects/dtc/libfdt -I../subprojects/dtc/libfdt -Iqapi -Itrace -Iui -Iui/shader -I/usr/include/pixman-1 -I/usr/include/libdrm -I/usr/include/glib-2.0 -I/usr/lib/sparcv9/glib-2.0/include -I/usr/include/pcre -fdiagnostics-color=auto -Wall -Winvalid-pch -std=gnu11 -O2 -g -fstack-protector-strong -Wundef -Wwrite-strings -Wmissing-prototypes -Wstrict-prototypes -Wredundant-decls -Wold-style-declaration -Wold-style-definition -Wtype-limits -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wnested-externs -Wendif-labels -Wexpansion-to-defined -Wimplicit-fallthrough=2 -Wmissing-format-attribute -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-psabi -Wshadow=local -iquote . -iquote /opt/qemu -iquote /opt/qemu/include -iquote /opt/qemu/host/include/generic -iquote /opt/qemu/tcg/sparc64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -fno-strict-aliasing -fno-common -fwrapv -D_XOPEN_SOURCE=600 -D__EXTENSIONS__ -fPIE -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -DNEED_CPU_H '-DCONFIG_TARGET="aarch64-softmmu-config-target.h"' '-DCONFIG_DEVICES="aarch64-softmmu-config-devices.h"' -MD -MQ libqemu-aarch64-softmmu.fa.p/target_arm_tcg_translate-sve.c.o -MF libqemu-aarch64-softmmu.fa.p/target_arm_tcg_translate-sve.c.o.d -o libqemu-aarch64-softmmu.fa.p/target_arm_tcg_translate-sve.c.o -c ../target/arm/tcg/translate-sve.c
In file included from ../target/arm/tcg/translate-sve.c:21:
../target/arm/tcg/translate.h:728:17: error: pasting "trans_" and "(" does not give a valid preprocessing token
  728 |     static bool trans_##NAME(DisasContext *s, arg_##NAME *a) \\
      |                 ^~~~~~
../target/arm/tcg/translate-sve.c:3854:5: note: in expansion of macro ‘TRANS_FEAT’
 3854 |     TRANS_FEAT(NAME, FEAT, gen_gvec_fpst_arg_zpzz, name##_zpzz_fns[a->esz], a)
      |     ^~~~~~~~~~
../target/arm/tcg/translate-sve.c:3864:1: note: in expansion of macro ‘DO_ZPZZ_FP’
 3864 | DO_ZPZZ_FP(FSCALE, aa64_sve, sve_fscalbn)
      | ^~~~~~~~~~
../target/arm/tcg/translate-sve.c:3864:12: error: expected declaration specifiers or ‘...’ before numeric constant
 3864 | DO_ZPZZ_FP(FSCALE, aa64_sve, sve_fscalbn)
      |            ^~~~~~
../target/arm/tcg/translate.h:728:25: note: in definition of macro ‘TRANS_FEAT’
  728 |     static bool trans_##NAME(DisasContext *s, arg_##NAME *a) \\
      |                         ^~~~
../target/arm/tcg/translate-sve.c:3864:1: note: in expansion of macro ‘DO_ZPZZ_FP’
 3864 | DO_ZPZZ_FP(FSCALE, aa64_sve, sve_fscalbn)
      | ^~~~~~~~~~
../target/arm/tcg/translate.h:728:47: error: pasting "arg_" and "(" does not give a valid preprocessing token
  728 |     static bool trans_##NAME(DisasContext *s, arg_##NAME *a) \\
      |                                               ^~~~
../target/arm/tcg/translate-sve.c:3854:5: note: in expansion of macro ‘TRANS_FEAT’
 3854 |     TRANS_FEAT(NAME, FEAT, gen_gvec_fpst_arg_zpzz, name##_zpzz_fns[a->esz], a)
      |     ^~~~~~~~~~
../target/arm/tcg/translate-sve.c:3864:1: note: in expansion of macro ‘DO_ZPZZ_FP’
 3864 | DO_ZPZZ_FP(FSCALE, aa64_sve, sve_fscalbn)
      | ^~~~~~~~~~
In file included from ../target/arm/tcg/translate-sve.c:86:
libqemu-aarch64-softmmu.fa.p/decode-sve.c.inc:1112:13: warning: ‘trans_FSCALE’ used but never defined
 1112 | static bool trans_FSCALE(DisasContext *ctx, arg_FSCALE *a);
      |             ^~~~~~~~~~~~
../target/arm/tcg/translate-sve.c:3864:30: warning: ‘sve_fscalbn_zpzz_fns’ defined but not used [-Wunused-const-variable=]
 3864 | DO_ZPZZ_FP(FSCALE, aa64_sve, sve_fscalbn)
      |                              ^~~~~~~~~~~
../target/arm/tcg/translate-sve.c:3850:42: note: in definition of macro ‘DO_ZPZZ_FP’
 3850 |     static gen_helper_gvec_4_ptr * const name##_zpzz_fns[4] = { \\
      |                                          ^~~~
"""


ChatGPT said:
Yes

Yes

No

You said:
Now I will give you Mailing Threads. Transform them into the toml format i provided you, which should be the only output. If a variable is not given in the mails, write "n/a". The id's should be 10000 and upwards.  the state is closed, when the bug is fixed, and open, when the bug is not fixed.  First Thread:

This bug was fixed in the package qemu - 1:9.0.2+ds-4ubuntu5.3

---------------
qemu (1:9.0.2+ds-4ubuntu5.3) oracular; urgency=medium

  * d/p/u/lp2049698/*: Add full boot order support on s390x (LP: #2049698)
  * Cherry-pick prerequisite for above backport (to avoid FTBFS):
    - d/p/u/lp2049698/0-hw-s390x-sclp.c-include-s390-virtio-ccw.h-to-make.patch
  * d/qemu-system-data.links: symlink s390-netboot.img -> s390-ccw.img for
    backwards compatibility, as the code is now combined.
  * Fix qemu-aarch64-static segfaults running ldconfig.real (LP: #2072564)
    - lp-2072564-01-linux-user-Honor-elf-alignment-when-placing-images.patch
    - lp-2072564-02-elfload-Fix-alignment-when-unmapping-excess-reservat.patch
    Thanks to Dimitry Andric for identifying the fix.

 -- Lukas Märdian <slyon@ubuntu.com>  Thu, 13 Mar 2025 17:18:50 +0100

** Changed in: qemu (Ubuntu Oracular)
       Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/2072564

Title:
  qemu-aarch64-static segfaults running ldconfig.real (amd64 host)

Status in QEMU:
  Fix Released
Status in qemu package in Ubuntu:
  Fix Released
Status in qemu source package in Noble:
  Fix Committed
Status in qemu source package in Oracular:
  Fix Released

Bug description:
  [ Impact ]

   * QEMU crashes when running (emulating) ldconfig in a Ubuntu 22.04
  arm64 guest

   * This affects the qemu-user-static 1:8.2.2+ds-0ubuntu1 package on
  Ubuntu 24.04+, running on a amd64 host.

   * When running docker containers with Ubuntu 22.04 in them, emulating
  arm64 with qemu-aarch64-static, invocations of ldconfig (actually
  ldconfig.real) segfault, leading to problems when loading shared
  libraries.

  [ Test Plan ]

   * Reproducer is very easy:

  $ sudo snap install docker
  docker 27.5.1 from Canonical** installed
  $ docker run -ti --platform linux/arm64/v8 ubuntu:22.04
  Unable to find image 'ubuntu:22.04' locally
  22.04: Pulling from library/ubuntu
  0d1c17d4e593: Pull complete 
  Digest: 
sha256:ed1544e454989078f5dec1bfdabd8c5cc9c48e0705d07b678ab6ae3fb61952d2
  Status: Downloaded newer image for ubuntu:22.04

  # Execute ldconfig.real inside the arm64 guest.
  # This should not crash after the fix!
  root@ad80af5378dc:/# /sbin/ldconfig.real
  qemu: uncaught target signal 11 (Segmentation fault) - core dumped
  Segmentation fault (core dumped)

  [ Where problems could occur ]

   * This changes the alignment of sections in the ELF binary via QEMUs
  elfloader, if something goes wrong with this change, it could lead to
  all kind of crashes (segfault) of any emulated binaries.

  [ Other Info ]

   * Upstream bug: https://gitlab.com/qemu-project/qemu/-/issues/1913
   * Upstream fix: https://gitlab.com/qemu-project/qemu/-/commit/4b7b20a3
     - Fix dependency (needed for QEMU < 9.20): 
https://gitlab.com/qemu-project/qemu/-/commit/c81d1faf

  --- original bug report ---

  
  This affects the qemu-user-static 1:8.2.2+ds-0ubuntu1 package on Ubuntu 
24.04, running on a amd64 host.

  When running docker containers with Ubuntu 22.04 in them, emulating
  arm64 with qemu-aarch64-static, invocations of ldconfig (actually
  ldconfig.real) segfault. For example:

  $ docker run -ti --platform linux/arm64/v8 ubuntu:22.04
  root@8861ff640a1c:/# /sbin/ldconfig.real
  Segmentation fault

  If you copy the ldconfig.real binary to the host, and run it directly
  via qemu-aarch64-static:

  $ gdb --args qemu-aarch64-static ./ldconfig.real
  GNU gdb (Ubuntu 15.0.50.20240403-0ubuntu1) 15.0.50.20240403-git
  Copyright (C) 2024 Free Software Foundation, Inc.
  License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
  This is free software: you are free to change and redistribute it.
  There is NO WARRANTY, to the extent permitted by law.
  Type "show copying" and "show warranty" for details.
  This GDB was configured as "x86_64-linux-gnu".
  Type "show configuration" for configuration details.
  For bug reporting instructions, please see:
  <https://www.gnu.org/software/gdb/bugs/>.
  Find the GDB manual and other documentation resources online at:
      <http://www.gnu.org/software/gdb/documentation/>.

  For help, type "help".
  Type "apropos word" to search for commands related to "word"...
  Reading symbols from qemu-aarch64-static...
  Reading symbols from 
/home/dim/.cache/debuginfod_client/86579812b213be0964189499f62f176bea817bf2/debuginfo...
  (gdb) r
  Starting program: /usr/bin/qemu-aarch64-static ./ldconfig.real
  [Thread debugging using libthread_db enabled]
  Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
  [New Thread 0x7ffff76006c0 (LWP 28378)]

  Thread 1 "qemu-aarch64-st" received signal SIGSEGV, Segmentation fault.
  0x00007fffe801645b in ?? ()
  (gdb) disassemble
  No function contains program counter for selected frame.

  It looks like this is a known qemu regression after v8.1.1:
  https://gitlab.com/qemu-project/qemu/-/issues/1913

  Downgrading the package to qemu-user-
  static_8.0.4+dfsg-1ubuntu3_amd64.deb fixes the segfault.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/2072564/+subscriptions


ChatGPT said:
toml
Copy
Edit
id = 10000
title = "qemu-aarch64-static segfaults running ldconfig.real (amd64 host)"
state = "closed"
created_at = "n/a"
closed_at = "2025-03-13T17:18:50+01:00"
labels = ["accel: TCG", "target: arm", "linux-user", "elfload"]
url = "https://bugs.launchpad.net/qemu/+bug/2072564"
host-os = "Ubuntu 24.04"
host-arch = "amd64"
qemu-version = "1:8.2.2+ds-0ubuntu1"
guest-os = "Ubuntu 22.04"
guest-arch = "arm64"
description = """QEMU crashes when running ldconfig.real in an Ubuntu 22.04 arm64 guest under emulation with qemu-aarch64-static on an amd64 host. The issue is due to incorrect alignment handling in the ELF loader, resulting in a segmentation fault."""
reproduce = """1. Run a docker container with Ubuntu 22.04 on an amd64 host using `--platform linux/arm64/v8`.
2. Execute `/sbin/ldconfig.real` inside the container.
3. Observe the segmentation fault."""
additional = """Upstream bug: https://gitlab.com/qemu-project/qemu/-/issues/1913
Upstream fix: https://gitlab.com/qemu-project/qemu/-/commit/4b7b20a3
Dependency fix: https://gitlab.com/qemu-project/qemu/-/commit/c81d1faf"""






You said:
Do the same for the next thread. Additionally, add the variable 'mistranslation' with the values 'yes' or 'no', depending on whether the bug is a semantic mistranslation.

On Tue, Apr 29, 2025 at 01:55:59PM +0800, Xiaoyao Li wrote:
> Date: Tue, 29 Apr 2025 13:55:59 +0800
> From: Xiaoyao Li <xiaoyao.li@intel.com>
> Subject: Re: [Bug] QEMU TCG warnings after commit c6bd2dd63420 - HTT /
>  CMP_LEG bits
> 
> On 4/29/2025 11:02 AM, Ewan Hai wrote:
> > Hi Community,
> > 
> > This email contains 3 bugs appear to share the same root cause.
> > 
> > [1] We ran into the following warnings when running QEMU v10.0.0 in TCG
> > mode:
> > 
> > qemu-system-x86_64 \
> >    -machine q35 \
> >    -m 4G -smp 4 \
> >    -kernel ./arch/x86/boot/bzImage \
> >    -bios /usr/share/ovmf/OVMF.fd \
> >    -drive file=~/kernel/rootfs.ext4,index=0,format=raw,media=disk \
> >    -drive file=~/kernel/swap.img,index=1,format=raw,media=disk \
> >    -nographic \
> >    -append 'root=/dev/sda rw resume=/dev/sdb console=ttyS0 nokaslr'
> > 
> > qemu-system-x86_64: warning: TCG doesn't support requested feature:
> > CPUID.01H:EDX.ht [bit 28]
> > qemu-system-x86_64: warning: TCG doesn't support requested feature:
> > CPUID.80000001H:ECX.cmp-legacy [bit 1]
> > (repeats 4 times, once per vCPU)
> > 
> > Tracing the history shows that commit c6bd2dd63420 "i386/cpu: Set up
> > CPUID_HT in x86_cpu_expand_features() instead of cpu_x86_cpuid()" is
> > what introduced the warnings.
> > 
> > Since that commit, TCG unconditionally advertises HTT (CPUID 1 EDX[28])
> > and CMP_LEG (CPUID 8000_0001 ECX[1]). Because TCG itself has no SMT
> > support, these bits trigger the warnings above.
> > 
> > [2] Also, Zhao pointed me to a similar report on GitLab:
> > https://gitlab.com/qemu-project/qemu/-/issues/2894
> > The symptoms there look identical to what we're seeing.
> > 
> > By convention we file one issue per email, but these two appear to share
> > the same root cause, so I'm describing them together here.
> 
> It was caused by my two patches. I think the fix can be as follow.
> If no objection from the community, I can submit the formal patch.
> 
> diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> index 1f970aa4daa6..fb95aadd6161 100644
> --- a/target/i386/cpu.c
> +++ b/target/i386/cpu.c
> @@ -776,11 +776,12 @@ void x86_cpu_vendor_words2str(char *dst, uint32_t
> vendor1,
>            CPUID_PAE | CPUID_MCE | CPUID_CX8 | CPUID_APIC | CPUID_SEP | \
>            CPUID_MTRR | CPUID_PGE | CPUID_MCA | CPUID_CMOV | CPUID_PAT | \
>            CPUID_PSE36 | CPUID_CLFLUSH | CPUID_ACPI | CPUID_MMX | \
> -          CPUID_FXSR | CPUID_SSE | CPUID_SSE2 | CPUID_SS | CPUID_DE)
> +          CPUID_FXSR | CPUID_SSE | CPUID_SSE2 | CPUID_SS | CPUID_DE | \
> +          CPUID_HT)
>            /* partly implemented:
>            CPUID_MTRR, CPUID_MCA, CPUID_CLFLUSH (needed for Win64) */
>            /* missing:
> -          CPUID_VME, CPUID_DTS, CPUID_SS, CPUID_HT, CPUID_TM, CPUID_PBE */
> +          CPUID_VME, CPUID_DTS, CPUID_SS, CPUID_TM, CPUID_PBE */
> 
>  /*
>   * Kernel-only features that can be shown to usermode programs even if
> @@ -848,7 +849,8 @@ void x86_cpu_vendor_words2str(char *dst, uint32_t
> vendor1,
> 
>  #define TCG_EXT3_FEATURES (CPUID_EXT3_LAHF_LM | CPUID_EXT3_SVM | \
>            CPUID_EXT3_CR8LEG | CPUID_EXT3_ABM | CPUID_EXT3_SSE4A | \
> -          CPUID_EXT3_3DNOWPREFETCH | CPUID_EXT3_KERNEL_FEATURES)
> +          CPUID_EXT3_3DNOWPREFETCH | CPUID_EXT3_KERNEL_FEATURES | \
> +          CPUID_EXT3_CMP_LEG)
> 
>  #define TCG_EXT4_FEATURES 0

This fix is fine for me...at least from SDM, HTT depends on topology and
it should exist when user sets "-smp 4".

> > [3] My colleague Alan noticed what appears to be a related problem: if
> > we launch a guest with '-cpu <model>,-ht --enable-kvm', which means
> > explicitly removing the ht flag, but the guest still reports HT(cat
> > /proc/cpuinfo in linux guest) enabled. In other words, under KVM the ht
> > bit seems to be forced on even when the user tries to disable it.
> 
> XiaoYao reminded me that issue [3] stems from a different patch. Please
> ignore it for now—I'll start a separate thread to discuss that one
> independently.

I haven't found any other thread :-).

By the way, just curious, in what cases do you need to disbale the HT
flag? "-smp 4" means 4 cores with 1 thread per core, and is it not
enough?

As for the “-ht” behavior, I'm also unsure whether this should be fixed
or not - one possible consideration is whether “-ht” would be useful.

On Tue, Apr 29, 2025 at 01:55:59PM +0800, Xiaoyao Li wrote:
> Date: Tue, 29 Apr 2025 13:55:59 +0800
> From: Xiaoyao Li <xiaoyao.li@intel.com>
> Subject: Re: [Bug] QEMU TCG warnings after commit c6bd2dd63420 - HTT /
>  CMP_LEG bits
> 
> On 4/29/2025 11:02 AM, Ewan Hai wrote:
> > Hi Community,
> > 
> > This email contains 3 bugs appear to share the same root cause.
> > 
> > [1] We ran into the following warnings when running QEMU v10.0.0 in TCG
> > mode:
> > 
> > qemu-system-x86_64 \
> >    -machine q35 \
> >    -m 4G -smp 4 \
> >    -kernel ./arch/x86/boot/bzImage \
> >    -bios /usr/share/ovmf/OVMF.fd \
> >    -drive file=~/kernel/rootfs.ext4,index=0,format=raw,media=disk \
> >    -drive file=~/kernel/swap.img,index=1,format=raw,media=disk \
> >    -nographic \
> >    -append 'root=/dev/sda rw resume=/dev/sdb console=ttyS0 nokaslr'
> > 
> > qemu-system-x86_64: warning: TCG doesn't support requested feature:
> > CPUID.01H:EDX.ht [bit 28]
> > qemu-system-x86_64: warning: TCG doesn't support requested feature:
> > CPUID.80000001H:ECX.cmp-legacy [bit 1]
> > (repeats 4 times, once per vCPU)
> > 
> > Tracing the history shows that commit c6bd2dd63420 "i386/cpu: Set up
> > CPUID_HT in x86_cpu_expand_features() instead of cpu_x86_cpuid()" is
> > what introduced the warnings.
> > 
> > Since that commit, TCG unconditionally advertises HTT (CPUID 1 EDX[28])
> > and CMP_LEG (CPUID 8000_0001 ECX[1]). Because TCG itself has no SMT
> > support, these bits trigger the warnings above.
> > 
> > [2] Also, Zhao pointed me to a similar report on GitLab:
> > https://gitlab.com/qemu-project/qemu/-/issues/2894
> > The symptoms there look identical to what we're seeing.
> > 
> > By convention we file one issue per email, but these two appear to share
> > the same root cause, so I'm describing them together here.
> 
> It was caused by my two patches. I think the fix can be as follow.
> If no objection from the community, I can submit the formal patch.
> 
> diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> index 1f970aa4daa6..fb95aadd6161 100644
> --- a/target/i386/cpu.c
> +++ b/target/i386/cpu.c
> @@ -776,11 +776,12 @@ void x86_cpu_vendor_words2str(char *dst, uint32_t
> vendor1,
>            CPUID_PAE | CPUID_MCE | CPUID_CX8 | CPUID_APIC | CPUID_SEP | \
>            CPUID_MTRR | CPUID_PGE | CPUID_MCA | CPUID_CMOV | CPUID_PAT | \
>            CPUID_PSE36 | CPUID_CLFLUSH | CPUID_ACPI | CPUID_MMX | \
> -          CPUID_FXSR | CPUID_SSE | CPUID_SSE2 | CPUID_SS | CPUID_DE)
> +          CPUID_FXSR | CPUID_SSE | CPUID_SSE2 | CPUID_SS | CPUID_DE | \
> +          CPUID_HT)
>            /* partly implemented:
>            CPUID_MTRR, CPUID_MCA, CPUID_CLFLUSH (needed for Win64) */
>            /* missing:
> -          CPUID_VME, CPUID_DTS, CPUID_SS, CPUID_HT, CPUID_TM, CPUID_PBE */
> +          CPUID_VME, CPUID_DTS, CPUID_SS, CPUID_TM, CPUID_PBE */
> 
>  /*
>   * Kernel-only features that can be shown to usermode programs even if
> @@ -848,7 +849,8 @@ void x86_cpu_vendor_words2str(char *dst, uint32_t
> vendor1,
> 
>  #define TCG_EXT3_FEATURES (CPUID_EXT3_LAHF_LM | CPUID_EXT3_SVM | \
>            CPUID_EXT3_CR8LEG | CPUID_EXT3_ABM | CPUID_EXT3_SSE4A | \
> -          CPUID_EXT3_3DNOWPREFETCH | CPUID_EXT3_KERNEL_FEATURES)
> +          CPUID_EXT3_3DNOWPREFETCH | CPUID_EXT3_KERNEL_FEATURES | \
> +          CPUID_EXT3_CMP_LEG)
> 
>  #define TCG_EXT4_FEATURES 0

This fix is fine for me...at least from SDM, HTT depends on topology and
it should exist when user sets "-smp 4".

> > [3] My colleague Alan noticed what appears to be a related problem: if
> > we launch a guest with '-cpu <model>,-ht --enable-kvm', which means
> > explicitly removing the ht flag, but the guest still reports HT(cat
> > /proc/cpuinfo in linux guest) enabled. In other words, under KVM the ht
> > bit seems to be forced on even when the user tries to disable it.
> 
> XiaoYao reminded me that issue [3] stems from a different patch. Please
> ignore it for now—I'll start a separate thread to discuss that one
> independently.

I haven't found any other thread :-).

By the way, just curious, in what cases do you need to disbale the HT
flag? "-smp 4" means 4 cores with 1 thread per core, and is it not
enough?

As for the “-ht” behavior, I'm also unsure whether this should be fixed
or not - one possible consideration is whether “-ht” would be useful.


ChatGPT said:
Here’s a structured JSON extraction of the bug information from the email thread, with the new "mistranslation" field added:

json
Copy
Edit
[
  {
    "id": 1,
    "mode": "TCG",
    "cpu_flags": ["CPUID.01H:EDX.ht [bit 28]", "CPUID.80000001H:ECX.cmp-legacy [bit 1]"],
    "symptom": "QEMU shows warnings that TCG doesn't support requested features HTT and CMP_LEG",
    "introduced_by_commit": "c6bd2dd63420",
    "cause": "HTT and CMP_LEG are now unconditionally advertised by TCG after the commit, but TCG has no SMT support",
    "related_issues": ["https://gitlab.com/qemu-project/qemu/-/issues/2894"],
    "fix_proposed": true,
    "fix_details": "Patch to conditionally advertise HTT and CMP_LEG features based on capability",
    "mistranslation": "no"
  },
  {
    "id": 2,
    "mode": "KVM",
    "cpu_flags": ["-ht"],
    "symptom": "Guest reports HT enabled even when the ht flag is explicitly disabled",
    "introduced_by_commit": null,
    "cause": "Different patch (not detailed in this thread); HT bit appears forced on under KVM",
    "related_issues": [],
    "fix_proposed": false,
    "fix_details": "Will be discussed in a separate thread",
    "mistranslation": "yes"
  }
]
Explanation of "mistranslation" field:
Bug 1 is not a semantic mistranslation—it’s a configuration logic error where unsupported features are incorrectly exposed. Hence, "mistranslation": "no".

Bug 2 is a semantic mistranslation—the software allows the user to remove a flag (-ht) but internally contradicts that request by still enabling the feature. This mismatch between user intent and actual behavior is a semantic mistranslation. Hence, "mistranslation": "yes".

Let me know if you want these grouped or exported in another format.