rename llm dir

2 files changed, 0 insertions, 1209 deletions

diff --git a/llm/chatgpt b/llm/chatgpt
deleted file mode 100644
index b178ca90..00000000
--- a/llm/chatgpt
+++ /dev/null
@@ -1,553 +0,0 @@
-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.
diff --git a/llm/deepseek b/llm/deepseek
deleted file mode 100644
index 674b9d60..00000000
--- a/llm/deepseek
+++ /dev/null
@@ -1,656 +0,0 @@
-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"
-
------------------------------------------------------------------------------------------
-
-yes
-
-no
-
------------------------------------------------------------------------------------------
-
-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. Additionally, add a 'mistranslation' variable, which is set to 'yes', if the bug is a mistranslation bug, and 'no', if not. First Thread:
-
-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.
-
------------------------------------------------------------------------------------------
-
-toml
-[[issue]]
-id = 10000
-title = "QEMU TCG warnings after commit c6bd2dd63420 - HTT / CMP_LEG bits"
-state = "closed"
-created_at = "2025-04-29T11:02:00.000Z"
-closed_at = "n/a"
-labels = ["accel: TCG", "target: i386"]
-url = "n/a"
-host-os = "n/a"
-host-arch = "x86"
-qemu-version = "10.0.0"
-guest-os = "Linux"
-guest-arch = "x86"
-description = """TCG unconditionally advertises HTT (CPUID 1 EDX[28]) and CMP_LEG (CPUID 8000_0001 ECX[1]) despite lacking SMT support, causing warnings."""
-reproduce = """Run QEMU in TCG mode with a Linux guest and observe CPUID-related warnings."""
-additional = """Related to GitLab issue #2894. Fix involves adjusting CPU feature flags in target/i386/cpu.c."""
-mistranslation = "no"
-
-[[issue]]
-id = 10001
-title = "KVM forces HT flag even when explicitly disabled"
-state = "open"
-created_at = "2025-04-29T11:02:00.000Z"
-closed_at = "n/a"
-labels = ["accel: KVM", "target: i386"]
-url = "n/a"
-host-os = "n/a"
-host-arch = "x86"
-qemu-version = "10.0.0"
-guest-os = "Linux"
-guest-arch = "x86"
-description = """When launching a guest with '-cpu <model>,-ht --enable-kvm', the HT flag remains enabled in /proc/cpuinfo."""
-reproduce = """Launch a KVM guest with HT explicitly disabled and check CPU flags."""
-additional = """Separate issue from the TCG warnings. Discussion pending in another thread."""
-mistranslation = "no"
-Second 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
-
------------------------------------------------------------------------------------------
-
-toml
-[[issue]]
-id = 10002
-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", "ubuntu"]
-url = "https://bugs.launchpad.net/bugs/2072564"
-host-os = "Ubuntu 24.04+"
-host-arch = "amd64"
-qemu-version = "1:9.0.2+ds-4ubuntu5.3"
-guest-os = "Ubuntu 22.04 (arm64)"
-guest-arch = "arm64"
-description = """QEMU crashes when running ldconfig in an emulated arm64 guest, affecting qemu-user-static on amd64 hosts."""
-reproduce = """Run 'ldconfig.real' in an emulated arm64 container or via qemu-aarch64-static."""
-additional = """Upstream bug: https://gitlab.com/qemu-project/qemu/-/issues/1913. Fixed by ELF alignment patches."""
-mistranslation = "no"
-Third Thread:
-Hi, all
-
-When I did the cxl memory hot-plug test on QEMU, I accidentally connected 
-two memdev to the same downstream port, the command like below:
-
-> -object memory-backend-ram,size=262144k,share=on,id=vmem0 \
-> -object memory-backend-ram,size=262144k,share=on,id=vmem1 \
-> -device pxb-cxl,bus_nr=12,bus=pcie.0,id=cxl.1 \
-> -device cxl-rp,port=0,bus=cxl.1,id=root_port0,chassis=0,slot=0 \
-> -device cxl-upstream,bus=root_port0,id=us0 \
-> -device cxl-downstream,port=0,bus=us0,id=swport00,chassis=0,slot=5 \
-> -device cxl-downstream,port=0,bus=us0,id=swport01,chassis=0,slot=7 \
-same downstream port but has different slot!
-
-> -device cxl-type3,bus=swport00,volatile-memdev=vmem0,id=cxl-vmem0 \
-> -device cxl-type3,bus=swport01,volatile-memdev=vmem1,id=cxl-vmem1 \
-> -M 
-> cxl-fmw.0.targets.0=cxl.1,cxl-fmw.0.size=64G,cxl-fmw.0.interleave-granularity=4k
->  \
-
-There is no error occurred when vm start, but when I executed the “cxl list” 
-command to view
-the CXL objects info, the process can not end properly.
-
-Then I used strace to trace the process, I found that the process is in 
-infinity loop:
-# strace cxl list
-......
-clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=1000000}, NULL) = 0
-openat(AT_FDCWD, "/sys/bus/cxl/flush", O_WRONLY|O_CLOEXEC) = 3
-write(3, "1\n\0", 3)                    = 3
-close(3)                                = 0
-access("/run/udev/queue", F_OK)         = 0
-clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=1000000}, NULL) = 0
-openat(AT_FDCWD, "/sys/bus/cxl/flush", O_WRONLY|O_CLOEXEC) = 3
-write(3, "1\n\0", 3)                    = 3
-close(3)                                = 0
-access("/run/udev/queue", F_OK)         = 0
-clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=1000000}, NULL) = 0
-openat(AT_FDCWD, "/sys/bus/cxl/flush", O_WRONLY|O_CLOEXEC) = 3
-write(3, "1\n\0", 3)                    = 3
-close(3)                                = 0
-access("/run/udev/queue", F_OK)         = 0
-clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=1000000}, NULL) = 0
-openat(AT_FDCWD, "/sys/bus/cxl/flush", O_WRONLY|O_CLOEXEC) = 3
-write(3, "1\n\0", 3)                    = 3
-close(3)                                = 0
-access("/run/udev/queue", F_OK)         = 0
-clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=1000000}, NULL) = 0
-openat(AT_FDCWD, "/sys/bus/cxl/flush", O_WRONLY|O_CLOEXEC) = 3
-write(3, "1\n\0", 3)                    = 3
-close(3)                                = 0
-access("/run/udev/queue", F_OK)         = 0
-clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=1000000}, NULL) = 0
-openat(AT_FDCWD, "/sys/bus/cxl/flush", O_WRONLY|O_CLOEXEC) = 3
-write(3, "1\n\0", 3)                    = 3
-close(3)                                = 0
-access("/run/udev/queue", F_OK)         = 0
-clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=1000000}, NULL) = 0
-openat(AT_FDCWD, "/sys/bus/cxl/flush", O_WRONLY|O_CLOEXEC) = 3
-write(3, "1\n\0", 3)                    = 3
-close(3)                                = 0
-access("/run/udev/queue", F_OK)         = 0
-clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=1000000}, NULL) = 0
-openat(AT_FDCWD, "/sys/bus/cxl/flush", O_WRONLY|O_CLOEXEC) = 3
-write(3, "1\n\0", 3)                    = 3
-close(3)                                = 0
-access("/run/udev/queue", F_OK)         = 0
-
-[Environment]:
-linux: V6.10-rc3
-QEMU: V9.0.0
-ndctl: v79
-
-I know this is because of the wrong use of the QEMU command, but I think we 
-should 
-be aware of this error in one of the QEMU, OS or ndctl side at least.
-
-Thanks
-Xingtao
-
------------------------------------------------------------------------------------------
-
-toml
-[[issue]]
-id = 10003
-title = "CXL memory hot-plug with incorrect configuration causes infinite loop in 'cxl list'"
-state = "open"
-created_at = "n/a"
-closed_at = "n/a"
-labels = ["device: cxl", "bug"]
-url = "n/a"
-host-os = "n/a"
-host-arch = "n/a"
-qemu-version = "9.0.0"
-guest-os = "Linux (v6.10-rc3)"
-guest-arch = "n/a"
-description = """When incorrectly connecting two memdevs to the same CXL downstream port, 'cxl list' command enters infinite loop."""
-reproduce = """1. Configure CXL with two memdevs on same downstream port (different slots)
-2. Start VM
-3. Run 'cxl list' command"""
-additional = """Environment: QEMU v9.0.0, Linux v6.10-rc3, ndctl v79. Issue occurs despite incorrect configuration - should be caught by either QEMU, OS or ndctl."""
-mistranslation = "no"
-Fourth Thread:
-[SRU] migration was active, but no RAM info was set
-[Impact]
-
- * While live-migrating many instances concurrently, libvirt sometimes return `internal error: migration was active, but no RAM info was set:`
-
- * Effects of this bug are mostly observed in large scale clusters with a lot of live migration activity.
-
- * Has second order effects for consumers of migration monitor such as libvirt and openstack.
-
-[Test Case]
-
-Synthetic reproducer with GDB in comment #21.
-
-Steps to Reproduce:
-1. live evacuate a compute
-2. live migration of one or more instances fails with the above error
-
-N.B Due to the nature of this bug it is difficult consistently reproduce.
-In an environment where it has been observed it is estimated to occur approximately 1/1000 migrations.
-
-[Where problems could occur]
- * In the event of a regression the migration monitor may report an inconsistent state.
-
-[Original Bug Description]
-
-While live-migrating many instances concurrently, libvirt sometimes return internal error: migration was active, but no RAM info was set:
-~~~
-2022-03-30 06:08:37.197 7 WARNING nova.virt.libvirt.driver [req-5c3296cf-88ee-4af6-ae6a-ddba99935e23 - - - - -] [instance: af339c99-1182-4489-b15c-21e52f50f724] Error monitoring migration: internal error: migration was active, but no RAM info was set: libvirt.libvirtError: internal error: migration was active, but no RAM info was set
-[Impact]
-
- * While live-migrating many instances concurrently, libvirt sometimes return `internal error: migration was active, but no RAM info was set:`
-
- * Effects of this bug are mostly observed in large scale clusters with a lot of live migration activity.
-
- * Has second order effects for consumers of migration monitor such as libvirt and openstack.
-
-[Test Case]
-
-Synthetic reproducer with GDB in comment #21.
-
-Steps to Reproduce:
-1. live evacuate a compute
-2. live migration of one or more instances fails with the above error
-
-N.B Due to the nature of this bug it is difficult consistently reproduce.
-In an environment where it has been observed it is estimated to occur approximately 1/1000 migrations.
-
-[Where problems could occur]
- * In the event of a regression the migration monitor may report an inconsistent state.
-
-[Original Bug Description]
-
-While live-migrating many instances concurrently, libvirt sometimes return internal error: migration was active, but no RAM info was set:
-~~~
-2022-03-30 06:08:37.197 7 WARNING nova.virt.libvirt.driver [req-5c3296cf-88ee-4af6-ae6a-ddba99935e23 - - - - -] [instance: af339c99-1182-4489-b15c-21e52f50f724] Error monitoring migration: internal error: migration was active, but no RAM info was set: libvirt.libvirtError: internal error: migration was active, but no RAM info was set
-toml
-[[issue]]
-id = 10004
-title = "Migration active but no RAM info set during concurrent live migrations"
-state = "open"
-created_at = "n/a"
-closed_at = "n/a"
-labels = ["migration", "libvirt", "openstack"]
-url = "n/a"
-host-os = "n/a"
-host-arch = "n/a"
-qemu-version = "n/a"
-guest-os = "n/a"
-guest-arch = "n/a"
-description = """During concurrent live migrations, libvirt reports 'migration was active, but no RAM info was set' error intermittently"""
-reproduce = """1. Perform live evacuation of compute node
-2. Observe failure in approximately 1/1000 migrations with error message
-3. Synthetic reproducer available via GDB in comments"""
-additional = """Affects large scale clusters with heavy migration activity. Impacts libvirt and OpenStack migration monitoring. Difficult to reproduce consistently."""
-mistranslation = "no"