From 3e4c5a6261770bced301b5e74233e7866166ea5b Mon Sep 17 00:00:00 2001
From: Christian Krinitsin <mail@krinitsin.com>
Date: Sun, 1 Jun 2025 21:35:14 +0200
Subject: clean up repository

---
 .../target_i386/host_missing/accel_HAX/325         |    1 -
 .../target_i386/host_missing/accel_HVF/1067        |   84 --
 .../target_i386/host_missing/accel_HVF/150         |    1 -
 .../target_i386/host_missing/accel_HVF/155         |    1 -
 .../target_i386/host_missing/accel_HVF/1603        |   73 --
 .../target_i386/host_missing/accel_HVF/2938        |   11 -
 .../target_i386/host_missing/accel_HVF/664         |   14 -
 .../target_i386/host_missing/accel_HVF/886         |   16 -
 .../target_i386/host_missing/accel_KVM/1004        |    9 -
 .../target_i386/host_missing/accel_KVM/1008        |   20 -
 .../target_i386/host_missing/accel_KVM/1021        |    9 -
 .../target_i386/host_missing/accel_KVM/1045        |   26 -
 .../target_i386/host_missing/accel_KVM/1068        |   11 -
 .../target_i386/host_missing/accel_KVM/1069        |   13 -
 .../target_i386/host_missing/accel_KVM/1133        |   10 -
 .../target_i386/host_missing/accel_KVM/1198        |   53 -
 .../target_i386/host_missing/accel_KVM/1217        |  130 --
 .../target_i386/host_missing/accel_KVM/1306        |  159 ---
 .../target_i386/host_missing/accel_KVM/131         |    1 -
 .../target_i386/host_missing/accel_KVM/1484        |   29 -
 .../target_i386/host_missing/accel_KVM/180         |    1 -
 .../target_i386/host_missing/accel_KVM/1966        |    8 -
 .../target_i386/host_missing/accel_KVM/2003        |   15 -
 .../target_i386/host_missing/accel_KVM/2007        |   29 -
 .../target_i386/host_missing/accel_KVM/2037        |   15 -
 .../target_i386/host_missing/accel_KVM/217         |    1 -
 .../target_i386/host_missing/accel_KVM/2325        |   11 -
 .../target_i386/host_missing/accel_KVM/2361        |   13 -
 .../target_i386/host_missing/accel_KVM/2394        |   29 -
 .../target_i386/host_missing/accel_KVM/2429        |   29 -
 .../target_i386/host_missing/accel_KVM/2502        |   13 -
 .../target_i386/host_missing/accel_KVM/2571        |   66 -
 .../target_i386/host_missing/accel_KVM/2572        |   30 -
 .../target_i386/host_missing/accel_KVM/2582        |   23 -
 .../target_i386/host_missing/accel_KVM/2612        |   82 --
 .../target_i386/host_missing/accel_KVM/2622        |  267 -----
 .../target_i386/host_missing/accel_KVM/2669        |   18 -
 .../target_i386/host_missing/accel_KVM/2731        |  344 ------
 .../target_i386/host_missing/accel_KVM/2956        |  214 ----
 .../target_i386/host_missing/accel_KVM/352         |    1 -
 .../target_i386/host_missing/accel_KVM/353         |    1 -
 .../target_i386/host_missing/accel_KVM/361         |    1 -
 .../target_i386/host_missing/accel_KVM/466         |    1 -
 .../target_i386/host_missing/accel_KVM/530         |   43 -
 .../target_i386/host_missing/accel_KVM/674         |   14 -
 .../target_i386/host_missing/accel_KVM/742         |   44 -
 .../target_i386/host_missing/accel_KVM/755         |   59 -
 .../target_i386/host_missing/accel_KVM/772         |   12 -
 .../target_i386/host_missing/accel_KVM/777         |    9 -
 .../target_i386/host_missing/accel_KVM/916         |   11 -
 .../target_i386/host_missing/accel_KVM/954         | 1257 --------------------
 .../target_i386/host_missing/accel_TCG/1023        |   60 -
 .../target_i386/host_missing/accel_TCG/1059        |   10 -
 .../target_i386/host_missing/accel_TCG/1143        |   78 --
 .../target_i386/host_missing/accel_TCG/125         |    1 -
 .../target_i386/host_missing/accel_TCG/1269        |   26 -
 .../target_i386/host_missing/accel_TCG/130         |    1 -
 .../target_i386/host_missing/accel_TCG/132         |    1 -
 .../target_i386/host_missing/accel_TCG/1324        |   40 -
 .../target_i386/host_missing/accel_TCG/1350        |   89 --
 .../target_i386/host_missing/accel_TCG/1370        |   13 -
 .../target_i386/host_missing/accel_TCG/1371        |   19 -
 .../target_i386/host_missing/accel_TCG/1372        |   20 -
 .../target_i386/host_missing/accel_TCG/1373        |   20 -
 .../target_i386/host_missing/accel_TCG/1374        |   22 -
 .../target_i386/host_missing/accel_TCG/1375        |   19 -
 .../target_i386/host_missing/accel_TCG/1376        |   15 -
 .../target_i386/host_missing/accel_TCG/1377        |   14 -
 .../target_i386/host_missing/accel_TCG/1471        |   16 -
 .../target_i386/host_missing/accel_TCG/1478        |   66 -
 .../target_i386/host_missing/accel_TCG/1506        |    1 -
 .../target_i386/host_missing/accel_TCG/1517        |    1 -
 .../target_i386/host_missing/accel_TCG/1637        |    1 -
 .../target_i386/host_missing/accel_TCG/164         |    1 -
 .../target_i386/host_missing/accel_TCG/1661        |   11 -
 .../target_i386/host_missing/accel_TCG/1803        |   14 -
 .../target_i386/host_missing/accel_TCG/1808        |   71 --
 .../target_i386/host_missing/accel_TCG/1826        |   29 -
 .../target_i386/host_missing/accel_TCG/1832        |    1 -
 .../target_i386/host_missing/accel_TCG/1834        |  184 ---
 .../target_i386/host_missing/accel_TCG/184         |    1 -
 .../target_i386/host_missing/accel_TCG/1864        |   21 -
 .../target_i386/host_missing/accel_TCG/1964        |    7 -
 .../target_i386/host_missing/accel_TCG/2022        |   11 -
 .../target_i386/host_missing/accel_TCG/2040        |   24 -
 .../target_i386/host_missing/accel_TCG/2092        |   70 --
 .../target_i386/host_missing/accel_TCG/2096        |    1 -
 .../target_i386/host_missing/accel_TCG/215         |    1 -
 .../target_i386/host_missing/accel_TCG/2170        |   44 -
 .../target_i386/host_missing/accel_TCG/2175        |   38 -
 .../target_i386/host_missing/accel_TCG/2180        |   36 -
 .../target_i386/host_missing/accel_TCG/2195        |   39 -
 .../target_i386/host_missing/accel_TCG/2198        |   25 -
 .../target_i386/host_missing/accel_TCG/2206        |   10 -
 .../target_i386/host_missing/accel_TCG/2207        |   11 -
 .../target_i386/host_missing/accel_TCG/2220        |  528 --------
 .../target_i386/host_missing/accel_TCG/2302        |   25 -
 .../target_i386/host_missing/accel_TCG/2380        |  105 --
 .../target_i386/host_missing/accel_TCG/2474        |   96 --
 .../target_i386/host_missing/accel_TCG/2489        |   92 --
 .../target_i386/host_missing/accel_TCG/249         |    1 -
 .../target_i386/host_missing/accel_TCG/2495        |   72 --
 .../target_i386/host_missing/accel_TCG/2511        |   32 -
 .../target_i386/host_missing/accel_TCG/2567        |   78 --
 .../target_i386/host_missing/accel_TCG/2578        |   14 -
 .../target_i386/host_missing/accel_TCG/2581        |   12 -
 .../target_i386/host_missing/accel_TCG/2599        |    1 -
 .../target_i386/host_missing/accel_TCG/2605        |    1 -
 .../target_i386/host_missing/accel_TCG/265         |    1 -
 .../target_i386/host_missing/accel_TCG/279         |    1 -
 .../target_i386/host_missing/accel_TCG/2821        |   23 -
 .../target_i386/host_missing/accel_TCG/286         |    1 -
 .../target_i386/host_missing/accel_TCG/2878        |    1 -
 .../target_i386/host_missing/accel_TCG/2891        |    1 -
 .../target_i386/host_missing/accel_TCG/314         |    1 -
 .../target_i386/host_missing/accel_TCG/318         |    1 -
 .../target_i386/host_missing/accel_TCG/330         |    1 -
 .../target_i386/host_missing/accel_TCG/380         |    1 -
 .../target_i386/host_missing/accel_TCG/382         |    1 -
 .../target_i386/host_missing/accel_TCG/394         |    1 -
 .../target_i386/host_missing/accel_TCG/404         |    1 -
 .../target_i386/host_missing/accel_TCG/420         |    1 -
 .../target_i386/host_missing/accel_TCG/427         |    1 -
 .../target_i386/host_missing/accel_TCG/505         |   12 -
 .../target_i386/host_missing/accel_TCG/509         |    1 -
 .../target_i386/host_missing/accel_TCG/601         |   20 -
 .../target_i386/host_missing/accel_TCG/619         |    1 -
 .../target_i386/host_missing/accel_TCG/661         |   44 -
 .../target_i386/host_missing/accel_TCG/67          |    1 -
 .../target_i386/host_missing/accel_TCG/676         |   54 -
 .../target_i386/host_missing/accel_TCG/683         |    1 -
 .../target_i386/host_missing/accel_TCG/766         |   27 -
 .../target_i386/host_missing/accel_TCG/824         |   12 -
 .../target_i386/host_missing/accel_TCG/83          |    1 -
 .../target_i386/host_missing/accel_TCG/844         |   44 -
 .../target_i386/host_missing/accel_TCG/870         |   12 -
 .../target_i386/host_missing/accel_TCG/888         |    7 -
 .../target_i386/host_missing/accel_TCG/973         |   19 -
 .../target_i386/host_missing/accel_TCG/984         |   23 -
 .../target_i386/host_missing/accel_TCG/993         |   81 --
 .../target_i386/host_missing/accel_WHPX/1031       |   42 -
 .../target_i386/host_missing/accel_WHPX/1043       |   10 -
 .../target_i386/host_missing/accel_WHPX/1137       |   35 -
 .../target_i386/host_missing/accel_WHPX/2063       |   55 -
 .../target_i386/host_missing/accel_WHPX/2403       |   14 -
 .../target_i386/host_missing/accel_WHPX/2782       |   10 -
 .../target_i386/host_missing/accel_WHPX/346        |    1 -
 .../target_i386/host_missing/accel_WHPX/513        |    1 -
 .../target_i386/host_missing/accel_WHPX/934        |   45 -
 .../target_i386/host_missing/accel_WHPX/977        |    1 -
 .../target_i386/host_missing/accel_Xen/2294        |    1 -
 .../target_i386/host_missing/accel_missing/101     |    1 -
 .../target_i386/host_missing/accel_missing/1017    |   13 -
 .../target_i386/host_missing/accel_missing/1035    |   16 -
 .../target_i386/host_missing/accel_missing/1040    |    6 -
 .../target_i386/host_missing/accel_missing/1041    |   31 -
 .../target_i386/host_missing/accel_missing/1042    |   20 -
 .../target_i386/host_missing/accel_missing/1047    |  104 --
 .../target_i386/host_missing/accel_missing/1098    |   11 -
 .../target_i386/host_missing/accel_missing/1115    |   14 -
 .../target_i386/host_missing/accel_missing/1131    |   20 -
 .../target_i386/host_missing/accel_missing/1135    |   12 -
 .../target_i386/host_missing/accel_missing/116     |    1 -
 .../target_i386/host_missing/accel_missing/1164    |   17 -
 .../target_i386/host_missing/accel_missing/1267    |   93 --
 .../target_i386/host_missing/accel_missing/1279    |    8 -
 .../target_i386/host_missing/accel_missing/1298    |   15 -
 .../target_i386/host_missing/accel_missing/1323    |   17 -
 .../target_i386/host_missing/accel_missing/1328    |    9 -
 .../target_i386/host_missing/accel_missing/1348    |    1 -
 .../target_i386/host_missing/accel_missing/1368    |   38 -
 .../target_i386/host_missing/accel_missing/1382    |   40 -
 .../target_i386/host_missing/accel_missing/1383    |    1 -
 .../target_i386/host_missing/accel_missing/1396    |    3 -
 .../target_i386/host_missing/accel_missing/141     |    1 -
 .../target_i386/host_missing/accel_missing/1410    |   14 -
 .../target_i386/host_missing/accel_missing/1437    |    6 -
 .../target_i386/host_missing/accel_missing/1472    |    5 -
 .../target_i386/host_missing/accel_missing/1473    |    1 -
 .../target_i386/host_missing/accel_missing/1476    |    1 -
 .../target_i386/host_missing/accel_missing/1492    |  292 -----
 .../target_i386/host_missing/accel_missing/1524    |   37 -
 .../target_i386/host_missing/accel_missing/1533    |    1 -
 .../target_i386/host_missing/accel_missing/1534    |    1 -
 .../target_i386/host_missing/accel_missing/1570    |   63 -
 .../target_i386/host_missing/accel_missing/1628    |  130 --
 .../target_i386/host_missing/accel_missing/1648    |   58 -
 .../target_i386/host_missing/accel_missing/1762    |   83 --
 .../target_i386/host_missing/accel_missing/189     |    1 -
 .../target_i386/host_missing/accel_missing/191     |    1 -
 .../target_i386/host_missing/accel_missing/1919    |   20 -
 .../target_i386/host_missing/accel_missing/192     |    1 -
 .../target_i386/host_missing/accel_missing/1932    |   12 -
 .../target_i386/host_missing/accel_missing/1947    |   20 -
 .../target_i386/host_missing/accel_missing/1952    |   96 --
 .../target_i386/host_missing/accel_missing/1956    |    1 -
 .../target_i386/host_missing/accel_missing/1986    |   14 -
 .../target_i386/host_missing/accel_missing/1998    |   27 -
 .../target_i386/host_missing/accel_missing/2008    |   12 -
 .../target_i386/host_missing/accel_missing/2020    |   11 -
 .../target_i386/host_missing/accel_missing/2064    |   12 -
 .../target_i386/host_missing/accel_missing/2070    |    9 -
 .../target_i386/host_missing/accel_missing/2079    |    1 -
 .../target_i386/host_missing/accel_missing/2218    |   12 -
 .../target_i386/host_missing/accel_missing/223     |    1 -
 .../target_i386/host_missing/accel_missing/2244    |   46 -
 .../target_i386/host_missing/accel_missing/2263    |   28 -
 .../target_i386/host_missing/accel_missing/2266    |   69 --
 .../target_i386/host_missing/accel_missing/2270    |    1 -
 .../target_i386/host_missing/accel_missing/2320    |    1 -
 .../target_i386/host_missing/accel_missing/2330    |   73 --
 .../target_i386/host_missing/accel_missing/2334    |  252 ----
 .../target_i386/host_missing/accel_missing/237     |    1 -
 .../target_i386/host_missing/accel_missing/2381    |    3 -
 .../target_i386/host_missing/accel_missing/2383    |    3 -
 .../target_i386/host_missing/accel_missing/2393    |   20 -
 .../target_i386/host_missing/accel_missing/2420    |   44 -
 .../target_i386/host_missing/accel_missing/2426    |    1 -
 .../target_i386/host_missing/accel_missing/243     |    1 -
 .../target_i386/host_missing/accel_missing/2452    |    1 -
 .../target_i386/host_missing/accel_missing/2509    |   26 -
 .../target_i386/host_missing/accel_missing/2520    |   11 -
 .../target_i386/host_missing/accel_missing/2530    |   17 -
 .../target_i386/host_missing/accel_missing/2555    |   20 -
 .../target_i386/host_missing/accel_missing/2556    |   12 -
 .../target_i386/host_missing/accel_missing/2562    |   52 -
 .../target_i386/host_missing/accel_missing/2583    |   25 -
 .../target_i386/host_missing/accel_missing/2586    |    3 -
 .../target_i386/host_missing/accel_missing/2590    |   23 -
 .../target_i386/host_missing/accel_missing/2593    |   57 -
 .../target_i386/host_missing/accel_missing/2594    |   35 -
 .../target_i386/host_missing/accel_missing/2597    |    1 -
 .../target_i386/host_missing/accel_missing/2616    |   11 -
 .../target_i386/host_missing/accel_missing/2626    |    8 -
 .../target_i386/host_missing/accel_missing/2631    |   81 --
 .../target_i386/host_missing/accel_missing/2654    |   14 -
 .../target_i386/host_missing/accel_missing/2657    |   11 -
 .../target_i386/host_missing/accel_missing/2666    |   22 -
 .../target_i386/host_missing/accel_missing/267     |    1 -
 .../target_i386/host_missing/accel_missing/2739    |    3 -
 .../target_i386/host_missing/accel_missing/2769    |    3 -
 .../target_i386/host_missing/accel_missing/2779    |   41 -
 .../target_i386/host_missing/accel_missing/2783    |   17 -
 .../target_i386/host_missing/accel_missing/2813    |    9 -
 .../target_i386/host_missing/accel_missing/2816    |   14 -
 .../target_i386/host_missing/accel_missing/2817    |   51 -
 .../target_i386/host_missing/accel_missing/2832    |   99 --
 .../target_i386/host_missing/accel_missing/2833    |   19 -
 .../target_i386/host_missing/accel_missing/2834    |   19 -
 .../target_i386/host_missing/accel_missing/2848    |   13 -
 .../target_i386/host_missing/accel_missing/2868    |    3 -
 .../target_i386/host_missing/accel_missing/2869    |    3 -
 .../target_i386/host_missing/accel_missing/2874    |    9 -
 .../target_i386/host_missing/accel_missing/2882    |   90 --
 .../target_i386/host_missing/accel_missing/2892    |    1 -
 .../target_i386/host_missing/accel_missing/2894    |   25 -
 .../target_i386/host_missing/accel_missing/2897    |   14 -
 .../target_i386/host_missing/accel_missing/2922    |    7 -
 .../target_i386/host_missing/accel_missing/2954    |   19 -
 .../target_i386/host_missing/accel_missing/2961    |   31 -
 .../target_i386/host_missing/accel_missing/2987    |    7 -
 .../target_i386/host_missing/accel_missing/320     |    1 -
 .../target_i386/host_missing/accel_missing/331     |    1 -
 .../target_i386/host_missing/accel_missing/368     |    1 -
 .../target_i386/host_missing/accel_missing/375     |    1 -
 .../target_i386/host_missing/accel_missing/387     |    1 -
 .../target_i386/host_missing/accel_missing/389     |    1 -
 .../target_i386/host_missing/accel_missing/475     |    1 -
 .../target_i386/host_missing/accel_missing/508     |    1 -
 .../target_i386/host_missing/accel_missing/510     |    1 -
 .../target_i386/host_missing/accel_missing/512     |    1 -
 .../target_i386/host_missing/accel_missing/525     |   14 -
 .../target_i386/host_missing/accel_missing/536     |    1 -
 .../target_i386/host_missing/accel_missing/538     |    1 -
 .../target_i386/host_missing/accel_missing/554     |    1 -
 .../target_i386/host_missing/accel_missing/561     |    1 -
 .../target_i386/host_missing/accel_missing/627     |    7 -
 .../target_i386/host_missing/accel_missing/629     |   10 -
 .../target_i386/host_missing/accel_missing/641     |    1 -
 .../target_i386/host_missing/accel_missing/673     |   10 -
 .../target_i386/host_missing/accel_missing/705     |   27 -
 .../target_i386/host_missing/accel_missing/745     |   36 -
 .../target_i386/host_missing/accel_missing/752     |   13 -
 .../target_i386/host_missing/accel_missing/77      |    1 -
 .../target_i386/host_missing/accel_missing/770     |    1 -
 .../target_i386/host_missing/accel_missing/771     |   14 -
 .../target_i386/host_missing/accel_missing/78      |    1 -
 .../target_i386/host_missing/accel_missing/780     |   54 -
 .../target_i386/host_missing/accel_missing/786     |   17 -
 .../target_i386/host_missing/accel_missing/791     |    1 -
 .../target_i386/host_missing/accel_missing/810     |   71 --
 .../target_i386/host_missing/accel_missing/837     |   30 -
 .../target_i386/host_missing/accel_missing/855     |   17 -
 .../target_i386/host_missing/accel_missing/871     |   14 -
 .../target_i386/host_missing/accel_missing/877     |  106 --
 .../target_i386/host_missing/accel_missing/91      |    1 -
 .../target_i386/host_missing/accel_missing/921     |  623 ----------
 .../target_i386/host_missing/accel_missing/928     |   84 --
 .../target_i386/host_missing/accel_missing/930     |    1 -
 .../target_i386/host_missing/accel_missing/975     |   38 -
 .../target_i386/host_missing/accel_missing/990     |    1 -
 301 files changed, 10297 deletions(-)
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_HAX/325
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_HVF/1067
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_HVF/150
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_HVF/155
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_HVF/1603
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_HVF/2938
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_HVF/664
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_HVF/886
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_KVM/1004
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_KVM/1008
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_KVM/1021
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_KVM/1045
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_KVM/1068
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_KVM/1069
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_KVM/1133
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_KVM/1198
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_KVM/1217
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_KVM/1306
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_KVM/131
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_KVM/1484
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_KVM/180
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_KVM/1966
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_KVM/2003
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_KVM/2007
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_KVM/2037
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_KVM/217
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_KVM/2325
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_KVM/2361
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_KVM/2394
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_KVM/2429
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_KVM/2502
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_KVM/2571
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_KVM/2572
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_KVM/2582
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_KVM/2612
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_KVM/2622
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_KVM/2669
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_KVM/2731
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_KVM/2956
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_KVM/352
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_KVM/353
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_KVM/361
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_KVM/466
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_KVM/530
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_KVM/674
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_KVM/742
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_KVM/755
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_KVM/772
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_KVM/777
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_KVM/916
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_KVM/954
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_TCG/1023
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_TCG/1059
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_TCG/1143
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_TCG/125
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_TCG/1269
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_TCG/130
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_TCG/132
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_TCG/1324
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_TCG/1350
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_TCG/1370
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_TCG/1371
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_TCG/1372
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_TCG/1373
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_TCG/1374
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_TCG/1375
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_TCG/1376
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_TCG/1377
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_TCG/1471
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_TCG/1478
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_TCG/1506
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_TCG/1517
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_TCG/1637
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_TCG/164
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_TCG/1661
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_TCG/1803
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_TCG/1808
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_TCG/1826
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_TCG/1832
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_TCG/1834
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_TCG/184
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_TCG/1864
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_TCG/1964
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_TCG/2022
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_TCG/2040
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_TCG/2092
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_TCG/2096
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_TCG/215
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_TCG/2170
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_TCG/2175
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_TCG/2180
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_TCG/2195
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_TCG/2198
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_TCG/2206
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_TCG/2207
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_TCG/2220
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_TCG/2302
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_TCG/2380
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_TCG/2474
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_TCG/2489
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_TCG/249
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_TCG/2495
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_TCG/2511
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_TCG/2567
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_TCG/2578
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_TCG/2581
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_TCG/2599
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_TCG/2605
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_TCG/265
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_TCG/279
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_TCG/2821
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_TCG/286
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_TCG/2878
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_TCG/2891
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_TCG/314
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_TCG/318
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_TCG/330
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_TCG/380
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_TCG/382
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_TCG/394
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_TCG/404
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_TCG/420
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_TCG/427
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_TCG/505
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_TCG/509
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_TCG/601
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_TCG/619
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_TCG/661
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_TCG/67
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_TCG/676
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_TCG/683
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_TCG/766
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_TCG/824
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_TCG/83
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_TCG/844
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_TCG/870
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_TCG/888
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_TCG/973
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_TCG/984
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_TCG/993
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_WHPX/1031
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_WHPX/1043
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_WHPX/1137
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_WHPX/2063
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_WHPX/2403
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_WHPX/2782
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_WHPX/346
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_WHPX/513
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_WHPX/934
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_WHPX/977
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_Xen/2294
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/101
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/1017
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/1035
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/1040
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/1041
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/1042
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/1047
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/1098
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/1115
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/1131
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/1135
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/116
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/1164
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/1267
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/1279
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/1298
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/1323
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/1328
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/1348
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/1368
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/1382
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/1383
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/1396
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/141
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/1410
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/1437
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/1472
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/1473
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/1476
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/1492
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/1524
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/1533
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/1534
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/1570
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/1628
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/1648
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/1762
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/189
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/191
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/1919
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/192
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/1932
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/1947
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/1952
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/1956
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/1986
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/1998
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/2008
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/2020
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/2064
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/2070
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/2079
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/2218
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/223
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/2244
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/2263
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/2266
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/2270
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/2320
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/2330
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/2334
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/237
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/2381
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/2383
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/2393
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/2420
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/2426
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/243
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/2452
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/2509
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/2520
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/2530
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/2555
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/2556
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/2562
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/2583
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/2586
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/2590
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/2593
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/2594
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/2597
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/2616
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/2626
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/2631
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/2654
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/2657
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/2666
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/267
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/2739
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/2769
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/2779
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/2783
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/2813
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/2816
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/2817
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/2832
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/2833
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/2834
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/2848
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/2868
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/2869
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/2874
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/2882
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/2892
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/2894
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/2897
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/2922
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/2954
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/2961
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/2987
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/320
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/331
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/368
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/375
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/387
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/389
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/475
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/508
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/510
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/512
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/525
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/536
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/538
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/554
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/561
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/627
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/629
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/641
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/673
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/705
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/745
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/752
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/77
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/770
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/771
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/78
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/780
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/786
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/791
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/810
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/837
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/855
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/871
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/877
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/91
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/921
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/928
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/930
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/975
 delete mode 100644 gitlab/issues_text/target_i386/host_missing/accel_missing/990

(limited to 'gitlab/issues_text/target_i386/host_missing')

diff --git a/gitlab/issues_text/target_i386/host_missing/accel_HAX/325 b/gitlab/issues_text/target_i386/host_missing/accel_HAX/325
deleted file mode 100644
index fd9365c5e..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_HAX/325
+++ /dev/null
@@ -1 +0,0 @@
-Latest QEMU crashes when switching color depth of ReactOS
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_HVF/1067 b/gitlab/issues_text/target_i386/host_missing/accel_HVF/1067
deleted file mode 100644
index fd91c3be1..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_HVF/1067
+++ /dev/null
@@ -1,84 +0,0 @@
-SSH QEMU ISSUE by using with MacOs
-Description of problem:
-ssh connection between Qemu Image and Guest Host (MacOS) broken down after few minutes
-Steps to reproduce:
-1. Take the Qemu window and external ssh connection to backround, \
-   wait until few minutes and the connection are frozen. \
-   If we clicking to qemu window again, the ssh connection are available
-Additional information:
-The ssh connection settings by Macos: \
-Host * \
-AddKeysToAgent yes \
-IdentityFile ~/.ssh/id_rsa \
-IdentitiesOnly yes \
-ServerAliveInterval 3600 \
-TCPKeepAlive yes \
-ServerAliveCountMax 2 \
-\
-\
-SSH connection settings by Ubuntu Server:
-
-Include /etc/ssh/sshd_config.d/*.conf \
-\
-#Port 22 \
-#AddressFamily any \
-#ListenAddress 0.0.0.0 \
-#ListenAddress :: \
-#HostKey /etc/ssh/ssh_host_rsa_key \
-#HostKey /etc/ssh/ssh_host_ecdsa_key \
-#HostKey /etc/ssh/ssh_host_ed25519_key \
-#RekeyLimit default none \
-#SyslogFacility AUTH \
-#LogLevel INFO \
-#LoginGraceTime 2m \
-#PermitRootLogin prohibit-password \
-#StrictModes yes \
-#MaxAuthTries 6 \
-#MaxSessions 10 \
-#PubkeyAuthentication yes \
-#Expect .ssh/authorized_keys2 to be disregarded by default in future. \
-#AuthorizedKeysFile	.ssh/authorized_keys .ssh/authorized_keys2 \
-#AuthorizedPrincipalsFile none \
-#AuthorizedKeysCommand none \
-#AuthorizedKeysCommandUser nobody \
-#HostbasedAuthentication no \
-#IgnoreUserKnownHosts no \
-#IgnoreRhosts yes \
-#PasswordAuthentication yes \
-#PermitEmptyPasswords no \
-ChallengeResponseAuthentication no \
-#KerberosAuthentication no \
-#KerberosOrLocalPasswd yes \
-#KerberosTicketCleanup yes \
-#KerberosGetAFSToken no \
-#GSSAPIAuthentication no \
-#GSSAPICleanupCredentials yes \
-#GSSAPIStrictAcceptorCheck yes \
-#GSSAPIKeyExchange no \
-UsePAM yes \
-#AllowAgentForwarding yes \
-#AllowTcpForwarding yes \
-#GatewayPorts no \
-X11Forwarding yes \
-#X11DisplayOffset 10 \
-#X11UseLocalhost yes \
-#PermitTTY yes \
-PrintMotd no \
-#PrintLastLog yes \
-#TCPKeepAlive yes \
-#PermitUserEnvironment no \
-#Compression delayed \
-#ClientAliveInterval 0 \
-#ClientAliveCountMax 3 \
-#UseDNS no \
-#PidFile /var/run/sshd.pid \
-#MaxStartups 10:30:100 \
-#PermitTunnel no \
-#ChrootDirectory none \
-#VersionAddendum none \
-#Banner none \
-AcceptEnv LANG LC_* \
-PasswordAuthentication yes \
-ClientAliveInterval 600 \
-TCPKeepAlive yes \
-ClientAliveCountMax 10 \
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_HVF/150 b/gitlab/issues_text/target_i386/host_missing/accel_HVF/150
deleted file mode 100644
index dbbe08265..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_HVF/150
+++ /dev/null
@@ -1 +0,0 @@
-Illegal Instruction with HVF when encountering SSE instructions in the emulator
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_HVF/155 b/gitlab/issues_text/target_i386/host_missing/accel_HVF/155
deleted file mode 100644
index 8471bf984..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_HVF/155
+++ /dev/null
@@ -1 +0,0 @@
-MMX emulation is missing on HVF Acceleration
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_HVF/1603 b/gitlab/issues_text/target_i386/host_missing/accel_HVF/1603
deleted file mode 100644
index be6410412..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_HVF/1603
+++ /dev/null
@@ -1,73 +0,0 @@
-Regression in v8.0.0-rc1: `Abort trap: 6` during `hvf/x86_emu.c:exec_mov()` (`-cpu host` + UEFI)
-Description of problem:
-`qemu-system-x86_64 -accel hvf -cpu host -drive <UEFI>` crashes.
-Steps to reproduce:
-```console
-$ qemu-system-x86_64 -accel hvf -cpu host -drive if=pflash,format=raw,readonly=on,file=/usr/local/share/qemu/edk2-x86_64-code.fd 
-vmx_read_mem: mmu_gva_to_gpa ffc00000 failed
-Abort trap: 6
-```
-Additional information:
-This is a regression in v8.0.0-rc1.
-
-- v8.0.0-rc0: works
-- v8.0.0-rc1: crashes
-- ...
-- v8.0.0-rc4: crashes
-
-
-Backtrace:
-```console
-$ lldb /usr/local/bin/qemu-system-x86_64 
-(lldb) target create "/usr/local/bin/qemu-system-x86_64"
-Current executable set to '/usr/local/bin/qemu-system-x86_64' (x86_64).
-(lldb) process handle SIGUSR2 -s false -p true
-NAME         PASS     STOP     NOTIFY
-===========  =======  =======  =======
-SIGUSR2      true     false    not set
-(lldb) run  -accel hvf -cpu host -drive if=pflash,format=raw,readonly=on,file=/usr/local/share/qemu/edk2-x86_64-code.fd
-Process 17627 launched: '/usr/local/bin/qemu-system-x86_64' (x86_64)
-Process 17627 stopped and restarted: thread 1 received signal: SIGUSR2
-Process 17627 stopped and restarted: thread 1 received signal: SIGUSR2
-Process 17627 stopped and restarted: thread 1 received signal: SIGUSR2
-Process 17627 stopped and restarted: thread 1 received signal: SIGUSR2
-Process 17627 stopped and restarted: thread 1 received signal: SIGUSR2
-Process 17627 stopped and restarted: thread 1 received signal: SIGUSR2
-Process 17627 stopped and restarted: thread 1 received signal: SIGUSR2
-Process 17627 stopped and restarted: thread 1 received signal: SIGUSR2
-Process 17627 stopped and restarted: thread 1 received signal: SIGUSR2
-Process 17627 stopped and restarted: thread 1 received signal: SIGUSR2
-Process 17627 stopped and restarted: thread 1 received signal: SIGUSR2
-Process 17627 stopped and restarted: thread 1 received signal: SIGUSR2
-Process 17627 stopped and restarted: thread 1 received signal: SIGUSR2
-Process 17627 stopped and restarted: thread 1 received signal: SIGUSR2
-Process 17627 stopped and restarted: thread 1 received signal: SIGUSR2
-Process 17627 stopped and restarted: thread 1 received signal: SIGUSR2
-2023-04-14 17:16:22.879194+0900 qemu-system-x86_64[17627:1529741] [Window] Warning: Window NSWindow 0x10391def0 ordered front from a non-active application and may order beneath the active application's windows.
-vmx_read_mem: mmu_gva_to_gpa ffc00000 failed
-Process 17627 stopped
-* thread #4, stop reason = signal SIGABRT
-    frame #0: 0x00007ff8121331f2 libsystem_kernel.dylib`__pthread_kill + 10
-libsystem_kernel.dylib`:
-->  0x7ff8121331f2 <+10>: jae    0x7ff8121331fc            ; <+20>
-    0x7ff8121331f4 <+12>: movq   %rax, %rdi
-    0x7ff8121331f7 <+15>: jmp    0x7ff81212ccdb            ; cerror_nocancel
-    0x7ff8121331fc <+20>: retq   
-Target 0: (qemu-system-x86_64) stopped.
-(lldb) bt
-* thread #4, stop reason = signal SIGABRT
-  * frame #0: 0x00007ff8121331f2 libsystem_kernel.dylib`__pthread_kill + 10
-    frame #1: 0x00007ff81216aee6 libsystem_pthread.dylib`pthread_kill + 263
-    frame #2: 0x00007ff812091b45 libsystem_c.dylib`abort + 123
-    frame #3: 0x0000000100223608 qemu-system-x86_64`vmx_read_mem + 201
-    frame #4: 0x000000010021fa5b qemu-system-x86_64`read_val_ext + 65
-    frame #5: 0x000000010021fc02 qemu-system-x86_64`fetch_operands + 197
-    frame #6: 0x0000000100220f8b qemu-system-x86_64`exec_mov + 31
-    frame #7: 0x0000000100220f01 qemu-system-x86_64`exec_instruction + 48
-    frame #8: 0x000000010021c81f qemu-system-x86_64`hvf_vcpu_exec + 4144
-    frame #9: 0x000000010033fa53 qemu-system-x86_64`hvf_cpu_thread_fn + 270
-    frame #10: 0x0000000100492e49 qemu-system-x86_64`qemu_thread_start + 130
-    frame #11: 0x00007ff81216b1d3 libsystem_pthread.dylib`_pthread_start + 125
-    frame #12: 0x00007ff812166bd3 libsystem_pthread.dylib`thread_start + 15
-(lldb) 
-```
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_HVF/2938 b/gitlab/issues_text/target_i386/host_missing/accel_HVF/2938
deleted file mode 100644
index 0ffa4769d..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_HVF/2938
+++ /dev/null
@@ -1,11 +0,0 @@
-10.0.0 HVF x86_64 regression: can't boot NetBSD 10.1 with -smp 2
-Description of problem:
-Under 9.2.3, a NetBSD/amd64 10.1 guest with `-smp 2` booted and ran fine.
-
-Under 10.0.0, the same guest never finishes loading the kernel. It looks like it's retrying many times per second, possibly even reloading the NetBSD boot loader each time, though it's redrawing so fast I can't tell for sure. (I'll attempt to link to an asciinema capture shortly.) `-smp 1` lets the machine come up.
-
-For comparison, a NetBSD/aarch64 10.1 with `-smp 4` runs with `-accel hvf` under macOS/aarch64 15.4.1 just as well with 10.0.0 as it did with 9.2.3.
-Steps to reproduce:
-1. With x86 macOS host and NetBSD guest (possibly a wider range than the exact versions I'm currently using), attempt to boot NetBSD with `-smp 2`
-Additional information:
-
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_HVF/664 b/gitlab/issues_text/target_i386/host_missing/accel_HVF/664
deleted file mode 100644
index 5f8de9c2f..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_HVF/664
+++ /dev/null
@@ -1,14 +0,0 @@
-hvf-accelerated x86_64 incorrectly reports virtual address bit width via CPUID
-Description of problem:
-When running qemu-system-x86_64 with hvf acceleration enabled the maximum extended cpuid function (available via EAX=0x80000000) is reported to be 0x80000001, which means that physical address and virtual address bit width (which is supposed to be reported via EAX=0x80000008) is not available. As per the intel IA32/64 manual: `Processors that do not support CPUID function 80000008H, support a linear-address width of 32.`, while in actuality qemu-system-x86_64 with hvf acceleration supports virtual addresses of up to 48 bit in width, like most modern x86_64 processors.
-Steps to reproduce:
-This can be observed when running SerenityOS on x86_64 qemu with hvf acceleration based on the following dmesg lines:
-```
-[Kernel]: CPU[0]: Physical address bit width: 36
-[Kernel]: CPU[0]: Virtual address bit width: 32
-```
-But can also be reproduced by running the CPUID instruction with EAX set to 0x80000000 and observing that the returned value is 0x80000001.
-Additional information:
-The best way to resolve this as far as I can tell is to expose the 0x80000008 CPUID function and report the real values.
-
-NOTE: This is a report of the underlying bug that was found during the investigation of an issue raised in the SerenityOS repository, see https://github.com/SerenityOS/serenity/issues/10382 for more information.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_HVF/886 b/gitlab/issues_text/target_i386/host_missing/accel_HVF/886
deleted file mode 100644
index a5fc28406..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_HVF/886
+++ /dev/null
@@ -1,16 +0,0 @@
-OpenIndiana panics when using -accel hvf
-Description of problem:
-OpenIndiana panics on boot.
-
-```
-Loading unix...
-Loading /platform/i86pc/amd64/boot_archive...
-Loading /platform/i86pc/amd64/boot_archive.hash...
-Booting...
-OpenIndiana Hipster 2021.10 Version illumos-79a6379db8 64-bit
-
-panic[cpu0]/thread=fffffffffbc49060:
-```
-Steps to reproduce:
-1. Run given command
-2. Wait
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_KVM/1004 b/gitlab/issues_text/target_i386/host_missing/accel_KVM/1004
deleted file mode 100644
index ce7f2089e..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_KVM/1004
+++ /dev/null
@@ -1,9 +0,0 @@
-qemu-system-i386 peggs 100% host CPU
-Description of problem:
-Before the guest OS even starts up, the host CPU eggs at 100%.
-Steps to reproduce:
-1. Start any VM using qemu-system-i386
-2. On Ubuntu use Virt Manager or command line.
-3. On macOS use UTM.
-Additional information:
-
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_KVM/1008 b/gitlab/issues_text/target_i386/host_missing/accel_KVM/1008
deleted file mode 100644
index 1bf267959..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_KVM/1008
+++ /dev/null
@@ -1,20 +0,0 @@
-nested virtualisation with old host kernel, qemu 7.0.0 broken
-Description of problem:
-```
-$ qemu-system-x86_64 -enable-kvm -nographic
-qemu-system-x86_64: error: failed to set MSR 0xc0000104 to 0x100000000
-qemu-system-x86_64: ../target/i386/kvm/kvm.c:2996: kvm_buf_set_msrs: Assertion `ret == cpu->kvm_msr_buf->nmsrs' failed.
-Aborted (core dumped)
-
-$
-```
-Steps to reproduce:
-1. (hardware) Host 1 running kernel 5.10 with nested kvm enabled
-2. (virtual) Host 2, with qemu 7.0.0 installed
-3. In the inner/virtual host, run: `qemu-system-x86 -enable-kvm -nographic`
-Additional information:
-It is fixed by using either a more up-to-date kernel version on the hardware/outer host (5.17.x for example), or by reverting to qemu 6.2.0 in the virtual/inner host.
-
-I have also reproduced this with latest qemu master, commit 731340813fdb4cb8339edb8630e3f923b7d987ec.
-
-**Reverting commit 3e4546d5bd38a1e98d4bd2de48631abf0398a3a2 also fixes the issue.**
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_KVM/1021 b/gitlab/issues_text/target_i386/host_missing/accel_KVM/1021
deleted file mode 100644
index 9410805b1..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_KVM/1021
+++ /dev/null
@@ -1,9 +0,0 @@
-nVMX: QEMU does not clear nVMX state through KVM(L0) when guest(L2) trigger a reboot event through I/O-Port(0xCF9)
-Description of problem:
-#
-Steps to reproduce:
-Guest(L2) write 0xCF9 to trigger a platform reboot.
-
-#
-Additional information:
-
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_KVM/1045 b/gitlab/issues_text/target_i386/host_missing/accel_KVM/1045
deleted file mode 100644
index cfb4524a4..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_KVM/1045
+++ /dev/null
@@ -1,26 +0,0 @@
-When a break point is set, nested virtualization sees "kvm_queue_exception: Assertion `!env->exception_has_payload' failed."
-Description of problem:
-I am debugging XMHF and LHV using QEMU + KVM. I found that if I set a break point using GDB, QEMU will crash when LHV is booting. The message is
-```
-qemu-system-i386: ../../../target/i386/kvm/kvm.c:678: kvm_queue_exception: Assertion `!env->exception_has_payload' failed.
-```
-
-The address of the break point is arbitrary. The break point does not need to hit. So I chose 0 as the address in this bug report.
-Steps to reproduce:
-1. Start QEMU using `qemu-system-i386 -m 512M -gdb tcp::1234 -smp 2 -cpu Haswell,vmx=yes -enable-kvm -serial stdio -drive media=disk,file=1.img,index=1 -drive media=disk,file=2.img,index=2 -S`
-2. In another shell, start GDB using `gdb --ex 'target remote :::1234' --ex 'hb *0' --ex c`
-3. See many serial output lines. The tail of the output is
-    ```
-    CPU #0: vcpu_vaddr_ptr=0x01e06080, esp=0x01e11000
-    CPU #1: vcpu_vaddr_ptr=0x01e06540, esp=0x01e15000
-    BSP(0x00): Rallying APs...
-    BSP(0x00): APs ready, doing DRTM...
-    LAPIC base and status=0xfee00900
-    Sending INIT IPI to all APs...
-    ```
-4. See assertion error in QEMU
-    ```
-    qemu-system-i386: ../target/i386/kvm/kvm.c:645: kvm_queue_exception: Assertion `!env->exception_has_payload' failed.
-    ```
-Additional information:
-This bug was first incorrectly filed in KVM's bug tracker at <https://bugzilla.kernel.org/show_bug.cgi?id=216002>.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_KVM/1068 b/gitlab/issues_text/target_i386/host_missing/accel_KVM/1068
deleted file mode 100644
index 6a6af675a..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_KVM/1068
+++ /dev/null
@@ -1,11 +0,0 @@
-VMs stuck loading Kernel "Freeing unused Kernel image (initmem) memory" with host running Vanilla Kernel >= 5.18.0
-Description of problem:
-The VMs are stuck after "Freeing unused Kernel image (initmem) memory"  
-See attached screen recording.  
-Rebooting the host with Kernel 5.17.13 solves the problem.
-Steps to reproduce:
-1. Boot host with Kernel >= 5.18.0
-2. Start VM
-Additional information:
-[bug.log](/uploads/faa14ac0bf84a21beb2ffeeb650df4b9/bug.log)
-[qemu-libvirt-host-kernel-5.18.2.mkv](/uploads/87a064f171833e9fb3d46fd3ece32152/qemu-libvirt-host-kernel-5.18.2.mkv)
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_KVM/1069 b/gitlab/issues_text/target_i386/host_missing/accel_KVM/1069
deleted file mode 100644
index 0634db6c4..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_KVM/1069
+++ /dev/null
@@ -1,13 +0,0 @@
-Qemu triggers the split lock detection of the Linux kernel
-Description of problem:
-Windows displays a "blue screen of death" and the Linux kernel logs this error message:
-
-```
-[  180.886150] x86/split lock detection: #AC: qemu-system-x86/10167 took a split_lock trap at address: 0x3ff2624d
-[  180.946151] x86/split lock detection: #AC: qemu-system-x86/10168 took a split_lock trap at address: 0x3ff2624d
-```
-Steps to reproduce:
-1. Start the guest OS
-2. Do some stuff in the Windows guest (for instance OS updates)
-Additional information:
-Is this a bug in Windows or in Qemu ?
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_KVM/1133 b/gitlab/issues_text/target_i386/host_missing/accel_KVM/1133
deleted file mode 100644
index 8fe0446b2..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_KVM/1133
+++ /dev/null
@@ -1,10 +0,0 @@
-unused memory filled with 0x00 instead of 0xFF
-Description of problem:
-Qemu, ever since it was made (so, since 2003), has this problem in DOS (either PC-DOS or MS-DOS and partly Windows 9x) not recognizing the memory available when the memory is filled with 0x00 but when it is filled with 0xFF it gets recognized properly, where should I patch qemu to solve this memory problem?
-
-Refer to
-https://bugs.launchpad.net/qemu/+bug/1180923
-Steps to reproduce:
-1.
-2.
-3.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_KVM/1198 b/gitlab/issues_text/target_i386/host_missing/accel_KVM/1198
deleted file mode 100644
index bb52ed618..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_KVM/1198
+++ /dev/null
@@ -1,53 +0,0 @@
-Windows 11 Guest keeps crashing with abort in cpu_asidx_from_attrs
-Steps to reproduce:
-1. Create Windows 11 guest, SWTPM, SECBOOT (haven't tested without since this is not an option for installing Windows 11)
-2. Use OS
-3. Will eventually crash. Have tried across multiple kernels 5.17, 5.18, 5.19
-Additional information:
-```
-
-               Stack trace of thread 76223:
-                #0  0x00007f24072d44dc n/a (libc.so.6 + 0x884dc)
-                #1  0x00007f2407284998 raise (libc.so.6 + 0x38998)
-                #2  0x00007f240726e53d abort (libc.so.6 + 0x2253d)
-                #3  0x00007f240726e45c n/a (libc.so.6 + 0x2245c)
-                #4  0x00007f240727d4c6 __assert_fail (libc.so.6 + 0x314c6)
-                #5  0x0000555681a35101 cpu_asidx_from_attrs (qemu-system-x86_64 + 0x572101)
-                #6  0x0000555681c6531e cpu_memory_rw_debug (qemu-system-x86_64 + 0x7a231e)
-                #7  0x0000555681bfb54a x86_cpu_dump_state (qemu-system-x86_64 + 0x73854a)
-                #8  0x0000555681d84a65 kvm_cpu_exec (qemu-system-x86_64 + 0x8c1a65)
-                #9  0x0000555681d85e48 kvm_vcpu_thread_fn (qemu-system-x86_64 + 0x8c2e48)
-                #10 0x0000555681fed0a8 qemu_thread_start (qemu-system-x86_64 + 0xb2a0a8)
-                #11 0x00007f24072d278d n/a (libc.so.6 + 0x8678d)
-                #12 0x00007f24073538e4 __clone (libc.so.6 + 0x1078e4)
-```
-
-
-```
-KVM: entry failed, hardware error 0x80000021
-
-If you're running a guest on an Intel machine without unrestricted mode
-support, the failure can be most likely due to the guest entering an invalid
-state for Intel VT. For example, the guest maybe running in big real mode
-which is not supported on less recent Intel processors.
-
-EAX=00000000 EBX=00000000 ECX=00000000 EDX=04c6d3e0
-ESI=12af7eb0 EDI=9e55d420 EBP=821b5aa0 ESP=10db0fb0
-EIP=00008000 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=1 HLT=0
-ES =0000 00000000 ffffffff 00809300
-CS =b500 7ffb5000 ffffffff 00809300
-SS =0000 00000000 ffffffff 00809300
-DS =0000 00000000 ffffffff 00809300
-FS =0000 00000000 ffffffff 00809300
-GS =0000 00000000 ffffffff 00809300
-LDT=0000 00000000 000fffff 00000000
-TR =0040 10d97000 00000067 00008b00
-GDT=     10d98fb0 00000057
-IDT=     00000000 00000000
-CR0=00050032 CR2=f80ff80c CR3=e47e7000 CR4=00000000
-DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 
-DR6=00000000ffff0ff0 DR7=0000000000000400
-EFER=0000000000000000
-Code=qemu-system-x86_64: ../qemu-7.0.0/hw/core/cpu-sysemu.c:77: cpu_asidx_from_attrs: Assertion `ret < cpu->num_ases && ret >= 0' failed.
-2022-09-06 14:48:15.392+0000: shutting down, reason=crashed
-```
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_KVM/1217 b/gitlab/issues_text/target_i386/host_missing/accel_KVM/1217
deleted file mode 100644
index 961b02991..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_KVM/1217
+++ /dev/null
@@ -1,130 +0,0 @@
-QEMU  6.2.0: Random segfaults when access register eax using qemu-system-x86_64
-Description of problem:
-coredump info:
-```
-(gdb) bt
-#0  0x0000152016187387 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:55
-#1  0x0000152016188a78 in __GI_abort () at abort.c:90
-#2  0x00001520159f2439 in os::abort (dump_core=<optimized out>)
-    at /usr/src/debug/java-1.8.0-openjdk-1.8.0.262.b10-0.el7_8.x86_64/openjdk/hotspot/src/os/linux/vm/os_linux.cpp:1572
-#3  0x0000152015c0e64a in VMError::report_and_die (this=this@entry=0x151fe009c4d0)
-    at /usr/src/debug/java-1.8.0-openjdk-1.8.0.262.b10-0.el7_8.x86_64/openjdk/hotspot/src/share/vm/utilities/vmError.cpp:1112
-#4  0x00001520159fc5e5 in JVM_handle_linux_signal (sig=11, info=0x151fe009c770, ucVoid=0x151fe009c640,
-    abort_if_unrecognized=<optimized out>)
-    at /usr/src/debug/java-1.8.0-openjdk-1.8.0.262.b10-0.el7_8.x86_64/openjdk/hotspot/src/os_cpu/linux_x86/vm/os_linux_x86.cpp:541
-#5  0x00001520159ef5f8 in signalHandler (sig=11, info=0x151fe009c770, uc=0x151fe009c640)
-    at /usr/src/debug/java-1.8.0-openjdk-1.8.0.262.b10-0.el7_8.x86_64/openjdk/hotspot/src/os/linux/vm/os_linux.cpp:4591
-#6  <signal handler called>
-#7  do_clone (pd=pd@entry=0x151fc7cfe700, attr=attr@entry=0x151fe009d410, stackaddr=<optimized out>,
-    stopped=<optimized out>, fct=0x152016b4fde0 <start_thread>, clone_flags=4001536)
-    at ../nptl/sysdeps/pthread/createthread.c:77
-#8  0x0000152016b5056a in create_thread (stackaddr=<optimized out>, attr=0x151fe009d410, pd=0x151fc7cfe700)
-    at ../nptl/sysdeps/pthread/createthread.c:244
-#9  __pthread_create_2_1 (newthread=<optimized out>, attr=<optimized out>, start_routine=<optimized out>,
-    arg=<optimized out>) at pthread_create.c:553
-#10 0x00001520159fb9b8 in os::create_thread (thread=0x561592f7f000, thr_type=<optimized out>,
----Type <return> to continue, or q <return> to quit---f 7
-    stack_size=<optimized out>)
-    at /usr/src/debug/java-1.8.0-openjdk-1.8.0.262.b10-0.el7_8.x86_64/openjdk/hotspot/src/os/linux/vm/os_linux.cpp:921
-#11 0x00001520157eea78 in JVM_StartThread (env=<optimized out>, jthread=0x151fe009d4d0)
-    at /usr/src/debug/java-1.8.0-openjdk-1.8.0.262.b10-0.el7_8.x86_64/openjdk/hotspot/src/share/vm/prims/jvm.cpp:3128
-#12 0x0000152001ef0c26 in ?? ()
-#13 0x00000006e100f538 in ?? ()
-#14 0x00000000de00bfff in ?? ()
-#15 0x0000151fe009d530 in ?? ()
-#16 0x0000152001915328 in ?? ()
-#17 0x00000006e100f538 in ?? ()
-#18 0x0000152010062550 in ?? ()
-#19 0x00000006f1450200 in ?? ()
-#20 0x00001520de280104 in ?? ()
-#21 0x0000000000000000 in ?? ()
-(gdb) f 7
-#7  do_clone (pd=pd@entry=0x151fc7cfe700, attr=attr@entry=0x151fe009d410, stackaddr=<optimized out>,
-    stopped=<optimized out>, fct=0x152016b4fde0 <start_thread>, clone_flags=4001536)
-    at ../nptl/sysdeps/pthread/createthread.c:77
-77        if (__builtin_expect (rc == -1, 0))
-(gdb) disas
-Dump of assembler code for function do_clone:
-   0x0000152016b4f010 <+0>:     push   %r12
-   0x0000152016b4f012 <+2>:     xor    %r12d,%r12d
-   0x0000152016b4f015 <+5>:     mov    %rdx,%r10
-   0x0000152016b4f018 <+8>:     push   %rbp
-   0x0000152016b4f019 <+9>:     mov    %rsi,%rbp
-   0x0000152016b4f01c <+12>:    push   %rbx
-   0x0000152016b4f01d <+13>:    mov    %rdi,%rbx
-   0x0000152016b4f020 <+16>:    sub    $0x10,%rsp
-   0x0000152016b4f024 <+20>:    test   %ecx,%ecx
-   0x0000152016b4f026 <+22>:    setne  %r12b
-   0x0000152016b4f02a <+26>:    jne    0x152016b4f07f <do_clone+111>
-   0x0000152016b4f02c <+28>:    lock incl 0x21022d(%rip)        # 0x152016d5f260 <__nptl_nthreads>
-   0x0000152016b4f033 <+35>:    lea    0x2d0(%rbx),%r8
-   0x0000152016b4f03a <+42>:    lea    0xd9f(%rip),%rdi        # 0x152016b4fde0 <start_thread>
-   0x0000152016b4f041 <+49>:    xor    %eax,%eax
-   0x0000152016b4f043 <+51>:    mov    %rbx,%r9
-   0x0000152016b4f046 <+54>:    mov    %rbx,%rcx
-   0x0000152016b4f049 <+57>:    mov    $0x3d0f00,%edx
-   0x0000152016b4f04e <+62>:    mov    %r8,(%rsp)
-   0x0000152016b4f052 <+66>:    mov    %r10,%rsi
-   0x0000152016b4f055 <+69>:    callq  0x152016b4d470 <__clone@plt>
-=> 0x0000152016b4f05a <+74>:    cmp    $0xffffffff,%eax
-   0x0000152016b4f05d <+77>:    je     0x152016b4f118 <do_clone+264>
----Type <return> to continue, or q <return> to quit---q
-Quit
-(gdb) p rc
-$1 = 223935
-(gdb) i r rax
-rax            0x36abf  223935
-(gdb) i r eax
-eax            0x0      0
-(gdb) l
-72        atomic_increment (&__nptl_nthreads);
-73
-74        int rc = ARCH_CLONE (fct, STACK_VARIABLES_ARGS, clone_flags,
-75                             pd, &pd->tid, TLS_VALUE, &pd->tid);
-76
-77        if (__builtin_expect (rc == -1, 0))
-78          {
-79            atomic_decrement (&__nptl_nthreads); /* Oops, we lied for a second.  */
-80
-81            /* Perhaps a thread wants to change the IDs and if waiting
-(gdb)
-```
-Additional information:
-```
-# cat test.c
-#include <stdlib.h>
-
-int main() {
-   int rc = test1();
-   if(__builtin_expect (rc == -1, 0)) {
-        return rc;
-   }
-
-  return 0;
-}
-# cat test_asm.s
-global test1
-section .text
-test1:
-      mov rax, 223935
-      ret
-
-(gdb) disas main
-Dump of assembler code for function main:
-   0x00000000004004f6 <+0>:     sub    $0x8,%rsp
-   0x00000000004004fa <+4>:     mov    $0x0,%eax
-   0x00000000004004ff <+9>:     callq  0x4004f0 <test1>
-   0x0000000000400504 <+14>:    cmp    $0xffffffff,%eax
-   0x0000000000400507 <+17>:    sete   %al
-   0x000000000040050a <+20>:    movzbl %al,%eax
-   0x000000000040050d <+23>:    neg    %eax
-   0x000000000040050f <+25>:    add    $0x8,%rsp
-   0x0000000000400513 <+29>:    retq
-End of assembler dump.
-...
-# set breakpoint at 0x0000000000400504 
-(gdb) i r eax
-eax            0x36abf  223935
-(gdb) i r rax
-rax            0x36abf  223935
-```
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_KVM/1306 b/gitlab/issues_text/target_i386/host_missing/accel_KVM/1306
deleted file mode 100644
index 2bcf220a5..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_KVM/1306
+++ /dev/null
@@ -1,159 +0,0 @@
-OpenIndiana fails with "BAD TRAP" & "Page fault" in guest with SATA optical drive
-Additional information:
-I am not experienced in QEMU, and have not been able to isolate with a simple command line. However, I will attempt any test cases provided by the community.
-
-The problem in the domain reproduced below resolves by removing the SATA optical drive (even if the SATA controller remains).
-
-The working case may be derived through the following patch:
-
-```
-1c1
-< <domain type='kvm' id='83'>
----
-> <domain type='kvm' id='82'>
-18a19
->     <boot dev='hd'/>
-42c43
-<       <source file='/srv/store/epl/img/OI-hipster-minimal-20211031.iso' index='2'/>
----
->       <source file='/srv/store/epl/img/OI-hipster-minimal-20211031.iso' index='1'/>
-46d46
-<       <boot order='1'/>
-48,54d47
-<       <address type='drive' controller='0' bus='0' target='0' unit='0'/>
-<     </disk>
-<     <disk type='file' device='cdrom'>
-<       <driver name='qemu'/>
-<       <target dev='sda' bus='sata'/>
-<       <readonly/>
-<       <alias name='sata0-0-0'/>
-```
-
-For consistency, the boot media is installed on an IDE optical drive, which appears not to cause problems. The problem was originally discovered attempting to boot from a SATA optical drive, following the intended layout of the guest system.
-
----
-
-```
-<domain type='kvm' id='84'>
-  <name>openindiana-clone</name>
-  <uuid>7a0550ec-ff03-4894-80b8-affe0dfd8177</uuid>
-  <metadata>
-    <libosinfo:libosinfo xmlns:libosinfo="http://libosinfo.org/xmlns/libvirt/domain/1.0">
-      <libosinfo:os id="http://oracle.com/solaris/11"/>
-    </libosinfo:libosinfo>
-  </metadata>
-  <memory unit='KiB'>2097152</memory>
-  <currentMemory unit='KiB'>2097152</currentMemory>
-  <vcpu placement='static'>4</vcpu>
-  <resource>
-    <partition>/machine</partition>
-  </resource>
-  <os>
-    <type arch='x86_64' machine='pc-i440fx-jammy'>hvm</type>
-    <loader readonly='yes' type='pflash'>/usr/share/OVMF/OVMF_CODE_4M.fd</loader>
-    <nvram template='/usr/share/OVMF/OVMF_VARS_4M.fd'>/var/lib/libvirt/qemu/nvram/openindiana-clone_VARS.fd</nvram>
-  </os>
-  <features>
-    <acpi/>
-    <apic/>
-    <vmport state='off'/>
-  </features>
-  <cpu mode='host-passthrough' check='none' migratable='on'/>
-  <clock offset='utc'>
-    <timer name='rtc' tickpolicy='catchup'/>
-    <timer name='pit' tickpolicy='delay'/>
-    <timer name='hpet' present='no'/>
-  </clock>
-  <on_poweroff>destroy</on_poweroff>
-  <on_reboot>restart</on_reboot>
-  <on_crash>destroy</on_crash>
-  <pm>
-    <suspend-to-mem enabled='no'/>
-    <suspend-to-disk enabled='no'/>
-  </pm>
-  <devices>
-    <emulator>/usr/bin/qemu-system-x86_64</emulator>
-    <disk type='file' device='cdrom'>
-      <driver name='qemu' type='raw'/>
-      <source file='/srv/img/OI-hipster-minimal-20211031.iso' index='2'/>
-      <backingStore/>
-      <target dev='hda' bus='ide'/>
-      <readonly/>
-      <boot order='1'/>
-      <alias name='ide0-0-0'/>
-      <address type='drive' controller='0' bus='0' target='0' unit='0'/>
-    </disk>
-    <disk type='file' device='cdrom'>
-      <driver name='qemu'/>
-      <target dev='sda' bus='sata'/>
-      <readonly/>
-      <alias name='sata0-0-0'/>
-      <address type='drive' controller='0' bus='0' target='0' unit='0'/>
-    </disk>
-    <controller type='usb' index='0' model='ich9-ehci1'>
-      <alias name='usb'/>
-      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x7'/>
-    </controller>
-    <controller type='usb' index='0' model='ich9-uhci1'>
-      <alias name='usb'/>
-      <master startport='0'/>
-      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0' multifunction='on'/>
-    </controller>
-    <controller type='usb' index='0' model='ich9-uhci2'>
-      <alias name='usb'/>
-      <master startport='2'/>
-      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x1'/>
-    </controller>
-    <controller type='usb' index='0' model='ich9-uhci3'>
-      <alias name='usb'/>
-      <master startport='4'/>
-      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x2'/>
-    </controller>
-    <controller type='pci' index='0' model='pci-root'>
-      <alias name='pci.0'/>
-    </controller>
-    <controller type='ide' index='0'>
-      <alias name='ide'/>
-      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/>
-    </controller>
-    <controller type='sata' index='0'>
-      <alias name='sata0'/>
-      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
-    </controller>
-    <input type='mouse' bus='ps2'>
-      <alias name='input0'/>
-    </input>
-    <input type='keyboard' bus='ps2'>
-      <alias name='input1'/>
-    </input>
-    <graphics type='spice'>
-      <listen type='none'/>
-      <image compression='off'/>
-      <gl enable='no'/>
-    </graphics>
-    <audio id='1' type='spice'/>
-    <video>
-      <model type='vga' vram='16384' heads='1' primary='yes'/>
-      <alias name='video0'/>
-      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
-    </video>
-    <memballoon model='virtio'>
-      <alias name='balloon0'/>
-      <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
-    </memballoon>
-  </devices>
-  <seclabel type='dynamic' model='apparmor' relabel='yes'>
-    <label>libvirt-7a0550ec-ff03-4894-80b8-affe0dfd8177</label>
-    <imagelabel>libvirt-7a0550ec-ff03-4894-80b8-affe0dfd8177</imagelabel>
-  </seclabel>
-  <seclabel type='dynamic' model='dac' relabel='yes'>
-    <label>+64055:+130</label>
-    <imagelabel>+64055:+130</imagelabel>
-  </seclabel>
-</domain>
-```
-
-
----
-
-![Screenshot_openindiana-clone_2022-11-07_11_24_06](/uploads/2f4a22d0fe3d5e2eb689bbaeb6dce346/Screenshot_openindiana-clone_2022-11-07_11_24_06.png)
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_KVM/131 b/gitlab/issues_text/target_i386/host_missing/accel_KVM/131
deleted file mode 100644
index 65128e9db..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_KVM/131
+++ /dev/null
@@ -1 +0,0 @@
-QEMU's default msrs handling causes Windows 10 64 bit to crash
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_KVM/1484 b/gitlab/issues_text/target_i386/host_missing/accel_KVM/1484
deleted file mode 100644
index 7e7c078c2..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_KVM/1484
+++ /dev/null
@@ -1,29 +0,0 @@
-cachy linux iso not booting in linux, host machine freezes
-Description of problem:
-- cachyos-gnome-linux-230121.iso
-  - boots native (core-i7 haswell) via ventoy-boot 
-  - boots on windows (Win10 22H2 19045.2546) using  
-    ```
-    qemu-system-x86_64 -cpu qemu64 -m 4096 -machine "type=q35,kernel-irqchip=off" -accel whpx -smp "sockets=1,cores=8,threads=1" -bios E:\vstorage\win_m01_edk2-x8_64.fd -boot d -cdrom E:/transcend/cachyos-gnome-linux-230121.iso  -display gtk -vga virtio -rtc base=utc -netdev user,id=vmnic1,net=192.168.20.0/24,dns=192.168.20.3,dhcpstart=192.168.20.15,hostfwd=tcp::9551-:22 -device virtio-net,netdev=vmnic1 -device virtio-serial -chardev socket,path=C:/tmpq/Downloads/qga.sock,server=on,wait=off,id=qga0 -device virtserialport,chardev=qga0,name=org.qemu.guest_agent.0 -chardev spicevmc,id=ch1,name=vdagent,clipboard=on  -device virtserialport,chardev=ch1,id=ch1,name=com.redhat.spice.0  -qmp "tcp:127.0.0.1:5955,server,nowait"
-    ```
-  - does not boot on Linux. Infact it crashes the host, which is a much bigger problem
-    ```
-    qemu-system-x86_64 -cpu qemu64 -m 4096 -machine "type=q35" -accel "kvm" -smp "sockets=1,cores=8,threads=1" -boot d  -drive "index=0,if=pflash,format=raw,readonly=on,file=/usr/share/edk2/ovmf/OVMF_CODE.fd" -drive "index=1,if=pflash,format=raw,file=/vol/15KJ_Images/vstorage/m20_OVMF_VARS.fd" -cdrom /vol/15KJ_Images/transcend/cachyos-gnome-linux-230121.iso  -device virtio-vga-gl  -display "spice-app,gl=on" -rtc "base=utc" -net "user" -device "virtio-net,netdev=vmnic" -device virtio-serial -chardev socket,path=/tmp/qga.sock,server=on,wait=off,id=qga0 -device virtserialport,chardev=qga0,name=org.qemu.guest_agent.0 -chardev spicevmc,id=ch1,name=vdagent,clipboard=on  -device virtserialport,chardev=ch1,id=ch1,name=com.redhat.spice.0  -netdev "user,id=vmnic,net=192.168.20.0/24,dns=192.168.20.3,dhcpstart=192.168.20.15" -qmp tcp:0:5955,server,nowait
-    ```  
-    when qemu windows pops up graphics inside the popped up virtviewer spice VM-window is garbled, seemingly of the grub2 bootscreen.  
-    Initially, after window popup the mouse pointer can move for a few more seconds.  
-    Then host machine GUI freezes  
-    Then caps lock toggle/LED works for a while  
-    Then host machine itself freezes. Even Ctrl-Alt-Fx to linux-console does not work.  
-    Then forced to long-press power button and reboot  
-
-Its one thing for the qemu to not be able to boot VM/iso, Its a whole different level bug to freeze the host-machine.   
-Fault inside VM should not affect outside. Plus, I think, I ran qemu-system-x86-64 as ordinary user and not as root.
-
-The self-built qemu-7.2.0 from handcrafted srpm has worked well with my other images.
-
-It may have something to do with virtio-vga-gl in linux but will need to test on next reboot to linux.
-Steps to reproduce:
-1. just run qemu command on linux
-Additional information:
-
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_KVM/180 b/gitlab/issues_text/target_i386/host_missing/accel_KVM/180
deleted file mode 100644
index df5d576bb..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_KVM/180
+++ /dev/null
@@ -1 +0,0 @@
-hardware-based time keeping
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_KVM/1966 b/gitlab/issues_text/target_i386/host_missing/accel_KVM/1966
deleted file mode 100644
index 380c5892a..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_KVM/1966
+++ /dev/null
@@ -1,8 +0,0 @@
-windows xp - some VM's hangs some working (regression?)
-Description of problem:
-Some of my XP instances behaves strange - seems that explorer.exe is unresponsive for about half an hour after start then works +- normally. 
-what is worse - there are instance which behaves normally - ie. after launch everything works as expected.
-Steps to reproduce:
-I want to know.
-Additional information:
-under qemu 8.0.4 all vms works.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_KVM/2003 b/gitlab/issues_text/target_i386/host_missing/accel_KVM/2003
deleted file mode 100644
index f5d08fed3..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_KVM/2003
+++ /dev/null
@@ -1,15 +0,0 @@
-Windows guest boot happens blue screen and crash by using "-cpu Skylake-Server,+la57,phys-bits=52"
-Description of problem:
-We are verifying 5-level paging enabling on Windows guest. After creating Windows guest, the system boot caused blue screen and no screen interface response.
-
-Same QEMU parameter without **+la57,phys-bits=52** (i.e., `./qemu-system-x86_64 -accel kvm -smp 4 -m 4096 -machine q35 -drive file=Winvm5l_host5l_ept5_1698034398,if=none,id=virtio-disk0 -device virtio-blk-pci,drive=virtio-disk0,bootindex=0 -cpu Skylake-Server -monitor pty -daemonize -vnc :40541 -device virtio-net-pci,netdev=nic0,mac=00:5b:0b:59:0d:26 -netdev tap,id=nic0,br=virbr0,helper=/usr/local/libexec/qemu-bridge-helper,vhost=on`), the same Windows image can be booted successfully. Initially suspected this new QEMU release does not support 5-level paging related features.
-Steps to reproduce:
-1. Create guest by using the command
-
-```
-./qemu-system-x86_64 -accel kvm -smp 4 -m 4096 -machine q35 -drive file=Winvm5l_host5l_ept5_1698034398,if=none,id=virtio-disk0 -device virtio-blk-pci,drive=virtio-disk0,bootindex=0 -cpu Skylake-Server,+la57,phys-bits=52 -monitor pty -daemonize -vnc :40541 -device virtio-net-pci,netdev=nic0,mac=00:5b:0b:59:0d:26 -netdev tap,id=nic0,br=virbr0,helper=/usr/local/libexec/qemu-bridge-helper,vhost=on
-```
-Additional information:
-Suspected to be a QEMU regression issue, the first bad commit id: 14f5a7bae4cb5ca45a03e16b5bb0c5d766fd51b7.
-
-Latest successful version commit id: cea3ea670fe265421131aad90c36fbb87bc4d206
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_KVM/2007 b/gitlab/issues_text/target_i386/host_missing/accel_KVM/2007
deleted file mode 100644
index 69e70cf49..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_KVM/2007
+++ /dev/null
@@ -1,29 +0,0 @@
-Unable to update APIC_TPR when x2APIC is enabled and -global kvm-pit.lost_tick_policy=discard parameter provided
-Description of problem:
-I am developing a custom OS and I wanted to implement x2APIC support. I was able to enable x2APIC, read and write some registers, like APIC_VER and APIC_SIVR. Everything looks good, except that I cannot update APIC_TPR register. Reading it always returns 0. The code I wrote works properly on bare metal. Below some observations:
-
-Scenario 1:
-1. Enable x2APIC
-2. Write to CR8 - success
-3. Read from CR8 - gives correct value
-4. Read from APIC_TPR - gives correct value
-
-Scenario 2:
-1. Enable x2APIC
-2. Read from APIC_TPR - gives 0
-3. Write to APIC_TPR
-4. Read from APIC_TPR - gives 0 again
-
-Scenario 3:
-1. Initialize APIC (LAPIC or xAPIC)
-2. Write to APIC_TPR
-3. Read from APIC_TPR - gives correct value
-4. Switch to x2APIC
-5. Read from APIC_TPR - gives correct value stored in pt. 2
-6. Write to APIC_TPR
-7. Read from APIC_TPR - gives values stored in pt.2, not in point 6!
-
-Looks like APIC_TPR is stuck at value stored there before switching to x2APIC and it cannot be updated with MSR. Only update CR8 works.
-I have checked parameters I passed to qemu. After removing `-global kvm-pit.lost_tick_policy=discard` problem is gone and APIC_TPR is updated correctly.
-Additional information:
-Please let me know if you need additional information.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_KVM/2037 b/gitlab/issues_text/target_i386/host_missing/accel_KVM/2037
deleted file mode 100644
index 09edffc46..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_KVM/2037
+++ /dev/null
@@ -1,15 +0,0 @@
-CPUID.07H:EBX.intel-pt not supported warning info shown in terminal when start guest with -cpu qemu64,+intel-pt
-Description of problem:
-When launch guest with qemu-system-x86_64 with parameter -cpu host,+intel-pt, it will show warning info in terminal :
-qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.07H:EBX.intel-pt [bit 25] 'intel_pt' can not be found  in guest's CPU flag. 
-While host already support intel_pt.
-Steps to reproduce:
-1. Run the above QEMU command.
-Additional information:
-This issue was observed with kernel 5.13
-
-qemu-system-x86_64 -accel kvm -m 4096 -smp 4 -cpu host,+intel-pt,min-level=0x14
-qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.07H:EBX.intel-pt [bit 25]
-qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.07H:EBX.intel-pt [bit 25]
-qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.07H:EBX.intel-pt [bit 25]
-qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.07H:EBX.intel-pt [bit 25]
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_KVM/217 b/gitlab/issues_text/target_i386/host_missing/accel_KVM/217
deleted file mode 100644
index 89efe1202..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_KVM/217
+++ /dev/null
@@ -1 +0,0 @@
-Qemu does not force SSE data alignment
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_KVM/2325 b/gitlab/issues_text/target_i386/host_missing/accel_KVM/2325
deleted file mode 100644
index 6b7bd1581..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_KVM/2325
+++ /dev/null
@@ -1,11 +0,0 @@
-[Performance Regression] Constant freezes on Alder lake and Raptor lake CPUs.
-Description of problem:
-Strangely, no logs are recorded. The guest just freezes. It can however be rescued by a simple pause and unpause.
-
-This issue only happens when using the KVM hypervisor. Other hypervisors are fine.
-
-This issue does NOT happen when I tested my Intel Core i7 8700K.
-Steps to reproduce:
-1. Create a basic virtual machine for Windows 11 (Or 10).
-2. Run it for about 5 - 30 minutes (Sometimes it happens in 20 seconds or even less).
-3. The problem should occur.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_KVM/2361 b/gitlab/issues_text/target_i386/host_missing/accel_KVM/2361
deleted file mode 100644
index f4490e91d..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_KVM/2361
+++ /dev/null
@@ -1,13 +0,0 @@
--cpu host or -cpu max breaks GRUB on AMD
-Description of problem:
-I'm running the on an AMD Ryzen CPU host.  I am emulating a Debian Bookworm image stored in a raw disk.  It uses GRUB to load a large (400MB) initrd.  When ran with the flag -cpu host or -cpu max, GRUB throws an out of memory error while loading the initrd.  This doesn't occur when using -cpu kvm64 or excluding the -cpu flag.
-
-If I direct boot the initrd and kernel via -initrd and -kernel, it works fine.  The image also works with -cpu host on an Intel CPU host machine.  The image also works with -cpu EPYC.
-Steps to reproduce:
-1. Create a raw disk with a large initrd and GRUB boot loader
-2. Start a qemu machine on an AMD host 
-3. Receive an error: out of memory
-Additional information:
-I could try selectively enabling CPU features, but I was wondering if the maintainers knew of any feature that might be causing this or how to list the features -cpu host enables.
-
-I also am not 100% that this is a QEMU bug, but it seems the only way to fix it is changing the QEMU config.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_KVM/2394 b/gitlab/issues_text/target_i386/host_missing/accel_KVM/2394
deleted file mode 100644
index 6e19dbb78..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_KVM/2394
+++ /dev/null
@@ -1,29 +0,0 @@
-kvm-unit-tests vmx failed
-Description of problem:
-On the Sierra Forest platform, the vmx test in kvm-unit-tests failed. But this issue cannot be replicated on Emerald Rapids platform.
-
-The first bad commit is ba6780905943696d790cc880c8e5684b51f027fe.
-Steps to reproduce:
-1.git clone https://gitlab.com/kvm-unit-tests/kvm-unit-tests.git
-
-2.cd kvm-unit-tests; ./configure
-
-3.make standalone
-
-4.rmmod kvm_intel
-
-5.modprobe kvm_intel nested=Y allow_smaller_maxphyaddr=Y
-
-6.cd tests; ./vmx
-Additional information:
-...
-FAIL: HOST_CR3 2000000001007000: vmlaunch fails
-
-FAIL: HOST_CR3 4000000001007000: vmlaunch fails
-...
-
-SUMMARY: 430013 tests, 2 unexpected failures, 2 expected failures, 5 skipped
-
-FAIL vmx (430013 tests, 2 unexpected failures, 2 expected failures, 5 skipped)
-
-[error.log](/uploads/02456b40f2736c0bf34d3f4b3a0c872a/error.log)
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_KVM/2429 b/gitlab/issues_text/target_i386/host_missing/accel_KVM/2429
deleted file mode 100644
index 0cb4d410b..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_KVM/2429
+++ /dev/null
@@ -1,29 +0,0 @@
-Enabling SVM in guest forcefully enables hypervisor flag and doesn't respect hv-vendor-id
-Description of problem:
-When the SVM cpu feature is enabled in a guest; despite both the hypervisor feature being disabled and hv-vendor-id being set to AuthenticAMD, the guest hypervisor is detected as "Microsoft Hv" and the hypervisor flag is present. Whereas when the SVM cpu feature is disabled but everything else is still the same, the vendor-id is detected as "AuthenticAMD" and the hypervisor flag isn't present, which is exactly as it was intended by the parameters. Therefore, from what I can tell, enabling the SVM cpu feature (which is necessary for nested-virtualization on AMD CPUs) renders hypervisor=off and hv-vendor-id useless by forcefully enabling the hypervisor flag and setting the hypervisor's vendor-id to the default "Microsoft Hv", which normally shouldn't happen.
-Steps to reproduce:
-1. Run a Windows 11 virtual machine with the given CLI arguments including svm=on
-2. I'm not sure how to check the hypervisor vendor from Command Prompt or PowerShell in Windows, so I used [Paranoid Fish](https://github.com/a0rtega/pafish) to check the hypervisor vendor, it's a utility for checking various different VM detection flags in a guest.
-3. You should see "Hypervisor: Microsoft Hv"
-Additional information:
-Screenshot of Paranoid Fish with SVM enabled:
-
-![svm_enabled.png](/uploads/1ea311d526c4d761cc734cc0daf9614e/svm_enabled.png){width="291" height="86"} ("Hypervisor:" is visible, meaning "-hypervisor" was ignored)
-
-![svm_enabled_hypervisor.png](/uploads/61262cfb6f6c2867b9c20c663fa704d3/svm_enabled_hypervisor.png){width="369" height="13"} (traced means the hypervisor bit is present, meaning `hypervisor=off` was ignored)
-
-And with SVM disabled:
-
-![image.png](/uploads/4a7b7812193c4303e930543a036bfa8f/image.png) ("Hypervisor:" isn't visible, as intended)
-
-![svm_disabled_hypervisor.png](/uploads/94fadbef1e168ace8f32923b3ca92ea9/svm_disabled_hypervisor.png){width="339" height="12"} (OK means the hypervisor bit isn't present, as intended)
-
-# Solution
-
-I finally found a solution to this. And it looks like the problem might not even have been on QEMU's side from the beginning. First disabling Virtualization Based Security (Memory Integrity) from settings and then running the following command: `bcdedit /set hypervisorlaunchtype off` in an admin PowerShell fixes the issue and now with SVM enabled, regardless of whether Hyper-V is enabled or not, I see the following CPU information in Paranoid Fish (identical to when SVM was disabled and everything is as intended, and I can still see that virtualization is enabled in task manager):
-
-![image.png](/uploads/f7cc24c201ad2a6c1ff5a98623e3235b/image.png)
-
-![image.png](/uploads/f3257f420d72fcd3a95ee45b1d9e24a0/image.png)
-
-It looks like for some odd reason Windows enables the hypervisor bit on the CPU and sets the hypervisor's vendor-id to "Microsoft Hv" when SVM is enabled in the VM. No clue as to why it does that, but disabling Virtualization Based Security (Memory Integrity) and running the command I mentioned earlier in an admin PowerShell fixes the problem regardless.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_KVM/2502 b/gitlab/issues_text/target_i386/host_missing/accel_KVM/2502
deleted file mode 100644
index 533413776..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_KVM/2502
+++ /dev/null
@@ -1,13 +0,0 @@
-Old amd64 Ubuntu won't start
-Description of problem:
-While taking a trip down memory lane, I noticed that old Ubuntu amd64 live CDs won't boot in qemu-system-x86_64, while i386 ones work fine. I can confirm this for 6.06 and prior releases, while 8.04 and forward are OK (I don't have interim releases isos).
-Steps to reproduce:
-1. Launch qemu-system-x86_64 with Ubuntu 6.06.1 amd64 live CD
-2. Press "Start or install Ubuntu"
-3. PANIC: early exception rip (etc, please see screenshot below)
-Additional information:
-![Schermata_da_2024-08-13_22-07-14](/uploads/b25474a5bc984e330c1cec32677db2bb/Schermata_da_2024-08-13_22-07-14.png)
-
-I tried a few versions of QEMU and I can tell you that everything worked fine in 7.0.0 and it first broke in 7.1.0. I don't have a more precise bisect, sorry. I also tried in Fedora 40 with QEMU 8.2.2 and I have the same issue, so I don't think it's distro related.
-
-On the other hand, on a completely different PC with an Intel Core i3-330M I have no issue at all, even with QEMU 8.2.3, so it might be AMD/Ryzen related.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_KVM/2571 b/gitlab/issues_text/target_i386/host_missing/accel_KVM/2571
deleted file mode 100644
index ac17a0e14..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_KVM/2571
+++ /dev/null
@@ -1,66 +0,0 @@
-9.1.0 spurious guest journal errors -> linux guest on AMD host
-Description of problem:
-Since upgrading to 9.1.0 I'm seeing new error messages (see below) inside the guest when booting linux guests on an AMD host. Bisection points to:
-```
-2ba8b7ee63589d4063c3b8dff3b70dbf9e224fc6 is the first bad commit
-commit 2ba8b7ee63589d4063c3b8dff3b70dbf9e224fc6
-Author: John Allen <john.allen@amd.com>
-Date:   Mon Jun 3 19:36:21 2024 +0000
-
-    i386: Add support for SUCCOR feature
-    
-    Add cpuid bit definition for the SUCCOR feature. This cpuid bit is required to
-    be exposed to guests to allow them to handle machine check exceptions on AMD
-    hosts.
-```
-Everything still seems to work so possibly not a bug. But the errors are still very disconcerting. Any thoughts?
-Steps to reproduce:
-1. e.g. Boot linux with `-cpu host` on an AMD host
-Additional information:
-```
-Sep 14 12:02:53 kernel: mce: [Firmware Bug]: Your BIOS is not setting up LVT offset 0x2 for deferred error IRQs correctly.
-Sep 14 12:02:53 kernel: unchecked MSR access error: RDMSR from 0x852 at rIP: 0xffffffffb548ffa7 (native_read_msr+0x7/0x40)
-Sep 14 12:02:53 kernel: Call Trace:
-Sep 14 12:02:53 kernel:  <TASK>
-Sep 14 12:02:53 kernel:  ? ex_handler_msr.isra.0.cold+0x28/0x60
-Sep 14 12:02:53 kernel:  ? fixup_exception+0x157/0x380
-Sep 14 12:02:53 kernel:  ? gp_try_fixup_and_notify+0x1e/0xb0
-Sep 14 12:02:53 kernel:  ? exc_general_protection+0x104/0x400
-Sep 14 12:02:53 kernel:  ? asm_exc_general_protection+0x26/0x30
-Sep 14 12:02:53 kernel:  ? native_read_msr+0x7/0x40
-Sep 14 12:02:53 kernel:  native_apic_msr_read+0x20/0x30
-Sep 14 12:02:53 kernel:  setup_APIC_eilvt+0x47/0x110
-Sep 14 12:02:53 kernel:  mce_amd_feature_init+0x485/0x4e0
-Sep 14 12:02:53 kernel:  mcheck_cpu_init+0x1bb/0x470
-Sep 14 12:02:53 kernel:  identify_cpu+0x396/0x5e0
-Sep 14 12:02:53 kernel:  arch_cpu_finalize_init+0x20/0x140
-Sep 14 12:02:53 kernel:  start_kernel+0x931/0x9c0
-Sep 14 12:02:53 kernel:  x86_64_start_reservations+0x24/0x30
-Sep 14 12:02:53 kernel:  x86_64_start_kernel+0x95/0xa0
-Sep 14 12:02:53 kernel:  common_startup_64+0x13e/0x141
-Sep 14 12:02:53 kernel:  </TASK>
-Sep 14 12:02:53 kernel: [Firmware Bug]: cpu 0, try to use APIC520 (LVT offset 2) for vector 0xf4, but the register is already in use for vector 0x
-0 on this cpu
-Sep 14 12:02:53 kernel: mce: [Firmware Bug]: Your BIOS is not setting up LVT offset 0x2 for deferred error IRQs correctly.
-Sep 14 12:02:53 kernel: [Firmware Bug]: cpu 2, try to use APIC520 (LVT offset 2) for vector 0xf4, but the register is already in use for vector 0x
-0 on this cpu
-Sep 14 12:02:53 kernel: mce: [Firmware Bug]: Your BIOS is not setting up LVT offset 0x2 for deferred error IRQs correctly.
-Sep 14 12:02:53 kernel: [Firmware Bug]: cpu 4, try to use APIC520 (LVT offset 2) for vector 0xf4, but the register is already in use for vector 0x
-0 on this cpu
-Sep 14 12:02:53 kernel: mce: [Firmware Bug]: Your BIOS is not setting up LVT offset 0x2 for deferred error IRQs correctly.
-Sep 14 12:02:53 kernel: [Firmware Bug]: cpu 6, try to use APIC520 (LVT offset 2) for vector 0xf4, but the register is already in use for vector 0x
-0 on this cpu
-Sep 14 12:02:53 kernel:  #1 #3 #5 #7
-Sep 14 12:02:53 kernel: mce: [Firmware Bug]: Your BIOS is not setting up LVT offset 0x2 for deferred error IRQs correctly.
-Sep 14 12:02:53 kernel: [Firmware Bug]: cpu 1, try to use APIC520 (LVT offset 2) for vector 0xf4, but the register is already in use for vector 0x
-0 on this cpu
-Sep 14 12:02:53 kernel: mce: [Firmware Bug]: Your BIOS is not setting up LVT offset 0x2 for deferred error IRQs correctly.
-Sep 14 12:02:53 kernel: [Firmware Bug]: cpu 3, try to use APIC520 (LVT offset 2) for vector 0xf4, but the register is already in use for vector 0x
-0 on this cpu
-Sep 14 12:02:53 kernel: mce: [Firmware Bug]: Your BIOS is not setting up LVT offset 0x2 for deferred error IRQs correctly.
-Sep 14 12:02:53 kernel: [Firmware Bug]: cpu 5, try to use APIC520 (LVT offset 2) for vector 0xf4, but the register is already in use for vector 0x
-0 on this cpu
-Sep 14 12:02:53 kernel: mce: [Firmware Bug]: Your BIOS is not setting up LVT offset 0x2 for deferred error IRQs correctly.
-Sep 14 12:02:53 kernel: [Firmware Bug]: cpu 7, try to use APIC520 (LVT offset 2) for vector 0xf4, but the register is already in use for vector 0x
-0 on this cpu
-```
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_KVM/2572 b/gitlab/issues_text/target_i386/host_missing/accel_KVM/2572
deleted file mode 100644
index 20ad0c1e7..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_KVM/2572
+++ /dev/null
@@ -1,30 +0,0 @@
-Guest os=Windows , qemu. Shutdown very slow. Memory allocation issue.
-Description of problem:
-simplifiying - libvirt config:
-```
-<memory unit='KiB'>33554432</memory>
-  <currentMemory unit='KiB'>131072</currentMemory>
-```
-when use `<currentMemory>` less than `<memory>` - at/after shutdown of guest os cpu hangs on 100% and lasts long- approximately 3-5 minutes
-if change to
-```
-<memory unit='KiB'>33554432</memory>
-  <currentMemory unit='KiB'>33554432</currentMemory>
-```
-then shutdown takes less some seconds
-
-problem occurs not (shutdown of VM takes some seconds) in cases when not used balloon device:
-1 `<currentMemory>` equal to `<memory>`
-2 memballoon driver disabled in windows
-3 memballoon disabled on libvirt with "model=none" (and therefore not passed to qemu command line)
-Additional information:
-on the guest :
- * used drivers from virtio-win-0.1.262.iso - membaloon ver 100.95.104.26200 
- * possible combination of all or some components 
-
-monitored next: 
-`virsh dommemstat VMName` at shutdown time there grows "rss" till MaxMem, but very slowly.
-aLso on `virsh setmem VMName --live --size 32G` 
-rss grows slow - but takes 2 times less than at simple shutdown time ( = at shutdown seems occurs memory allocation and deallocation at the same time)
-
-so something with some or all libvirt/qemu/balloon parts not so nice
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_KVM/2582 b/gitlab/issues_text/target_i386/host_missing/accel_KVM/2582
deleted file mode 100644
index 11ec718a5..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_KVM/2582
+++ /dev/null
@@ -1,23 +0,0 @@
-CR4.VMX leaks from L1 into L2 on Intel VMX
-Description of problem:
-In a nested virtualization setting, `savevm` can cause CR4 bits from leaking from L1 into L2. This causes general-protection faults in certain guests.
-
-The L2 guest executes this code:
-
-```
-mov rax, cr4  ; Get CR4​
-mov rcx, rax  ; Remember the old value​
-btc rax, 7    ; Toggle CR4.PGE​
-mov cr4, rax  ; #GP! <- Shouldn't happen!​
-mov cr4, rcx  ; Restore old value
-```
-
-If the guest code is interrupted at the right time (e.g. via `savevm`), Qemu marks CR4 dirty while the guest executes L2 code. Due to really complicated KVM semantics, this will result in L1 CR4 bits (VMXE) leaking into the L2 guest and the L2 will die with a GP:
-
-Instead of the expected CR4 value, the L2 guest reads a value with VMXE set. When it tries to write this back into CR4, this triggers the general protection fault.
-Steps to reproduce:
-This is only an issue on **Intel** systems.
-
-#
-Additional information:
-See also this discussion where we discussed a (flawed) approach to fixing this in KVM: https://lore.kernel.org/lkml/Zh6WlOB8CS-By3DQ@google.com/t/
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_KVM/2612 b/gitlab/issues_text/target_i386/host_missing/accel_KVM/2612
deleted file mode 100644
index 0da5edd23..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_KVM/2612
+++ /dev/null
@@ -1,82 +0,0 @@
-In-guest ROCm tests fail with multiple AMD GPUs passed through (bisected to SeaBIOS update)
-Description of problem:
-We got a report of a VM setup with 8 passed-through AMD GPUs that works well with QEMU 8.1.5, but has issues with QEMU 8.2.2 (see below for details). A QEMU bisect points to commit [14f5a7ba](https://gitlab.com/qemu-project/qemu/-/commit/14f5a7bae4cb5ca45a03e16b5bb0c5d766fd51b7) which updated the seabios snapshot.
-Even though Proxmox VE comes with its own packaged QEMU versions, for bisecting we used the [upstream repository](https://gitlab.com/qemu-project/qemu).
-
-Bisecting seabios between rel-1.16.2 and rel-1.16.3 brought the following 2 commits to attention:
-
-[bcfed7e2](https://gitlab.com/qemu-project/seabios/-/commit/bcfed7e270776ab5595cafc6f1794bea0cae1c6c) move 64bit pci window to end of address space
-
-[96a8d130](https://gitlab.com/qemu-project/seabios/-/commit/96a8d130a8c2e908e357ce62cd713f2cc0b0a2eb) be less conservative with the 64bit pci io window
-
-
-
-Since bcfed7e2 resulted in KVM errors when trying to start the guest, we could not narrow it down to a single commit. With 96a8d130 the issues in the guest began.
-
-The issues in the guest were reproduced by running some ROCm tests in the guest using all 8 GPUs. We had no insight into the tests in question, they, as well as the test setup, were provided by one of our customers. The failing test was a DeepSpeed test using all 8 GPUs.
-
-We're not sure if it's a driver issue in the guest (AMDGPU and ROCm 6.1.x and 6.2.1 tested), a hardware issue or a seabios issue. Since we narrowed it down to these commits (QEMU, seabios) we wanted to open an issue here first. 
-
-The in-guest kernel warning received seems to indicate an issue with the driver::
-```
-kernel: ------------[ cut here ]------------
-kernel: WARNING: CPU: 2 PID: 149 at /tmp/amd.eT2ZshuE/ttm/ttm_bo.c:687 amdttm_bo_unpin+0x72/0x90 [amdttm]
-kernel: Modules linked in: veth tls xt_conntrack nft_chain_nat xt_MASQUERADE nf_nat nf_conntrack_netlink nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xfrm_user xfrm_algo xt_addrtype nft_compat n>
-kernel:  libahci video wmi i2c_algo_bit hid_generic usbhid hid aesni_intel crypto_simd cryptd
-kernel: CPU: 2 PID: 149 Comm: kworker/2:1 Tainted: G           OE      6.8.0-45-generic #45-Ubuntu
-kernel: Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014
-kernel: Workqueue: kfd_process_wq kfd_process_wq_release [amdgpu]
-kernel: RIP: 0010:amdttm_bo_unpin+0x72/0x90 [amdttm]
-kernel: Code: 89 de e8 01 56 00 00 48 8b bb 60 01 00 00 48 81 c7 40 08 00 00 e8 6e 72 89 d2 48 8b 5d f8 c9 31 c0 31 f6 31 ff e9 79 54 b5 d2 <0f> 0b 48 8b 5d f8 c9 31 c0 31 f6 31 ff e9 67 54 b5>
-kernel: RSP: 0018:ffffa03380687ca0 EFLAGS: 00010246
-kernel: RAX: 0000000000000000 RBX: ffff8ed6191b6848 RCX: 0000000000000000
-kernel: RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff8ed6191b6848
-kernel: RBP: ffffa03380687ca8 R08: 0000000000000000 R09: 0000000000000000
-kernel: R10: 0000000000000000 R11: 0000000000000000 R12: ffff8ed62268ef38
-kernel: R13: ffff8ed6014fc800 R14: ffff8ed6015f0400 R15: ffff8ed60109b000
-kernel: FS:  0000000000000000(0000) GS:ffff8ef4ff700000(0000) knlGS:0000000000000000
-kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
-kernel: CR2: 00007f923c000020 CR3: 00000106f083c006 CR4: 0000000000770ef0
-kernel: PKRU: 55555554
-kernel: Call Trace:
-kernel:  <TASK>
-kernel:  ? show_regs+0x6d/0x80
-kernel:  ? __warn+0x89/0x160
-kernel:  ? amdttm_bo_unpin+0x72/0x90 [amdttm]
-kernel:  ? report_bug+0x17e/0x1b0
-kernel:  ? handle_bug+0x51/0xa0
-kernel:  ? exc_invalid_op+0x18/0x80
-kernel:  ? asm_exc_invalid_op+0x1b/0x20
-kernel:  ? amdttm_bo_unpin+0x72/0x90 [amdttm]
-kernel:  amdgpu_bo_unpin+0x1f/0xb0 [amdgpu]
-kernel:  amdgpu_amdkfd_gpuvm_unpin_bo+0x35/0xd0 [amdgpu]
-kernel:  amdgpu_amdkfd_gpuvm_free_memory_of_gpu+0x3ea/0x460 [amdgpu]
-kernel:  kfd_process_device_free_bos+0xb7/0x150 [amdgpu]
-kernel:  kfd_process_wq_release+0x2db/0x410 [amdgpu]
-kernel:  process_one_work+0x16f/0x350
-kernel:  worker_thread+0x306/0x440
-kernel:  ? srso_alias_return_thunk+0x5/0xfbef5
-kernel:  ? _raw_spin_unlock_irqrestore+0x11/0x60
-kernel:  ? __pfx_worker_thread+0x10/0x10
-kernel:  kthread+0xf2/0x120
-kernel:  ? __pfx_kthread+0x10/0x10
-kernel:  ret_from_fork+0x47/0x70
-kernel:  ? __pfx_kthread+0x10/0x10
-kernel:  ret_from_fork_asm+0x1b/0x30
-kernel:  </TASK>
-kernel: ---[ end trace 0000000000000000 ]---
-```
-
-Does anyone have an idea how to troubleshoot this further? If any more information or logs are required, we can try to provide them.
-Steps to reproduce:
-Sadly we can't provide steps since we only had the customer's setup that included a proprietary docker image.
-Additional information:
-We used the options `-chardev pipe,path=qemudebugpipe,id=seabios -device isa-debugcon,iobase=0x402,chardev=seabios` specified in [0] to gather some debug logs from seabios:
-
-The non-working one is from commit `96a8d130` while the working one is from an earlier version.
-
-[seabios.log](/uploads/4d7f43213c631fb5cf6aea519bfd79ad/seabios.log)
-[seabios_working.log](/uploads/978e6c56ff8784bb5639963c9fb0c93f/seabios_working.log)
-
-
-[0] https://gitlab.com/qemu-project/seabios/-/blob/master/docs/Debugging.md?ref_type=heads
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_KVM/2622 b/gitlab/issues_text/target_i386/host_missing/accel_KVM/2622
deleted file mode 100644
index e1d4828c3..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_KVM/2622
+++ /dev/null
@@ -1,267 +0,0 @@
-qemu abort in qemu_aio_coroutine_enter
-Description of problem:
-Start the virtual machine using NFS disk, run sysbench to test myql inside the virtual machine,
- and execute command "virsh domblkinfo domid vda" in host. After running for a period of time, qemu crashes.
- This issue is not a necessary problem and requires long-term operation for more than ten hours. 
-It maybe related to NFS disk and not appear with other types of storage.
-the qemu log is 
-
-qemu_aio_coroutine_enter Co-routine was already scheduled in aio_co_schedule
-
-```
-Core was generated by `/usr/libexec/qemu-kvm -name guest=default_vm-csv66,debug-threads=on -S -object'.
-Program terminated with signal SIGABRT, Aborted.
-#0  0x00007f9702f5a54c in __pthread_kill_implementation () from /lib64/libc.so.6
-[Current thread is 1 (Thread 0x7f9701f7bf40 (LWP 98))]
-Missing separate debuginfos, use: dnf debuginfo-install capstone-4.0.2-10.cl9.x86_64 cyrus-sasl-lib-2.1.27-20.cl9.x86_64 daxctl-libs-71.1-7.cl9.x86_64 glib2-2.68.4-5.cl9.x86_64 glibc-2.34-40.cl9_1.2.x86_64 gnutls-3.7.6-18.cl9_1.x86_64 kmod-libs-28-7.cl9.x86_64 krb5-libs-1.19.1-24.cl9_1.x86_64 libaio-0.3.111-13.cl9.x86_64 libblkid-2.37.4-9.cl9.x86_64 libcom_err-1.46.5-3.cl9.x86_64 libfdt-1.6.0-7.cl9.x86_64 libffi-3--Type <RET> for more, q to quit, c to continue without paging--
-.4.2-7.cl9.x86_64 libgcc-11.3.1-2.1.cl9.x86_64 libibverbs-42.0-1.cl9.x86_64 libidn2-2.3.0-7.cl9.x86_64 libmount-2.37.4-9.cl9.x86_64 libnfs-5.0.3-2.cl9.x86_64 libnl3-3.7.0-1.cl9.x86_64 libpmem-1.12.1-1.cl9.x86_64 libpng-1.6.37-12.cl9.x86_64 librdmacm-42.0-1.cl9.x86_64 libseccomp-2.5.2-2.cl9.x86_64 libselinux-3.4-3.cl9.x86_64 libslirp-4.4.0-7.cl9.x86_64 libstdc++-11.3.1-2.1.cl9.x86_64 libtasn1-4.16.0-8.cl9_1.x86_64 libunistring-0.9.10-16.cl9.x86_64 liburing-0.7-7.cl9.x86_64 libuuid-2.37.4-9.cl9.x86_64 libxcrypt-4.4.18-3.cl9.x86_64 libzstd-1.5.1-2.cl9.x86_64 lzo-2.10-7.cl9.x86_64 nettle-3.8-3.cl9_0.x86_64 numactl-libs-2.0.14-8.cl9.x86_64 openssl-libs-3.0.1-49.cl9_1.x86_64 p11-kit-0.24.1-2.cl9.x86_64 pcre-8.44-3.cl9.3.x86_64 pcre2-10.40-2.cl9.x86_64 pixman-0.40.0-5.cl9.x86_64 snappy-1.1.8-8.cl9.x86_64 systemd-libs-250-12.cl9_1.3.x86_64 zlib-1.2.11-34.cl9.x86_64
-(gdb) bt
-#0  0x00007f9702f5a54c in __pthread_kill_implementation () from /lib64/libc.so.6
-#1  0x00007f9702f0dce6 in raise () from /lib64/libc.so.6
-#2  0x00007f9702ee17f3 in abort () from /lib64/libc.so.6
-#3  0x00005631681ceed2 in qemu_aio_coroutine_enter (ctx=0x563169dd9550, co=<optimized out>) at ../util/qemu-coroutine.c:277
-#4  0x00005631680a99e9 in bdrv_poll_co (s=0x7ffe072eea80)
-    at /usr/src/debug/qemu-kvm-8.2.0-1.cl9.gcc.git908b11716.x86_64/block/block-gen.h:42
-#5  bdrv_get_info (bs=bs@entry=0x563169fc1680, bdi=bdi@entry=0x7ffe072eeaf0) at block/block-gen.c:600
-#6  0x00005631680efc3d in bdrv_do_query_node_info (bs=bs@entry=0x563169fc1680, info=info@entry=0x56316a0f6650,
-    errp=errp@entry=0x7ffe072eed48) at ../block/qapi.c:255
-#7  0x00005631680efe1a in bdrv_query_image_info (bs=0x563169fc1680, p_info=0x56316a53c0d8, flat=<optimized out>,
-    skip_implicit_filters=<optimized out>, errp=0x7ffe072eed48) at ../block/qapi.c:337
-#8  0x00005631680f026f in bdrv_block_device_info (blk=blk@entry=0x0, bs=bs@entry=0x563169fc1680, flat=flat@entry=true,
-    errp=errp@entry=0x7ffe072eed48) at ../block/qapi.c:155
-#9  0x00005631680b31e3 in bdrv_named_nodes_list (flat=<optimized out>, errp=errp@entry=0x7ffe072eed48) at ../block.c:6207
-#10 0x00005631680a4162 in qmp_query_named_block_nodes (has_flat=<optimized out>, flat=<optimized out>, errp=errp@entry=0x7ffe072eed48)
-    at ../blockdev.c:2785
-#11 0x00005631681593eb in qmp_marshal_query_named_block_nodes (args=0x7f96e80093d0, ret=0x7f9701777eb8, errp=0x7f9701777eb0)
-    at qapi/qapi-commands-block-core.c:553
-#12 0x00005631681ade8d in do_qmp_dispatch_bh (opaque=0x7f9701777ec0) at ../qapi/qmp-dispatch.c:128
-#13 0x00005631681cd155 in aio_bh_poll (ctx=ctx@entry=0x563169da6e70) at ../util/async.c:216
-#14 0x00005631681b7a42 in aio_dispatch (ctx=0x563169da6e70) at ../util/aio-posix.c:423
-#15 0x00005631681ccee2 in aio_ctx_dispatch (source=<optimized out>, callback=<optimized out>, user_data=<optimized out>)
-    at ../util/async.c:358
-#16 0x00007f9703356d6f in g_main_context_dispatch () from /lib64/libglib-2.0.so.0
-#17 0x00005631681ce710 in glib_pollfds_poll () at ../util/main-loop.c:290
-#18 os_host_main_loop_wait (timeout=0) at ../util/main-loop.c:313
-#19 main_loop_wait (nonblocking=nonblocking@entry=0) at ../util/main-loop.c:592
-#20 0x0000563167edc9b7 in qemu_main_loop () at ../system/runstate.c:782
-#21 0x0000563167daa3ab in qemu_default_main () at ../system/main.c:37
-#22 0x00007f9702ef8eb0 in __libc_start_call_main () from /lib64/libc.so.6
-#23 0x00007f9702ef8f60 in __libc_start_main_impl () from /lib64/libc.so.6
-#24 0x0000563167daa2d5 in _start ()
-(gdb) list ../util/qemu-coroutine.c:277
-272              * been deleted */
-273             if (scheduled) {
-**274                 fprintf(stderr,
-275                         "%s: Co-routine was already scheduled in '%s'\n",
-276                         __func__, scheduled);
-277                 abort();**
-278             }
-279
-280             if (to->caller) {
-281                 fprintf(stderr, "Co-routine re-entered recursively\n");
-
-(gdb) p *(AioContext *)0x563169dd9550
-$3 = {source = {callback_data = 0x0, callback_funcs = 0x0, source_funcs = 0x563168f029c0 <aio_source_funcs>, ref_count = 2,
-    context = 0x563169dd16b0, priority = 0, flags = 33, source_id = 1, poll_fds = 0x563169d34e70, prev = 0x0, next = 0x563169da6e70,
-    name = 0x563169ddd400 "aio-context", priv = 0x563169da7230}, lock = {m = {lock = {__data = {__lock = 0, __count = 0, __owner = 0,
-          __nusers = 0, __kind = 1, __spins = 0, __elision = 0, __list = {__prev = 0x0, __next = 0x0}},
-        __size = '\000' <repeats 16 times>, "\001", '\000' <repeats 22 times>, __align = 0}, initialized = true}},
-  bdrv_graph = 0x563169dc7350, aio_handlers = {lh_first = 0x563169ddd020}, deleted_aio_handlers = {lh_first = 0x0}, notify_me = 0,
-  list_lock = {count = 0}, bh_list = {slh_first = 0x563169dad160}, bh_slice_list = {sqh_first = 0x0, sqh_last = 0x563169dd9608},
-  notified = true, notifier = {rfd = 8, wfd = 8, initialized = true}, scheduled_coroutines = {slh_first = 0x563169fbff70},
-  co_schedule_bh = 0x563169dad160, thread_pool_min = 0, thread_pool_max = 64, thread_pool = 0x0, linux_aio = 0x0, linux_io_uring = 0x0,
-  fdmon_io_uring = {sq = {khead = 0x7f9701675000, ktail = 0x7f9701675040, kring_mask = 0x7f9701675100, kring_entries = 0x7f9701675108,
-      kflags = 0x7f9701675114, kdropped = 0x7f9701675110, array = 0x7f9701676140, sqes = 0x7f9701673000, sqe_head = 0, sqe_tail = 0,
-      ring_sz = 4928, ring_ptr = 0x7f9701675000}, cq = {khead = 0x7f9701675080, ktail = 0x7f97016750c0, kring_mask = 0x7f9701675104,
-      kring_entries = 0x7f970167510c, kflags = 0x7f9701675118, koverflow = 0x7f970167511c, cqes = 0x7f9701675140, ring_sz = 4928,
-      ring_ptr = 0x7f9701675000}, flags = 0, ring_fd = 7}, submit_list = {slh_first = 0x0}, tlg = {tl = {0x563169ddd390, 0x563169dd1a50,
-      0x563169dd1ac0, 0x563169dd1b30}}, poll_disable_cnt = 0, poll_ns = 0, poll_max_ns = 0, poll_grow = 0, poll_shrink = 0,
-  aio_max_batch = 0, poll_aio_handlers = {lh_first = 0x563169ddd020}, poll_started = false, epollfd = -1,
-  fdmon_ops = 0x563168dfabe0 <fdmon_poll_ops>}
-(gdb) list bdrv_poll_co
-file: "/usr/src/debug/qemu-kvm-8.2.0-1.cl9.gcc.git908b11716.x86_64/block/block-gen.h", line number: 38, symbol: "bdrv_poll_co"
-33          AioContext *ctx;
-34          bool in_progress;
-35          Coroutine *co; /* Keep pointer here for debugging */
-36      } BdrvPollCo;
-37
-38      static inline void bdrv_poll_co(BdrvPollCo *s)
-39      {
-40          assert(!qemu_in_coroutine());
-41
-42          aio_co_enter(s->ctx, s->co);
-file: "/usr/src/debug/qemu-kvm-8.2.0-1.cl9.gcc.git908b11716.x86_64/block/block-gen.h", line number: 40, symbol: "bdrv_poll_co"
-35          Coroutine *co; /* Keep pointer here for debugging */
-36      } BdrvPollCo;
-37
-38      static inline void bdrv_poll_co(BdrvPollCo *s)
-39      {
-40          assert(!qemu_in_coroutine());
-41
-42          aio_co_enter(s->ctx, s->co);
-43          AIO_WAIT_WHILE(s->ctx, s->in_progress);
-44      }
-(gdb) p *(BdrvPollCo*)0x7ffe072eea80
-$4 = {ctx = 0x563169dd9550, in_progress = true, co = 0x563169fbff70}
-
-(gdb) p *(Coroutine*)0x563169fbff70
-$6 = {entry = 0x5631680a7bc0 <bdrv_co_get_info_entry>, entry_arg = 0x7ffe072eea80, caller = 0x0, caller_sp = 0x7ffe072eea28, pool_next = {
-    sle_next = 0x0}, locks_held = 0, ctx = 0x563169dd9550, scheduled = 0x5631683596c0 <__func__.3> "aio_co_schedule", co_queue_next = {
-    sqe_next = 0x0}, co_queue_wakeup = {sqh_first = 0x0, sqh_last = 0x563169fbffb8}, co_scheduled_next = {sle_next = 0x0}}
-(gdb)
-```
-Steps to reproduce:
-1. start vm 
-
-the virtual machine xml is
-[libnfs-vm-xml](/uploads/f664fe2002a032064f3d574f3cc0b13f/libnfs-vm-xml)
-
-2. run sysbench test for mysql
-the command line:
-
-![0880c4c80710b5db8422](/uploads/e3431029de2d66a075bb34d3866ac92d/0880c4c80710b5db8422.png)
-3. run command line: virsh domlbkinfo domid vda
-Additional information:
-```
-the all theads stack:
-
-Thread 12 (Thread 0x7f59b1a71640 (LWP 102)):
-#0  0x00007f59ba2ed71f in poll () from /lib64/libc.so.6
-#1  0x00007f59ba69e0bc in split_replacement.constprop () from /lib64/libglib-2.0.so.0
-#2  0xddd73fd20744af00 in ?? ()
-#3  0x00080f8a5afdd040 in ?? ()
-#4  0x0000563110266fd8 in ?? ()
-#5  0x0000563110266fd0 in ?? ()
-#6  0x0000563110239680 in ?? ()
-#7  0x000056311023ad20 in ?? ()
-#8  0x00007f59ba24a530 in ?? () from /lib64/libc.so.6
-#9  0x0000000000000000 in ?? ()
-
-Thread 11 (Thread 0x7f579cbbf640 (LWP 107)):
-#0  0x00007f59ba24739a in __futex_abstimed_wait_common () from /lib64/libc.so.6
-#1  0x00007f59ba249ba0 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libc.so.6
-#2  0x000056310e2edced in qemu_cond_wait_impl (cond=<optimized out>, mutex=0x56311160aea8, file=0x56310e392334 "../ui/vnc-jobs.c", line=248) at ../util/qemu-thread-posix.c:225
-#3  0x000056310df03c47 in vnc_worker_thread_loop (queue=queue@entry=0x56311160ae70) at ../ui/vnc-jobs.c:248
-#4  0x000056310df045c0 in vnc_worker_thread (arg=0x56311160ae70) at ../ui/vnc-jobs.c:362
-#5  0x000056310e2ed7f3 in qemu_thread_start (args=0x563110dbab70) at ../util/qemu-thread-posix.c:541
-#6  0x00007f59ba24a802 in start_thread () from /lib64/libc.so.6
-#7  0x00007f59ba1ea314 in clone () from /lib64/libc.so.6
-
-Thread 10 (Thread 0x7f59b896b640 (LWP 98)):
-#0  0x00007f59ba2ed81e in ppoll () from /lib64/libc.so.6
-#1  0x000056310e303d05 in ppoll (__ss=0x0, __timeout=0x7f59b896a540, __nfds=<optimized out>, __fds=<optimized out>) at /usr/include/bits/poll2.h:64
-#2  qemu_poll_ns (fds=<optimized out>, nfds=<optimized out>, timeout=<optimized out>) at ../util/qemu-timer.c:351
-#3  0x000056310e2eb2d9 in fdmon_poll_wait (ctx=0x56311043f190, ready_list=0x7f59b896a5d0, timeout=93350478717) at ../util/fdmon-poll.c:79
-#4  0x000056310e2eaadd in aio_poll (ctx=0x56311043f190, blocking=blocking@entry=true) at ../util/aio-posix.c:670
-#5  0x000056310e1d8fba in iothread_run (opaque=0x563110239ce0) at ../iothread.c:63
-#6  0x000056310e2ed7f3 in qemu_thread_start (args=0x56311043f6f0) at ../util/qemu-thread-posix.c:541
-#7  0x00007f59ba24a802 in start_thread () from /lib64/libc.so.6
-#8  0x00007f59ba1ea314 in clone () from /lib64/libc.so.6
-
-Thread 9 (Thread 0x7f579fffe640 (LWP 105)):
-#0  0x00007f59ba1e9c6b in ioctl () from /lib64/libc.so.6
---Type <RET> for more, q to quit, c to continue without paging--
-#1  0x000056310e19f0cd in kvm_vcpu_ioctl (cpu=cpu@entry=0x563110535c10, type=type@entry=44672) at ../accel/kvm/kvm-all.c:3078
-#2  0x000056310e19f47a in kvm_cpu_exec (cpu=cpu@entry=0x563110535c10) at ../accel/kvm/kvm-all.c:2890
-#3  0x000056310e1a09cd in kvm_vcpu_thread_fn (arg=0x563110535c10) at ../accel/kvm/kvm-accel-ops.c:51
-#4  0x000056310e2ed7f3 in qemu_thread_start (args=0x56311053ea10) at ../util/qemu-thread-posix.c:541
-#5  0x00007f59ba24a802 in start_thread () from /lib64/libc.so.6
-#6  0x00007f59ba1ea314 in clone () from /lib64/libc.so.6
-
-Thread 8 (Thread 0x7f59b1270640 (LWP 103)):
-#0  0x00007f59ba1e9c6b in ioctl () from /lib64/libc.so.6
-#1  0x000056310e19f0cd in kvm_vcpu_ioctl (cpu=cpu@entry=0x5631104fd5e0, type=type@entry=44672) at ../accel/kvm/kvm-all.c:3078
-#2  0x000056310e19f47a in kvm_cpu_exec (cpu=cpu@entry=0x5631104fd5e0) at ../accel/kvm/kvm-all.c:2890
-#3  0x000056310e1a09cd in kvm_vcpu_thread_fn (arg=0x5631104fd5e0) at ../accel/kvm/kvm-accel-ops.c:51
-#4  0x000056310e2ed7f3 in qemu_thread_start (args=0x5631104ac540) at ../util/qemu-thread-posix.c:541
-#5  0x00007f59ba24a802 in start_thread () from /lib64/libc.so.6
-#6  0x00007f59ba1ea314 in clone () from /lib64/libc.so.6
-
-Thread 7 (Thread 0x7f59b926d640 (LWP 97)):
-#0  0x00007f59ba1e9e5d in syscall () from /lib64/libc.so.6
-#1  0x000056310e2ee262 in qemu_futex_wait (val=<optimized out>, f=<optimized out>) at /usr/src/debug/qemu-kvm-8.2.0-1.cl9.gcc.gita8dcbf606.x86_64/include/qemu/futex.h:29
-#2  qemu_event_wait (ev=ev@entry=0x56310f060688 <rcu_call_ready_event>) at ../util/qemu-thread-posix.c:464
-#3  0x000056310e2f8a52 in call_rcu_thread (opaque=<optimized out>) at ../util/rcu.c:278
-#4  0x000056310e2ed7f3 in qemu_thread_start (args=0x5631101d9df0) at ../util/qemu-thread-posix.c:541
-#5  0x00007f59ba24a802 in start_thread () from /lib64/libc.so.6
-#6  0x00007f59ba1ea450 in clone3 () from /lib64/libc.so.6
-
-Thread 6 (Thread 0x7f59b37fe640 (LWP 100)):
-#0  0x00007f59ba2ed81e in ppoll () from /lib64/libc.so.6
-#1  0x000056310e303d5d in ppoll (__ss=0x0, __timeout=0x0, __nfds=<optimized out>, __fds=<optimized out>) at /usr/include/bits/poll2.h:64
-#2  0x000056310e2eb2d9 in fdmon_poll_wait (ctx=0x56311043fea0, ready_list=0x7f59b37fd5d0, timeout=-1) at ../util/fdmon-poll.c:79
-#3  0x000056310e2eaadd in aio_poll (ctx=0x56311043fea0, blocking=blocking@entry=true) at ../util/aio-posix.c:670
-#4  0x000056310e1d8fba in iothread_run (opaque=0x56311043f8f0) at ../iothread.c:63
-#5  0x000056310e2ed7f3 in qemu_thread_start (args=0x5631104404c0) at ../util/qemu-thread-posix.c:541
-#6  0x00007f59ba24a802 in start_thread () from /lib64/libc.so.6
-#7  0x00007f59ba1ea314 in clone () from /lib64/libc.so.6
-
-Thread 5 (Thread 0x7f59b2ffd640 (LWP 101)):
-#0  0x00007f59ba2ed81e in ppoll () from /lib64/libc.so.6
---Type <RET> for more, q to quit, c to continue without paging--
-#1  0x000056310e303d5d in ppoll (__ss=0x0, __timeout=0x0, __nfds=<optimized out>, __fds=<optimized out>) at /usr/include/bits/poll2.h:64
-#2  0x000056310e2eb2d9 in fdmon_poll_wait (ctx=0x5631104407f0, ready_list=0x7f59b2ffc5d0, timeout=-1) at ../util/fdmon-poll.c:79
-#3  0x000056310e2eaadd in aio_poll (ctx=0x5631104407f0, blocking=blocking@entry=true) at ../util/aio-posix.c:670
-#4  0x000056310e1d8fba in iothread_run (opaque=0x56311043fc20) at ../iothread.c:63
-#5  0x000056310e2ed7f3 in qemu_thread_start (args=0x5631104437a0) at ../util/qemu-thread-posix.c:541
-#6  0x00007f59ba24a802 in start_thread () from /lib64/libc.so.6
-#7  0x00007f59ba1ea314 in clone () from /lib64/libc.so.6
-
-Thread 4 (Thread 0x7f59b0a6f640 (LWP 104)):
-#0  0x00007f59ba1e9c6b in ioctl () from /lib64/libc.so.6
-#1  0x000056310e19f0cd in kvm_vcpu_ioctl (cpu=cpu@entry=0x56311052bd80, type=type@entry=44672) at ../accel/kvm/kvm-all.c:3078
-#2  0x000056310e19f47a in kvm_cpu_exec (cpu=cpu@entry=0x56311052bd80) at ../accel/kvm/kvm-all.c:2890
-#3  0x000056310e1a09cd in kvm_vcpu_thread_fn (arg=0x56311052bd80) at ../accel/kvm/kvm-accel-ops.c:51
-#4  0x000056310e2ed7f3 in qemu_thread_start (args=0x563110535330) at ../util/qemu-thread-posix.c:541
-#5  0x00007f59ba24a802 in start_thread () from /lib64/libc.so.6
-#6  0x00007f59ba1ea314 in clone () from /lib64/libc.so.6
-
-Thread 3 (Thread 0x7f59b3fff640 (LWP 99)):
-#0  0x00007f59ba2ed81e in ppoll () from /lib64/libc.so.6
-#1  0x000056310e303d5d in ppoll (__ss=0x0, __timeout=0x0, __nfds=<optimized out>, __fds=<optimized out>) at /usr/include/bits/poll2.h:64
-#2  0x000056310e2eb2d9 in fdmon_poll_wait (ctx=0x563110441e00, ready_list=0x7f59b3ffe5d0, timeout=-1) at ../util/fdmon-poll.c:79
-#3  0x000056310e2eaadd in aio_poll (ctx=0x563110441e00, blocking=blocking@entry=true) at ../util/aio-posix.c:670
-#4  0x000056310e1d8fba in iothread_run (opaque=0x56311043fa40) at ../iothread.c:63
-#5  0x000056310e2ed7f3 in qemu_thread_start (args=0x5631104423b0) at ../util/qemu-thread-posix.c:541
-#6  0x00007f59ba24a802 in start_thread () from /lib64/libc.so.6
-#7  0x00007f59ba1ea314 in clone () from /lib64/libc.so.6
-
-Thread 2 (Thread 0x7f579f7fd640 (LWP 106)):
-#0  0x00007f59ba1e9c6b in ioctl () from /lib64/libc.so.6
-#1  0x000056310e19f0cd in kvm_vcpu_ioctl (cpu=cpu@entry=0x56311053f2f0, type=type@entry=44672) at ../accel/kvm/kvm-all.c:3078
-#2  0x000056310e19f47a in kvm_cpu_exec (cpu=cpu@entry=0x56311053f2f0) at ../accel/kvm/kvm-all.c:2890
-#3  0x000056310e1a09cd in kvm_vcpu_thread_fn (arg=0x56311053f2f0) at ../accel/kvm/kvm-accel-ops.c:51
-#4  0x000056310e2ed7f3 in qemu_thread_start (args=0x563110548280) at ../util/qemu-thread-posix.c:541
-#5  0x00007f59ba24a802 in start_thread () from /lib64/libc.so.6
-#6  0x00007f59ba1ea314 in clone () from /lib64/libc.so.6
-
-Thread 1 (Thread 0x7f59b9270f40 (LWP 95)):
-#0  0x00007f59ba24c54c in __pthread_kill_implementation () from /lib64/libc.so.6
---Type <RET> for more, q to quit, c to continue without paging--
-#1  0x00007f59ba1ffce6 in raise () from /lib64/libc.so.6
-#2  0x00007f59ba1d37f3 in abort () from /lib64/libc.so.6
-#3  0x000056310e301e02 in qemu_aio_coroutine_enter (ctx=0x563110266550, co=<optimized out>) at ../util/qemu-coroutine.c:277
-#4  0x000056310e1dc919 in bdrv_poll_co (s=0x7ffd1c9ec8d0) at /usr/src/debug/qemu-kvm-8.2.0-1.cl9.gcc.gita8dcbf606.x86_64/block/block-gen.h:42
-#5  bdrv_get_info (bs=bs@entry=0x563110481e10, bdi=bdi@entry=0x7ffd1c9ec940) at block/block-gen.c:600
-#6  0x000056310e222b6d in bdrv_do_query_node_info (bs=bs@entry=0x563110481e10, info=info@entry=0x563110480130, errp=errp@entry=0x7ffd1c9ecb98) at ../block/qapi.c:255
-#7  0x000056310e222d4a in bdrv_query_image_info (bs=0x563110481e10, p_info=0x56311121cc18, flat=<optimized out>, skip_implicit_filters=<optimized out>, errp=0x7ffd1c9ecb98) at ../block/qapi.c:337
-#8  0x000056310e22319f in bdrv_block_device_info (blk=blk@entry=0x0, bs=bs@entry=0x563110481e10, flat=flat@entry=true, errp=errp@entry=0x7ffd1c9ecb98) at ../block/qapi.c:155
-#9  0x000056310e1e6113 in bdrv_named_nodes_list (flat=<optimized out>, errp=errp@entry=0x7ffd1c9ecb98) at ../block.c:6207
-#10 0x000056310e1d7092 in qmp_query_named_block_nodes (has_flat=<optimized out>, flat=<optimized out>, errp=errp@entry=0x7ffd1c9ecb98) at ../blockdev.c:2785
-#11 0x000056310e28c31b in qmp_marshal_query_named_block_nodes (args=0x7f579800bbc0, ret=0x7f59b8a6ceb8, errp=0x7f59b8a6ceb0) at qapi/qapi-commands-block-core.c:553
-#12 0x000056310e2e0dbd in do_qmp_dispatch_bh (opaque=0x7f59b8a6cec0) at ../qapi/qmp-dispatch.c:128
-#13 0x000056310e300085 in aio_bh_poll (ctx=ctx@entry=0x563110233e70) at ../util/async.c:216
-#14 0x000056310e2ea972 in aio_dispatch (ctx=0x563110233e70) at ../util/aio-posix.c:423
-#15 0x000056310e2ffe12 in aio_ctx_dispatch (source=<optimized out>, callback=<optimized out>, user_data=<optimized out>) at ../util/async.c:358
-#16 0x00007f59ba648d6f in g_main_context_find_source_by_user_data () from /lib64/libglib-2.0.so.0
-#17 0x000056310f060908 in iohandler_ctx ()
-#18 0x00007ffd1c9ecd40 in ?? ()
-#19 0x000056310e301640 in glib_pollfds_poll () at ../util/main-loop.c:290
-#20 os_host_main_loop_wait (timeout=0) at ../util/main-loop.c:313
-#21 main_loop_wait (nonblocking=nonblocking@entry=0) at ../util/main-loop.c:592
-#22 0x000056310e00f9b7 in qemu_main_loop () at ../system/runstate.c:782
-#23 0x000056310dedd3ab in qemu_default_main () at ../system/main.c:37
-#24 0x00007f59ba1eaeb0 in __libc_start_call_main () from /lib64/libc.so.6
-#25 0x00007f59ba1eaf60 in __libc_start_main_impl () from /lib64/libc.so.6
-#26 0x000056310dedd2d5 in _start ()
-```
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_KVM/2669 b/gitlab/issues_text/target_i386/host_missing/accel_KVM/2669
deleted file mode 100644
index 026572f88..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_KVM/2669
+++ /dev/null
@@ -1,18 +0,0 @@
-CPU Hotplug (Host Model) Causes the Windows VM to BSOD
-Description of problem:
-The QEMU runs on a host with the Intel(R) Xeon(R) CPU E3-1230 v6 CPU which supports Software Guard Extension (SGX). I start a VM with Windows Server 2019 inside and with `-cpu host,...`. When I attempts to hotplug additional CPU (when the VM is running), the OS issues a bug check 0x3e (`MULTIPROCESSOR_CONFIGURATION_NOT_SUPPORTED`). The problem is that the newly hotplugged CPU is not evaluated as "equivalent enough" compared to the already present CPUs. I did some more digging and reverse engineering and it looks like the CPU being hotplugged has SGX turned off. This seems to be fixed when the VM reboots.
-
-I tried to disable SGX through `-cpu host,-sgx` which helps (the VM successfully accepts the hotplugged CPU), however, `+sgx` does not help (seems to have no effect on the CPU being hotplugged).
-
-My goal is to be able to hotplug CPUs even when the host CPU supports SGX.
-
-I tested with QEMU 8.0.0, 9.1.0, 9.1.1 and 9.1.50 (current master) but with no luck.
-Steps to reproduce:
-1. Create a simple Windows VM,
-2. start the VM,
-3. use `qpm-shell` to hotplug a CPU (https://www.qemu.org/docs/master/system/cpu-hotplug.html).
-
-I can provide you the VM as well but its image (QCOW2) has around 10G in size.
-
-Best regards
-Martin Dráb
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_KVM/2731 b/gitlab/issues_text/target_i386/host_missing/accel_KVM/2731
deleted file mode 100644
index 556a95600..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_KVM/2731
+++ /dev/null
@@ -1,344 +0,0 @@
-test_kvm_xen_guest_novector_noapic sometimes fails
-Description of problem:
-The test_kvm_xen_guest_novector_noapic test of tests/avocado/kvm_xen_guest.py (soon to be moved to tests/functional/test_x86_64_kvm_xen.py ) is sometimes (maybe 1 time out of 50) failing to boot to the shell prompt. The messages on the serial console are:
-
-```
-Linux version 6.3.0-rc3-00031-g1e760fa3596e (alex@zen) (gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #21 SMP PREEMPT_DYNAMIC Fri Mar 24 15:04:37 GMT 2023
-Command line: printk.time=0 root=/dev/xvda console=ttyS0 xen_emul_unplug=ide-disks xen_no_vector_callback noapic
-x86/fpu: x87 FPU will use FXSAVE
-signal: max sigframe size: 1440
-BIOS-provided physical RAM map:
-BIOS-e820: [mem 0x0000000000000000-0x000000000009fbff] usable
-BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff] reserved
-BIOS-e820: [mem 0x00000000000f0000-0x00000000000fffff] reserved
-BIOS-e820: [mem 0x0000000000100000-0x0000000007fdffff] usable
-BIOS-e820: [mem 0x0000000007fe0000-0x0000000007ffffff] reserved
-BIOS-e820: [mem 0x00000000feff8000-0x00000000feffffff] reserved
-BIOS-e820: [mem 0x00000000fffc0000-0x00000000ffffffff] reserved
-NX (Execute Disable) protection: active
-SMBIOS 2.8 present.
-DMI: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014
-Hypervisor detected: Xen HVM
-Xen version 4.10.
-last_pfn = 0x7fe0 max_arch_pfn = 0x400000000
-x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WP  UC- WT  
-found SMP MP-table at [mem 0x000f5470-0x000f547f]
-ACPI: Early table checksum verification disabled
-ACPI: RSDP 0x00000000000F5290 000014 (v00 BOCHS )
-ACPI: RSDT 0x0000000007FE237F 000034 (v01 BOCHS  BXPC     00000001 BXPC 00000001)
-ACPI: FACP 0x0000000007FE222B 000074 (v01 BOCHS  BXPC     00000001 BXPC 00000001)
-ACPI: DSDT 0x0000000007FE0040 0021EB (v01 BOCHS  BXPC     00000001 BXPC 00000001)
-ACPI: FACS 0x0000000007FE0000 000040
-ACPI: APIC 0x0000000007FE229F 000080 (v03 BOCHS  BXPC     00000001 BXPC 00000001)
-ACPI: HPET 0x0000000007FE231F 000038 (v01 BOCHS  BXPC     00000001 BXPC 00000001)
-ACPI: WAET 0x0000000007FE2357 000028 (v01 BOCHS  BXPC     00000001 BXPC 00000001)
-ACPI: Reserving FACP table memory at [mem 0x7fe222b-0x7fe229e]
-ACPI: Reserving DSDT table memory at [mem 0x7fe0040-0x7fe222a]
-ACPI: Reserving FACS table memory at [mem 0x7fe0000-0x7fe003f]
-ACPI: Reserving APIC table memory at [mem 0x7fe229f-0x7fe231e]
-ACPI: Reserving HPET table memory at [mem 0x7fe231f-0x7fe2356]
-ACPI: Reserving WAET table memory at [mem 0x7fe2357-0x7fe237e]
-Zone ranges:
-  DMA      [mem 0x0000000000001000-0x0000000000ffffff]
-  DMA32    [mem 0x0000000001000000-0x0000000007fdffff]
-  Normal   empty
-  Device   empty
-Movable zone start for each node
-Early memory node ranges
-  node   0: [mem 0x0000000000001000-0x000000000009efff]
-  node   0: [mem 0x0000000000100000-0x0000000007fdffff]
-Initmem setup node 0 [mem 0x0000000000001000-0x0000000007fdffff]
-On node 0, zone DMA: 1 pages in unavailable ranges
-On node 0, zone DMA: 97 pages in unavailable ranges
-On node 0, zone DMA32: 32 pages in unavailable ranges
-ACPI: LAPIC_NMI (acpi_id[0xff] dfl dfl lint[0x1])
-ACPI: Skipping IOAPIC probe due to 'noapic' option.
-ACPI: Using ACPI for processor (LAPIC) configuration information
-ACPI: HPET id: 0x8086a201 base: 0xfed00000
-Intel MultiProcessor Specification v1.4
-MPTABLE: OEM ID: BOCHSCPU
-MPTABLE: Product ID: 0.1         
-MPTABLE: APIC at: 0xFEE00000
-IOAPIC[0]: apic_id 0, version 32, address 0xfec00000, GSI 0-23
-Processors: 2
-smpboot: Allowing 2 CPUs, 0 hotplug CPUs
-[mem 0x08000000-0xfeff7fff] available for PCI devices
-Booting paravirtualized kernel on Xen HVM
-clocksource: refined-jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1910969940391419 ns
-setup_percpu: NR_CPUS:64 nr_cpumask_bits:2 nr_cpu_ids:2 nr_node_ids:1
-percpu: Embedded 44 pages/cpu s149304 r0 d30920 u1048576
-Built 1 zonelists, mobility grouping on.  Total pages: 31968
-Kernel command line: printk.time=0 root=/dev/xvda console=ttyS0 xen_emul_unplug=ide-disks xen_no_vector_callback noapic
-Dentry cache hash table entries: 16384 (order: 5, 131072 bytes, linear)
-Inode-cache hash table entries: 8192 (order: 4, 65536 bytes, linear)
-mem auto-init: stack:off, heap alloc:off, heap free:off
-Memory: 102364K/130552K available (12288K kernel code, 1699K rwdata, 3004K rodata, 1040K init, 2632K bss, 27928K reserved, 0K cma-reserved)
-SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
-Dynamic Preempt: full
-rcu: Preemptible hierarchical RCU implementation.
-rcu: 	RCU event tracing is enabled.
-rcu: 	RCU restricting CPUs from NR_CPUS=64 to nr_cpu_ids=2.
-rcu: RCU calculated value of scheduler-enlistment delay is 100 jiffies.
-rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=2
-NR_IRQS: 4352, nr_irqs: 440, preallocated irqs: 16
-xen:events: Using 2-level ABI
-rcu: srcu_init: Setting srcu_struct sizes based on contention.
-Console: colour *CGA 80x25
-Cannot get hvm parameter CONSOLE_EVTCHN (18): -22!
-printk: console [ttyS0] enabled
-ACPI: Core revision 20221020
-ACPI: setting ELCR to 0200 (from 0c00)
-clocksource: hpet: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604467 ns
-APIC: Switch to symmetric I/O mode setup
-Not enabling interrupt remapping due to skipped IO-APIC setup
-tsc: Unable to calibrate against PIT
-tsc: using HPET reference calibration
-tsc: Detected 2496.010 MHz processor
-clocksource: tsc-early: mask: 0xffffffffffffffff max_cycles: 0x23fa80a809f, max_idle_ns: 440795273818 ns
-Calibrating delay loop (skipped), value calculated using timer frequency.. 4992.02 BogoMIPS (lpj=2496010)
-pid_max: default: 32768 minimum: 301
-LSM: initializing lsm=capability,yama,integrity,selinux
-Yama: becoming mindful.
-SELinux:  Initializing.
-Mount-cache hash table entries: 512 (order: 0, 4096 bytes, linear)
-Mountpoint-cache hash table entries: 512 (order: 0, 4096 bytes, linear)
-Last level iTLB entries: 4KB 0, 2MB 0, 4MB 0
-Last level dTLB entries: 4KB 0, 2MB 0, 4MB 0, 1GB 0
-Spectre V1 : Mitigation: usercopy/swapgs barriers and __user pointer sanitization
-Spectre V2 : Kernel not compiled with retpoline; no mitigation available!
-Spectre V2 : Vulnerable
-Spectre V2 : Spectre v2 / SpectreRSB mitigation: Filling RSB on context switch
-Speculative Store Bypass: Vulnerable
-MDS: Vulnerable: Clear CPU buffers attempted, no microcode
-MMIO Stale Data: Unknown: No mitigations
-Freeing SMP alternatives memory: 24K
-APIC timer disabled due to verification failure
-smpboot: CPU0: Intel QEMU Virtual CPU version 2.5+ (family: 0xf, model: 0x6b, stepping: 0x1)
-Performance Events: unsupported Netburst CPU model 107 no PMU driver, software events only.
-rcu: Hierarchical SRCU implementation.
-rcu: 	Max phase no-delay instances is 400.
-NMI watchdog: Perf NMI watchdog permanently disabled
-smp: Bringing up secondary CPUs ...
-x86: Booting SMP configuration:
-.... node  #0, CPUs:      #1
-smp: Brought up 1 node, 2 CPUs
-smpboot: Max logical packages: 1
-smpboot: Total of 2 processors activated (9984.04 BogoMIPS)
-devtmpfs: initialized
-x86/mm: Memory block size: 128MB
-clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1911260446275000 ns
-futex hash table entries: 512 (order: 3, 32768 bytes, linear)
-PM: RTC time: 12:02:16, date: 2024-12-19
-NET: Registered PF_NETLINK/PF_ROUTE protocol family
-audit: initializing netlink subsys (disabled)
-audit: type=2000 audit(1734609736.239:1): state=initialized audit_enabled=0 res=1
-thermal_sys: Registered thermal governor 'step_wise'
-thermal_sys: Registered thermal governor 'user_space'
-cpuidle: using governor ladder
-cpuidle: using governor menu
-PCI: Using configuration type 1 for base access
-HugeTLB: registered 2.00 MiB page size, pre-allocated 0 pages
-HugeTLB: 28 KiB vmemmap can be freed for a 2.00 MiB page
-cryptd: max_cpu_qlen set to 1000
-ACPI: Added _OSI(Module Device)
-ACPI: Added _OSI(Processor Device)
-ACPI: Added _OSI(3.0 _SCP Extensions)
-ACPI: Added _OSI(Processor Aggregator Device)
-ACPI: 1 ACPI AML tables successfully acquired and loaded
-ACPI: Interpreter enabled
-ACPI: PM: (supports S0 S3 S5)
-ACPI: Using PIC for interrupt routing
-PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
-PCI: Using E820 reservations for host bridge windows
-ACPI: Enabled 2 GPEs in block 00 to 0F
-ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
-acpi PNP0A03:00: _OSC: OS supports [ASPM ClockPM Segments MSI HPX-Type3]
-acpi PNP0A03:00: PCIe port services disabled; not requesting _OSC control
-acpi PNP0A03:00: fail to add MMCONFIG information, can't access extended configuration space under this bridge
-PCI host bridge to bus 0000:00
-pci_bus 0000:00: root bus resource [io  0x0000-0x0cf7 window]
-pci_bus 0000:00: root bus resource [io  0x0d00-0xffff window]
-pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff window]
-pci_bus 0000:00: root bus resource [mem 0x08000000-0xfebfffff window]
-pci_bus 0000:00: root bus resource [mem 0x100000000-0x17fffffff window]
-pci_bus 0000:00: root bus resource [bus 00-ff]
-pci 0000:00:00.0: [8086:1237] type 00 class 0x060000
-pci 0000:00:01.0: [8086:7000] type 00 class 0x060100
-pci 0000:00:01.1: [8086:7010] type 00 class 0x010180
-pci 0000:00:01.1: reg 0x20: [io  0xc120-0xc12f]
-pci 0000:00:01.1: legacy IDE quirk: reg 0x10: [io  0x01f0-0x01f7]
-pci 0000:00:01.1: legacy IDE quirk: reg 0x14: [io  0x03f6]
-pci 0000:00:01.1: legacy IDE quirk: reg 0x18: [io  0x0170-0x0177]
-pci 0000:00:01.1: legacy IDE quirk: reg 0x1c: [io  0x0376]
-pci 0000:00:01.3: [8086:7113] type 00 class 0x068000
-pci 0000:00:01.3: quirk: [io  0x0600-0x063f] claimed by PIIX4 ACPI
-pci 0000:00:01.3: quirk: [io  0x0700-0x070f] claimed by PIIX4 SMB
-pci 0000:00:02.0: [5853:0001] type 00 class 0xff8000
-pci 0000:00:02.0: reg 0x10: [io  0xc000-0xc0ff]
-pci 0000:00:02.0: reg 0x14: [mem 0xfd000000-0xfdffffff pref]
-pci 0000:00:03.0: [1af4:1000] type 00 class 0x020000
-pci 0000:00:03.0: reg 0x10: [io  0xc100-0xc11f]
-pci 0000:00:03.0: reg 0x14: [mem 0xfebc0000-0xfebc0fff]
-pci 0000:00:03.0: reg 0x20: [mem 0xfe000000-0xfe003fff 64bit pref]
-pci 0000:00:03.0: reg 0x30: [mem 0xfeb80000-0xfebbffff pref]
-ACPI: PCI: Interrupt link LNKA configured for IRQ 10
-ACPI: PCI: Interrupt link LNKB configured for IRQ 10
-ACPI: PCI: Interrupt link LNKC configured for IRQ 11
-ACPI: PCI: Interrupt link LNKD configured for IRQ 11
-ACPI: PCI: Interrupt link LNKS configured for IRQ 9
-xen:balloon: Initialising balloon driver
-iommu: Default domain type: Translated 
-iommu: DMA domain TLB invalidation policy: lazy mode 
-SCSI subsystem initialized
-ACPI: bus type USB registered
-usbcore: registered new interface driver usbfs
-usbcore: registered new interface driver hub
-usbcore: registered new device driver usb
-pps_core: LinuxPPS API ver. 1 registered
-pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
-PTP clock support registered
-Advanced Linux Sound Architecture Driver Initialized.
-PCI: Using ACPI for IRQ routing
-hpet: 3 channels of 0 reserved for per-cpu timers
-clocksource: Switched to clocksource tsc-early
-FS-Cache: Loaded
-pnp: PnP ACPI init
-pnp: PnP ACPI: found 6 devices
-NET: Registered PF_INET protocol family
-IP idents hash table entries: 2048 (order: 2, 16384 bytes, linear)
-tcp_listen_portaddr_hash hash table entries: 128 (order: 0, 4096 bytes, linear)
-Table-perturb hash table entries: 65536 (order: 6, 262144 bytes, linear)
-TCP established hash table entries: 1024 (order: 1, 8192 bytes, linear)
-TCP bind hash table entries: 1024 (order: 4, 65536 bytes, linear)
-TCP: Hash tables configured (established 1024 bind 1024)
-UDP hash table entries: 256 (order: 2, 24576 bytes, linear)
-UDP-Lite hash table entries: 256 (order: 2, 24576 bytes, linear)
-NET: Registered PF_UNIX/PF_LOCAL protocol family
-RPC: Registered named UNIX socket transport module.
-RPC: Registered udp transport module.
-RPC: Registered tcp transport module.
-RPC: Registered tcp NFSv4.1 backchannel transport module.
-pci_bus 0000:00: resource 4 [io  0x0000-0x0cf7 window]
-pci_bus 0000:00: resource 5 [io  0x0d00-0xffff window]
-pci_bus 0000:00: resource 6 [mem 0x000a0000-0x000bffff window]
-pci_bus 0000:00: resource 7 [mem 0x08000000-0xfebfffff window]
-pci_bus 0000:00: resource 8 [mem 0x100000000-0x17fffffff window]
-pci 0000:00:01.0: PIIX3: Enabling Passive Release
-pci 0000:00:00.0: Limiting direct PCI/PCI transfers
-PCI: CLS 0 bytes, default 64
-kvm_intel: VMX not supported by CPU 0
-workingset: timestamp_bits=46 max_order=15 bucket_order=0
-squashfs: version 4.0 (2009/01/31) Phillip Lougher
-fuse: init (API version 7.38)
-9p: Installing v9fs 9p2000 file system support
-Block layer SCSI generic (bsg) driver version 0.4 loaded (major 245)
-io scheduler mq-deadline registered
-io scheduler kyber registered
-ACPI: \_SB_.LNKC: Enabled at IRQ 11
-xen:xen_evtchn: Event-channel device installed
-ACPI: \_SB_.LNKB: Enabled at IRQ 10
-xen:grant_table: Grant tables using version 1 layout
-Grant table initialized
-Cannot get hvm parameter CONSOLE_EVTCHN (18): -22!
-Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
-00:04: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A
-Non-volatile memory driver v1.3
-ACPI: bus type drm_connector registered
-loop: module loaded
-Invalid max_queues (4), will use default max: 2.
-tun: Universal TUN/TAP device driver, 1.6
-e100: Intel(R) PRO/100 Network Driver
-e100: Copyright(c) 1999-2006 Intel Corporation
-e1000: Intel(R) PRO/1000 Network Driver
-e1000: Copyright (c) 1999-2006 Intel Corporation.
-e1000e: Intel(R) PRO/1000 Network Driver
-e1000e: Copyright(c) 1999 - 2015 Intel Corporation.
-igb: Intel(R) Gigabit Ethernet Network Driver
-igb: Copyright (c) 2007-2014 Intel Corporation.
-igbvf: Intel(R) Gigabit Virtual Function Network Driver
-igbvf: Copyright (c) 2009 - 2012 Intel Corporation.
-VMware vmxnet3 virtual NIC driver - version 1.7.0.0-k-NAPI
-xen_netfront: Initialising Xen virtual ethernet driver
-usbcore: registered new interface driver cdc_ether
-usbcore: registered new interface driver cdc_eem
-usbcore: registered new interface driver cdc_ncm
-usbcore: registered new interface driver r8153_ecm
-usbcore: registered new interface driver cdc_acm
-cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters
-usbcore: registered new interface driver usb-storage
-usbcore: registered new interface driver usbserial_generic
-usbserial: USB Serial support registered for generic
-usbcore: registered new interface driver ch341
-usbserial: USB Serial support registered for ch341-uart
-usbcore: registered new interface driver cp210x
-usbserial: USB Serial support registered for cp210x
-usbcore: registered new interface driver ftdi_sio
-usbserial: USB Serial support registered for FTDI USB Serial Device
-usbcore: registered new interface driver keyspan
-usbserial: USB Serial support registered for Keyspan - (without firmware)
-usbserial: USB Serial support registered for Keyspan 1 port adapter
-usbserial: USB Serial support registered for Keyspan 2 port adapter
-usbserial: USB Serial support registered for Keyspan 4 port adapter
-usbcore: registered new interface driver pl2303
-usbserial: USB Serial support registered for pl2303
-usbcore: registered new interface driver usb_serial_simple
-usbserial: USB Serial support registered for carelink
-usbserial: USB Serial support registered for zio
-usbserial: USB Serial support registered for funsoft
-usbserial: USB Serial support registered for flashloader
-usbserial: USB Serial support registered for google
-usbserial: USB Serial support registered for libtransistor
-usbserial: USB Serial support registered for vivopay
-usbserial: USB Serial support registered for moto_modem
-usbserial: USB Serial support registered for motorola_tetra
-usbserial: USB Serial support registered for nokia
-usbserial: USB Serial support registered for novatel_gps
-usbserial: USB Serial support registered for hp4x
-usbserial: USB Serial support registered for suunto
-usbserial: USB Serial support registered for siemens_mpi
-rtc_cmos 00:05: RTC can wake from S4
-rtc_cmos 00:05: registered as rtc0
-rtc_cmos 00:05: alarms up to one day, y3k, 242 bytes nvram, hpet irqs
-fail to initialize ptp_kvm
-intel_pstate: CPU model not supported
-usbcore: registered new interface driver usbhid
-usbhid: USB HID core driver
-GACT probability NOT on
-xt_time: kernel timezone is -0000
-IPVS: Registered protocols (TCP, UDP)
-IPVS: Connection hash table configured (size=4096, memory=32Kbytes)
-IPVS: ipvs loaded.
-IPVS: [rr] scheduler registered.
-Initializing XFRM netlink socket
-NET: Registered PF_INET6 protocol family
-Segment Routing with IPv6
-In-situ OAM (IOAM) with IPv6
-NET: Registered PF_PACKET protocol family
-8021q: 802.1Q VLAN Support v1.8
-9pnet: Installing 9P2000 support
-NET: Registered PF_VSOCK protocol family
-IPI shorthand broadcast: enabled
-sched_clock: Marking stable (402156364, -4933103)->(420983909, -23760648)
-Clockevents: could not switch to one-shot mode: lapic is not functional.
-Could not switch to high resolution mode on CPU 0
-Clockevents: could not switch to one-shot mode: lapic is not functional.
-Could not switch to high resolution mode on CPU 1
-tsc: Refined TSC clocksource calibration: 2495.955 MHz
-clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x23fa4cd42c8, max_idle_ns: 440795310990 ns
-clocksource: Switched to clocksource tsc
-Clockevents: could not switch to one-shot mode: lapic is not functional.
-Could not switch to high resolution mode on CPU 1
-Clockevents: could not switch to one-shot mode: lapic is not functional.
-Could not switch to high resolution mode on CPU 0
-xenbus_probe_frontend: Waiting for devices to initialise: 25s...20s...15s...
-random: crng init done
-10s...5s...0s...
-```
-Steps to reproduce:
-Either run the mentioned avocado/functional test, or directly the mentioned QEMU command line >= 50 times
-Additional information:
-I think it reproduces more easily if the host machine is under load (not quite sure about it, though).
-
-See this discussion on the mailing list for some more details:
-
-https://lore.kernel.org/qemu-devel/999a8203f0c800f1305aacdb500dbf6038ebf147.camel@infradead.org/
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_KVM/2956 b/gitlab/issues_text/target_i386/host_missing/accel_KVM/2956
deleted file mode 100644
index e01737681..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_KVM/2956
+++ /dev/null
@@ -1,214 +0,0 @@
-AMD SEV-SNP: vhost-user-fs-pci iommu_platform=true is not supported by the device
-Description of problem:
-Trying to make use of `vhost-user-fs-pci` with `sev-snp-guest` enabled doesn't work.
-The system reports that `vhost-user-fs-pci` doesn't support IOMMU but as far as I understand
-we need IOMMU for the virtio protocol to fully function.
-Steps to reproduce:
-1. Ensure you are running on a system with AMD SNP support:
-```
-sudo dmesg | grep -i sev
-[    0.000000] SEV-SNP: RMP table physical range [0x000000bfbd000000 - 0x000000c07d8fffff]
-[    0.003807] SEV-SNP: Reserving start/end of RMP table on a 2MB boundary [0x000000c07d800000]
-[    8.085220] ccp 0000:06:00.5: sev enabled
-[   16.226155] ccp 0000:06:00.5: SEV API:1.55 build:28
-[   16.226162] ccp 0000:06:00.5: SEV-SNP API:1.55 build:28
-[   16.239284] kvm_amd: SEV enabled (ASIDs 15 - 1006)
-[   16.239289] kvm_amd: SEV-ES enabled (ASIDs 1 - 14)
-[   16.239292] kvm_amd: SEV-SNP enabled (ASIDs 1 - 14)
-```
-2. Use an OVMF which supports AMD SNP: https://github.com/tianocore/edk2.git branch: edk2-stable202502
-3. Launch the virtiofs daemon process.
-4. Launch qemu with device `vhost-user-fs-pci`
-5. The qemu process will terminate with the following error message:
-
-```
-qemu-system-x86_64: -device vhost-user-fs-pci,chardev=fs0,tag=cfg: iommu_platform=true is not supported by the device
-```
-Additional information:
-It does launch if I disable any AMD SEV-SNP functionality from the VM:
-
-```
-sudo ./qemu-system-x86_64  \
-         -nodefaults \
-	 -enable-kvm \
-	 -cpu host \
-	 -object memory-backend-memfd,id=mem0,size=2048M,share=on \
-	 -machine q35,memory-backend=mem0 \
-	 -smp cpus=1 \
-	 -drive file=ubuntu.qcow2,if=none,id=disk0,format=qcow2 \
-	 -device virtio-blk-pci,drive=disk0 \
-	 -device amd-iommu \
-	 -chardev socket,id=fs0,path=/var/run/virtiofs/cfg.sock \
-	 -device vhost-user-fs-pci,chardev=fs0,tag=cfg \
-	 -bios ./ovmf-dist/x86_64/OVMF.fd \
-	 -kernel ./linux-guest-6.12.15-1-/boot/vmlinuz-6.12.15-1 \
-	 -initrd ./initrd/initrd.img \
-	 -append 'console=ttyS0' \
-	 -display none
-	 -nographic
-	 -chardev stdio,id=stdio0,signal=off \
-	 -serial chardev:stdio0 \
-	 -D /tmp/qemu-vmm.log \
-	 -d 'guest_errors,unimp,trace:virtio*'
-```
-
-BTW: I've also managed to reproduce the same bug on AMD's fork:
-- Repo: https://github.com/AMDESE/qemu.git
-- Branch: snp-latest
-
-Configure flags:
-```
-    --target-list=x86_64-softmmu \
-    --prefix=/builder/out/qemu-dist \
-    --sysconfdir=/builder/out/qemu-dist/etc \
-    --libdir=/builder/out/qemu-dist/lib \
-    --libexecdir=/builder/out/qemu-dist/lib/qemu \
-    --localstatedir=/builder/out/qemu-dist/var \
-    --ninja=/usr/bin/ninja \
-    --python=/usr/bin/python3 \
-    --with-pkgversion=qemu \
-    --cc=/usr/bin/x86_64-linux-gnu-gcc-13 \
-    --static \
-    --disable-cocoa \
-    --disable-curses \
-    --disable-dbus-display \
-    --disable-gtk \
-    --disable-gtk-clipboard \
-    --disable-opengl \
-    --disable-png \
-    --disable-sdl \
-    --disable-sdl-image \
-    --disable-spice \
-    --disable-spice-protocol \
-    --disable-virglrenderer \
-    --disable-vnc \
-    --disable-vnc-jpeg \
-    --disable-vnc-sasl \
-    --disable-vte \
-    --disable-alsa \
-    --disable-coreaudio \
-    --disable-dsound \
-    --disable-jack \
-    --disable-oss \
-    --disable-pa \
-    --disable-pipewire \
-    --disable-sndio \
-    --disable-vvfat \
-    --disable-vdi \
-    --disable-qed \
-    --disable-qcow1 \
-    --disable-bochs \
-    --disable-cloop \
-    --disable-dmg \
-    --disable-parallels \
-    --disable-vpc \
-    --disable-vmdk \
-    --disable-vhdx \
-    --disable-bzip2 \
-    --disable-lzfse \
-    --disable-snappy \
-    --disable-lzo \
-    --disable-netmap \
-    --disable-l2tpv3 \
-    --disable-slirp-smbd \
-    --disable-vde \
-    --disable-vmnet \
-    --disable-vhost-user-blk-server \
-    --disable-vfio-user-server \
-    --disable-curl \
-    --disable-glusterfs \
-    --disable-libiscsi \
-    --disable-libnfs \
-    --disable-libssh \
-    --disable-mpath \
-    --disable-rbd \
-    --disable-vduse-blk-export \
-    --disable-virtfs \
-    --disable-fuse \
-    --disable-fuse-lseek \
-    --disable-blkio \
-    --disable-nettle \
-    --disable-gcrypt \
-    --disable-gnutls \
-    --disable-crypto-afalg \
-    --disable-libkeyutils \
-    --disable-libkeyutils \
-    --disable-auth-pam \
-    --disable-keyring \
-    --disable-selinux \
-    --disable-u2f \
-    --disable-brlapi \
-    --disable-canokey \
-    --disable-hvf \
-    --disable-hv-balloon \
-    --disable-libdaxctl \
-    --disable-libudev \
-    --disable-libusb \
-    --disable-nvmm \
-    --disable-rdma \
-    --disable-smartcard \
-    --disable-usb-redir \
-    --disable-whpx \
-    --disable-xen \
-    --disable-xen-pci-passthrough \
-    --disable-guest-agent \
-    --disable-guest-agent-msi \
-    --disable-colo-proxy \
-    --disable-rutabaga-gfx \
-    --disable-vhost-crypto \
-    --disable-capstone \
-    --disable-docs \
-    --disable-gettext \
-    --disable-iconv \
-    --disable-libdw \
-    --disable-pixman \
-    --disable-sparse \
-    --disable-xkbcommon \
-    --disable-attr \
-    --disable-gio \
-    --disable-multiprocess \
-    --disable-plugins \
-    --disable-qpl \
-    --disable-replication \
-    --disable-uadk \
-    --disable-libvduse \
-    --disable-libpmem \
-    --disable-user \
-    --disable-bsd-user \
-    --disable-linux-user \
-    --disable-tcg \
-    --disable-debug-tcg \
-    --disable-tcg-interpreter \
-    --disable-hexagon-idef-parser \
-    --disable-qom-cast-debug \
-    --enable-kvm \
-    --enable-system \
-    --enable-pie \
-    --enable-lto \
-    --enable-af-xdp \
-    --enable-slirp \
-    --enable-vhost-kernel \
-    --enable-vhost-net \
-    --enable-vhost-user \
-    --enable-vhost-vdpa \
-    --enable-bpf \
-    --enable-coroutine-pool \
-    --enable-linux-aio \
-    --enable-linux-io-uring \
-    --enable-malloc-trim \
-    --enable-membarrier \
-    --enable-cap-ng \
-    --enable-seccomp \
-    --enable-stack-protector \
-    --enable-tpm \
-    --enable-zstd \
-    --enable-numa \
-    --enable-fdt=disabled \
-    --enable-install-blobs \
-    --enable-tools \
-    --enable-trace-backends=log \
-    --enable-strip \
-    --x86-version=4 \
-    --extra-cflags=-O2 -fno-semantic-interposition -fdevirtualize-at-ltrans -flto=auto -fuse-linker-plugin -falign-functions=32 -D_FORTIFY_SOURCE=2 -Wno-deprecated-declarations -Wno-error=stringop-overflow -Wformat -Werror=format-security -Werror=implicit-function-declaration -fstack-protector-strong -fstack-clash-protection -fcf-protection -fipa-pta \
-    --extra-ldflags=-Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now -Wl,-O1 -Wl,--as-needed
-```
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_KVM/352 b/gitlab/issues_text/target_i386/host_missing/accel_KVM/352
deleted file mode 100644
index 3285d990c..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_KVM/352
+++ /dev/null
@@ -1 +0,0 @@
-audio input crack
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_KVM/353 b/gitlab/issues_text/target_i386/host_missing/accel_KVM/353
deleted file mode 100644
index ab9a98991..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_KVM/353
+++ /dev/null
@@ -1 +0,0 @@
-video capture, slowness
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_KVM/361 b/gitlab/issues_text/target_i386/host_missing/accel_KVM/361
deleted file mode 100644
index f1c6645d8..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_KVM/361
+++ /dev/null
@@ -1 +0,0 @@
--cpu host results in unsupported AVX512 instructions
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_KVM/466 b/gitlab/issues_text/target_i386/host_missing/accel_KVM/466
deleted file mode 100644
index 3d8481962..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_KVM/466
+++ /dev/null
@@ -1 +0,0 @@
-3x 100% host CPU core usage while virtual machine is in idle
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_KVM/530 b/gitlab/issues_text/target_i386/host_missing/accel_KVM/530
deleted file mode 100644
index 8c2328a8e..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_KVM/530
+++ /dev/null
@@ -1,43 +0,0 @@
-Invalid guest state when rebooting a nesting hypervisor
-Description of problem:
-On a standard Linux machine, I run a custom hypervisor stack based on [Hedron](https://github.com/cyberus-technology/hedron) in a qemu VM with nesting capabilities. The Hedron stack starts a nested Linux guest with complete pass-through of all resources not required for virtualizing the nested guest. In particular, ACPI and PCI including the reset functionality are directly accessible to the nested guest. As soon as the nested guest issues a machine reset, I get a hardware error with the following error message:
-
-<details><summary>KVM: entry failed, hardware error 0x80000021</summary>
-<pre>
-If you're running a guest on an Intel machine without unrestricted mode
-support, the failure can be most likely due to the guest entering an invalid
-state for Intel VT. For example, the guest maybe running in big real mode
-which is not supported on less recent Intel processors.
-
-EAX=00000000 EBX=00000000 ECX=00000000 EDX=00050657
-ESI=00000000 EDI=00000000 EBP=00000000 ESP=00000000
-EIP=0000fff0 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
-ES =0000 00000000 0000ffff 00009300
-CS =f000 ffff0000 0000ffff 00009b00
-SS =0000 00000000 0000ffff 00009300
-DS =0000 00000000 0000ffff 00009300
-FS =0000 00000000 0000ffff 00009300
-GS =0000 00000000 0000ffff 00009300
-LDT=0000 00000000 0000ffff 00008200
-TR =0000 00000000 0000ffff 00008b00
-GDT=     00000000 0000ffff
-IDT=     00000000 0000ffff
-CR0=60000010 CR2=00000000 CR3=00000000 CR4=003726f8
-DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000
-DR6=00000000ffff0ff0 DR7=0000000000000400
-EFER=0000000000000000
-</pre>
-</details>
-
-If I'm not mistaken, the CR4 value of `0x003726f8` is the offending state here, because PCIDE (bit 17) is set, even though the arch state indicates real-mode and the Intel SDM states:
-
-> If the “IA-32e mode guest” VM-entry control is 0, bit 17 in the CR4 field (corresponding to CR4.PCIDE) must be 0.
-
-Furthermore, the issue is not present when not using PCID in the L1 hypervisor or when PCID/VPID are fused out using `qemu-kvm -cpu host,-pcid,-vmx-vpid,-vmx-invpcid-exit`.
-Steps to reproduce:
-1. Boot custom hypervisor stack (unfortunately not yet publicly available, I'm working on that)
-2. In nested Linux guest, type `reboot`, which eventually directly reboots the main VM (all main VM hardware is passed through to the single nested guest)
-Additional information:
-I have tracked down the [change](https://gitlab.com/qemu/qemu/-/commit/b16c0e20c74218f2d69710cedad11da7dd4d2190#063d8f78716c7a658841a1d51cc66bf30f697082_3920_3944) that likely introduced this issue. Moving the call to `kvm_put_sregs` back down (I suspect after `kvm_put_nested_state`, but I did not verify that yet) solves the reboot issue for me. The comment makes it clear that it is important to keep a certain order here, so I'm aware just reversing it is not an option.
-
-Maybe this already helps enough to figure out what exactly the issue and correct fix is, and I am happy to try any suggestions as long as I cannot provide a proper reproducer.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_KVM/674 b/gitlab/issues_text/target_i386/host_missing/accel_KVM/674
deleted file mode 100644
index 2ba7d97ea..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_KVM/674
+++ /dev/null
@@ -1,14 +0,0 @@
-Windows 7 fails with blue screen when KVM is enabled.
-Description of problem:
-The problem appeared immediately after a full system update of Arch Linux (The first for several months). Windows 7 images that had been running normally would fail with a blue screen and Error 0x7E immediately after displaying "Starting Windows". The same error would occur with a Windows 7 installation image, as in the command line above. When the "-enable-kvm" option was removed Windows would run normally but slowly. An old Clonezilla image booted without apparent problems.
-
-The final line on the blue screen reads:
-*** STOP: 0x0000007E (0xC0000005,0x8BA3CA36,0x85186AA0,0x85186680)
-
-After getting the problem with the Arch package I cloned the source and built the latest version, getting the same error. However, when I build version 5.2.95 (v6.0.0-rc5-dirty) I found that this would run my existing Windows images (qcow2) and the installation ISO image.
-Steps to reproduce:
-1.
-2.
-3.
-Additional information:
-
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_KVM/742 b/gitlab/issues_text/target_i386/host_missing/accel_KVM/742
deleted file mode 100644
index 1a48498c0..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_KVM/742
+++ /dev/null
@@ -1,44 +0,0 @@
-Cache Layout wrong on many Zen Arch CPUs
-Description of problem:
-This is `coreinfo -l` when running Windows as host:
-
-![image](/uploads/b4217fd80071c95e20e7d729e0fd19fa/image.png)
-
-This is `coreinfo -l` when running the same Windows as guest with 6 cores and 6 threads (half of each):
-
-![image](/uploads/bb6f2ccbec661273e83e36d3e1bff309/image.png)
-Steps to reproduce:
-1. You need a AMD Ryzen 3900X. It has an L3 cache over 3 cores
-2. Use `-cpu host,+topoext,host-cache-info=on`
-3. Use `coreinfo -l` to see how the L3 cache is distributed
-Additional information:
-1. When running without `host-cache-info=on` then the L3 cache is spread on all the cpus.
-2. `lscpu -e`:
-
-```
-CPU NODE SOCKET CORE L1d:L1i:L2:L3 ONLINE    MAXMHZ    MINMHZ      MHZ
-  0    0      0    0 0:0:0:0          yes 4672.0698 2200.0000 3800.000
-  1    0      0    1 1:1:1:0          yes 4672.0698 2200.0000 3800.000
-  2    0      0    2 2:2:2:0          yes 4672.0698 2200.0000 3800.000
-  3    0      0    3 4:4:4:1          yes 4672.0698 2200.0000 3800.000
-  4    0      0    4 5:5:5:1          yes 4672.0698 2200.0000 3800.000
-  5    0      0    5 6:6:6:1          yes 4672.0698 2200.0000 3800.000
-  6    0      0    6 8:8:8:2          yes 4672.0698 2200.0000 3800.000
-  7    0      0    7 9:9:9:2          yes 4672.0698 2200.0000 3610.580
-  8    0      0    8 10:10:10:2       yes 4672.0698 2200.0000 3800.000
-  9    0      0    9 12:12:12:3       yes 4672.0698 2200.0000 3800.000
- 10    0      0   10 13:13:13:3       yes 4672.0698 2200.0000 3800.000
- 11    0      0   11 14:14:14:3       yes 4672.0698 2200.0000 3800.000
- 12    0      0    0 0:0:0:0          yes 4672.0698 2200.0000 3800.000
- 13    0      0    1 1:1:1:0          yes 4672.0698 2200.0000 3800.000
- 14    0      0    2 2:2:2:0          yes 4672.0698 2200.0000 3800.000
- 15    0      0    3 4:4:4:1          yes 4672.0698 2200.0000 3800.000
- 16    0      0    4 5:5:5:1          yes 4672.0698 2200.0000 3800.000
- 17    0      0    5 6:6:6:1          yes 4672.0698 2200.0000 3800.000
- 18    0      0    6 8:8:8:2          yes 4672.0698 2200.0000 3800.000
- 19    0      0    7 9:9:9:2          yes 4672.0698 2200.0000 3800.000
- 20    0      0    8 10:10:10:2       yes 4672.0698 2200.0000 3800.000
- 21    0      0    9 12:12:12:3       yes 4672.0698 2200.0000 3800.000
- 22    0      0   10 13:13:13:3       yes 4672.0698 2200.0000 3800.000
- 23    0      0   11 14:14:14:3       yes 4672.0698 2200.0000 3800.000
-```
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_KVM/755 b/gitlab/issues_text/target_i386/host_missing/accel_KVM/755
deleted file mode 100644
index 6a6977f2f..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_KVM/755
+++ /dev/null
@@ -1,59 +0,0 @@
-Qemu is stuck on the startup intermittently.
-Description of problem:
-Qemu is stuck on the startup intermittently. 
-
-We are using kubevirt to launch the VM in kubernetes env. We have compiled qemu with a few flags enabled and using it. 
-All things are working as expected except we are seeing qemu stuck issue during VM startup. Please find logs from system in additional information
-
-Qemu version: qemu-system-x86-core-5.1.0-9.fc32.x86_64.rpm
-Libvirtd version: 6.6.0
-Steps to reproduce:
-1. Create and start a VM.
-Additional information:
-TOP OUTPUT:
---------------
-```
-  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND                                                                                                                                                  
-  **125 qemu       0 -20 8519896  73392  15412 R  99.9   0.1  85:27.96 CPU 0/KVM **                                                                                                                                               
-  113 qemu      20   0 8519896  73392  15412 S   0.0   0.1   0:00.14 qemu-system-ori                                                                                                                                          
-  121 qemu      20   0 8519896  73392  15412 S   0.0   0.1   0:00.00 qemu-system-ori                                                                                                                                          
-  122 qemu      20   0 8519896  73392  15412 S   0.0   0.1   0:00.00 IO iothread1                                                                                                                                             
-  124 qemu      20   0 8519896  73392  15412 S   0.0   0.1   0:00.23 IO mon_iothread                                                                                                                                          
-  126 qemu       0 -20 8519896  73392  15412 S   0.0   0.1   0:00.00 CPU 1/KVM                                                                                                                                                
-  128 qemu      20   0 8519896  73392  15412 S   0.0   0.1   0:00.00 vnc_worker 
-```
-
-qemu logs on error:
--------------------
-```
-KVM: injection failed, MSI lost (Operation not permitted)
-KVM: injection failed, MSI lost (Operation not permitted)
-KVM: injection failed, MSI lost (Operation not permitted)
-KVM: injection failed, MSI lost (Operation not permitted)
-KVM: injection failed, MSI lost (Operation not permitted)
-KVM: injection failed, MSI lost (Operation not permitted)
-KVM: injection failed, MSI lost (Operation not permitted)
-```
-
-dmesg logs from host:-
-----------------------
-```
-[ 7853.643187] kvm: apic: phys broadcast and lowest prio
-[ 7853.643265] kvm: apic: phys broadcast and lowest prio
-[ 7853.643341] kvm: apic: phys broadcast and lowest prio
-[ 7853.643413] kvm: apic: phys broadcast and lowest prio
-[ 7853.643486] kvm: apic: phys broadcast and lowest prio
-[ 7853.643559] kvm: apic: phys broadcast and lowest prio
-[ 7853.643631] kvm: apic: phys broadcast and lowest prio
-[ 7853.643703] kvm: apic: phys broadcast and lowest prio
-[ 7853.643776] kvm: apic: phys broadcast and lowest prio
-[ 7853.643848] kvm: apic: phys broadcast and lowest prio
-[ 7853.643920] kvm: apic: phys broadcast and lowest prio
-[ 7853.643992] kvm: apic: phys broadcast and lowest prio
-[ 7853.644065] kvm: apic: phys broadcast and lowest prio
-[ 7853.644137] kvm: apic: phys broadcast and lowest prio
-[ 7853.644209] kvm: apic: phys broadcast and lowest prio
-[ 7853.644289] kvm: apic: phys broadcast and lowest prio
-```
-
--->
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_KVM/772 b/gitlab/issues_text/target_i386/host_missing/accel_KVM/772
deleted file mode 100644
index 0113425f7..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_KVM/772
+++ /dev/null
@@ -1,12 +0,0 @@
-Pop!_OS 20.10 host + RHEL 8.5 guest = Oh no! Something has gone wrong.
-Description of problem:
-Whenever starting the Qemu VM, there is an error covering the whole desktop "Oh no! Something has gone wrong. A problem has occurred and the system can't recover. Please log out and try again." After clicking the "Log Out" button and waiting for hours, the guest RHEL may or may not recover, based on your luck and other qemu options used.
-Steps to reproduce:
-1. Build qemu using the following `./configure` options:
-```
---prefix=$HOME/.bin --target-list=x86_64-softmmu --enable-kvm --enable-vnc --enable-gtk --enable-vte --enable-xkbcommon --enable-sdl --enable-spice --enable-spice-protocol --enable-virglrenderer --enable-opengl --enable-guest-agent --enable-avx2 --enable-avx512f --enable-hax --enable-system --enable-linux-user --enable-libssh --enable-linux-aio --enable-linux-io-uring --enable-modules --enable-gio --enable-fuse --enable-fuse-lseek
-```
-2. Install Red Hat Enterprise Linux 8.5 in qemu
-3. Run qemu using the above command line.
-Additional information:
-![image](/uploads/6ccb8dabb1022b548975e63b389a037a/image.png)
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_KVM/777 b/gitlab/issues_text/target_i386/host_missing/accel_KVM/777
deleted file mode 100644
index 8561941f1..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_KVM/777
+++ /dev/null
@@ -1,9 +0,0 @@
-Hang on Alder Lake with multiple cores
-Description of problem:
-The guest silently hangs after a few seconds or minutes. No output in log, no errors in guest.
-Steps to reproduce:
-1. Start guest, do anything or nothing for a few minutes
-Additional information:
-More cores seem to make it less stable. With a single core, I haven't had a problem but at 8 cores it usually doesn't make it much past login on Windows or Linux.
-
-The guests are stable with 8 cores if I pin the vcpus to P cores.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_KVM/916 b/gitlab/issues_text/target_i386/host_missing/accel_KVM/916
deleted file mode 100644
index 0e4a0de6f..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_KVM/916
+++ /dev/null
@@ -1,11 +0,0 @@
-QEMU system emulators immediately crash on AMD hosts when KVM is used
-Description of problem:
-```
-$ qemu-system-x86_64  -accel kvm
-qemu-system-x86_64: ../target/i386/kvm/kvm-cpu.c:105: kvm_cpu_xsave_init: Assertion `esa->size == eax' failed.
-Aborted (core dumped)
-```
-
-This is a regression introduced in
-
-https://lists.gnu.org/archive/html/qemu-devel/2022-03/msg04312.html
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_KVM/954 b/gitlab/issues_text/target_i386/host_missing/accel_KVM/954
deleted file mode 100644
index d2ad8d1da..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_KVM/954
+++ /dev/null
@@ -1,1257 +0,0 @@
-qemu 6.2.0 with SEV in x86_64 initrd unpack ?
-Description of problem:
-The guest kernel panic from qemu 6.2.0, works fine on 6.0.0 and 6.1.0, works fine without SEV on 6.2.0 too.
-
-From our research it seems that initrd is not unpacked and initialized in an SEV context on 6.2.0 as we can see in logs without SEV that the initrd is well unpacked. Please have a look on additional informations for all the logs.
-
-We can see this crash during guest initialization:  
-```
-[    0.252891] VFS: Cannot open root device \(null)\ or unknown-block(0,0): error -6
-[    0.253054] Please append a correct \root=\ boot option; here are the available partitions:
-[    0.253179] 0100            4096 ram0 
-[    0.253181]  (driver?)
-[    0.253285] 0101            4096 ram1 
-[    0.253286]  (driver?)
-[    0.253389] 0102            4096 ram2 
-[    0.253390]  (driver?)
-[    0.253490] 0103            4096 ram3 
-[    0.253491]  (driver?)
-[    0.253595] 0104            4096 ram4 
-[    0.253596]  (driver?)
-[    0.253708] 0105            4096 ram5 
-[    0.253709]  (driver?)
-[    0.253816] 0106            4096 ram6 
-[    0.253817]  (driver?)
-[    0.253965] 0107            4096 ram7 
-[    0.253967]  (driver?)
-[    0.254065] 0108            4096 ram8 
-[    0.254066]  (driver?)
-[    0.254170] 0109            4096 ram9 
-[    0.254171]  (driver?)
-[    0.254274] 010a            4096 ram10 
-[    0.254276]  (driver?)
-[    0.254392] 010b            4096 ram11 
-[    0.254393]  (driver?)
-[    0.254514] 010c            4096 ram12 
-[    0.254516]  (driver?)
-[    0.254639] 010d            4096 ram13 
-[    0.254640]  (driver?)
-[    0.254755] 010e            4096 ram14 
-[    0.254756]  (driver?)
-[    0.254871] 010f            4096 ram15 
-[    0.254872]  (driver?)
-[    0.254996] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
-[    0.255115] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.15.31 #1
-[    0.255215] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
-[    0.255339] Call Trace:
-[    0.255387]  <TASK>
-[    0.255430]  dump_stack_lvl+0x34/0x44
-[    0.255499]  panic+0xe8/0x27a
-[    0.255563]  mount_block_root+0x16b/0x1fe
-[    0.255631]  ? rest_init+0xc0/0xc0
-[    0.255692]  prepare_namespace+0x131/0x160
-[    0.255757]  ? rest_init+0xc0/0xc0
-[    0.255823]  kernel_init+0x11/0x100
-[    0.255889]  ret_from_fork+0x22/0x30
-[    0.255969]  </TASK>
-[    0.256061] Kernel Offset: disabled
-[    0.256130] Rebooting in 1 seconds..
-```
-Steps to reproduce:
-1. build kernel with right config (build_kernel from kata-containers) with sev support (-x sev) & get kata-containers initrd
-2. Launch the command on a AMD SEV compatible device
-
-This is a complex problem I guess I can provide more informations if needed.
-Additional information:
-We didn't see any logs from QEMU when running this command line even when putting -D file...
-
-Complete output from QEMU 6.2.0 with SEV :  
-```
-[    0.000000] Linux version 5.10.25 (gitlab-runner@runner-buildah0) (gcc (Debian 11.2.0-12) 11.2.0, GNU ld (GNU Binutils for Debian) 2.37) #1 SMP Tue Dec 7 11:43:22 CET 2021
-[    0.000000] Command line: tsc=reliable no_timer_check rcupdate.rcu_expedited=1 i8042.direct=1 i8042.dumbkbd=1 i8042.nopnp=1 i8042.noaux=1 noreplace-smp reboot=k console=hvc0 console=hvc1 console=ttyS0 cryptomgr.notests net.ifnames=0 pci=lastbus=0 debug panic=1 nr_cpus=32 scsi_mod.scan=none agent.log=debug
-[    0.000000] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
-[    0.000000] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
-[    0.000000] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
-[    0.000000] x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
-[    0.000000] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'compacted' format.
-[    0.000000] BIOS-provided physical RAM map:
-[    0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009ffff] usable
-[    0.000000] BIOS-e820: [mem 0x0000000000100000-0x00000000007fffff] usable
-[    0.000000] BIOS-e820: [mem 0x0000000000800000-0x0000000000807fff] ACPI NVS
-[    0.000000] BIOS-e820: [mem 0x0000000000808000-0x000000000080ffff] usable
-[    0.000000] BIOS-e820: [mem 0x0000000000810000-0x00000000008fffff] ACPI NVS
-[    0.000000] BIOS-e820: [mem 0x0000000000900000-0x000000007f6eefff] usable
-[    0.000000] BIOS-e820: [mem 0x000000007f6ef000-0x000000007f96efff] reserved
-[    0.000000] BIOS-e820: [mem 0x000000007f96f000-0x000000007f97efff] ACPI data
-[    0.000000] BIOS-e820: [mem 0x000000007f97f000-0x000000007f9fefff] ACPI NVS
-[    0.000000] BIOS-e820: [mem 0x000000007f9ff000-0x000000007fe5ffff] usable
-[    0.000000] BIOS-e820: [mem 0x000000007fe60000-0x000000007fe7ffff] reserved
-[    0.000000] BIOS-e820: [mem 0x000000007fe80000-0x000000007fffffff] ACPI NVS
-[    0.000000] BIOS-e820: [mem 0x00000000b0000000-0x00000000bfffffff] reserved
-[    0.000000] NX (Execute Disable) protection: active
-[    0.000000] efi: EFI v2.70 by EDK II
-[    0.000000] efi: SMBIOS=0x7f7ab000 ACPI=0x7f97e000 ACPI 2.0=0x7f97e014 MEMATTR=0x7e9d8118
-[    0.000000] SMBIOS 2.8 present.
-[    0.000000] DMI: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
-[    0.000000] Hypervisor detected: KVM
-[    0.000000] kvm-clock: Using msrs 4b564d01 and 4b564d00
-[    0.000000] kvm-clock: cpu 0, msr 3d401001, primary cpu clock
-[    0.000000] kvm-clock: using sched offset of 4061892066 cycles
-[    0.000003] clocksource: kvm-clock: mask: 0xffffffffffffffff max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 ns
-[    0.000006] tsc: Detected 2994.372 MHz processor
-[    0.000159] e820: update [mem 0x00000000-0x00000fff] usable ==> reserved
-[    0.000162] e820: remove [mem 0x000a0000-0x000fffff] usable
-[    0.000169] last_pfn = 0x7fe60 max_arch_pfn = 0x400000000
-[    0.000215] MTRR default type: write-back
-[    0.000216] MTRR fixed ranges enabled:
-[    0.000218]   00000-9FFFF write-back
-[    0.000219]   A0000-FFFFF uncachable
-[    0.000220] MTRR variable ranges enabled:
-[    0.000222]   0 base 0000C0000000 mask FFFFC0000000 uncachable
-[    0.000224]   1 base 0000B0000000 mask FFFFF0000000 uncachable
-[    0.000225]   2 base 001000000000 mask FFF800000000 uncachable
-[    0.000226]   3 disabled
-[    0.000227]   4 disabled
-[    0.000228]   5 disabled
-[    0.000229]   6 disabled
-[    0.000229]   7 disabled
-[    0.000277] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WP  UC- WT
-[    0.008747] Using GB pages for direct mapping
-[    0.009448] Secure boot could not be determined
-[    0.009466] ACPI: Early table checksum verification disabled
-[    0.009476] ACPI: RSDP 0x000000007F97E014 000024 (v02 BOCHS )
-[    0.009482] ACPI: XSDT 0x000000007F97D0E8 000054 (v01 BOCHS  BXPC     00000001      01000013)
-[    0.009490] ACPI: FACP 0x000000007F978000 0000F4 (v03 BOCHS  BXPC     00000001 BXPC 00000001)
-[    0.009497] ACPI: DSDT 0x000000007F979000 003EAE (v01 BOCHS  BXPC     00000001 BXPC 00000001)
-[    0.009502] ACPI: FACS 0x000000007F9DD000 000040
-[    0.009506] ACPI: APIC 0x000000007F977000 000170 (v01 BOCHS  BXPC     00000001 BXPC 00000001)
-[    0.009510] ACPI: HPET 0x000000007F976000 000038 (v01 BOCHS  BXPC     00000001 BXPC 00000001)
-[    0.009515] ACPI: SRAT 0x000000007F975000 0002D0 (v01 BOCHS  BXPC     00000001 BXPC 00000001)
-[    0.009519] ACPI: MCFG 0x000000007F974000 00003C (v01 BOCHS  BXPC     00000001 BXPC 00000001)
-[    0.009523] ACPI: WAET 0x000000007F973000 000028 (v01 BOCHS  BXPC     00000001 BXPC 00000001)
-[    0.009532] ACPI: Local APIC address 0xfee00000
-[    0.009575] Zone ranges:
-[    0.009576]   DMA      [mem 0x0000000000001000-0x0000000000ffffff]
-[    0.009578]   DMA32    [mem 0x0000000001000000-0x000000007fe5ffff]
-[    0.009580]   Normal   empty
-[    0.009581]   Device   empty
-[    0.009582] Movable zone start for each node
-[    0.009583] Early memory node ranges
-[    0.009585]   node   0: [mem 0x0000000000001000-0x000000000009ffff]
-[    0.009587]   node   0: [mem 0x0000000000100000-0x00000000007fffff]
-[    0.009588]   node   0: [mem 0x0000000000808000-0x000000000080ffff]
-[    0.009589]   node   0: [mem 0x0000000000900000-0x000000007f6eefff]
-[    0.009590]   node   0: [mem 0x000000007f9ff000-0x000000007fe5ffff]
-[    0.009592] Initmem setup node 0 [mem 0x0000000000001000-0x000000007fe5ffff]
-[    0.009595] On node 0 totalpages: 522743
-[    0.009596]   DMA zone: 59 pages used for memmap
-[    0.009597]   DMA zone: 1814 pages reserved
-[    0.009599]   DMA zone: 3751 pages, LIFO batch:0
-[    0.009931]   DMA zone: 29017 pages in unavailable ranges
-[    0.009933]   DMA32 zone: 8122 pages used for memmap
-[    0.009934]   DMA32 zone: 518992 pages, LIFO batch:63
-[    0.014254]   DMA32 zone: 1200 pages in unavailable ranges
-[    0.014984] ACPI: PM-Timer IO Port: 0x608
-[    0.014988] ACPI: Local APIC address 0xfee00000
-[    0.015002] ACPI: LAPIC_NMI (acpi_id[0xff] dfl dfl lint[0x1])
-[    0.015201] IOAPIC[0]: apic_id 0, version 32, address 0xfec00000, GSI 0-23
-[    0.015205] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
-[    0.015207] ACPI: INT_SRC_OVR (bus 0 bus_irq 5 global_irq 5 high level)
-[    0.015209] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
-[    0.015210] ACPI: INT_SRC_OVR (bus 0 bus_irq 10 global_irq 10 high level)
-[    0.015212] ACPI: INT_SRC_OVR (bus 0 bus_irq 11 global_irq 11 high level)
-[    0.015213] ACPI: IRQ0 used by override.
-[    0.015214] ACPI: IRQ5 used by override.
-[    0.015216] ACPI: IRQ9 used by override.
-[    0.015217] ACPI: IRQ10 used by override.
-[    0.015217] ACPI: IRQ11 used by override.
-[    0.015220] Using ACPI (MADT) for SMP configuration information
-[    0.015223] ACPI: HPET id: 0x8086a201 base: 0xfed00000
-[    0.015228] TSC deadline timer available
-[    0.015233] smpboot: Allowing 32 CPUs, 31 hotplug CPUs
-[    0.015245] kvm-guest: KVM setup pv remote TLB flush
-[    0.015254] kvm-guest: setup PV sched yield
-[    0.015272] [mem 0xc0000000-0xffffffff] available for PCI devices
-[    0.015274] Booting paravirtualized kernel on KVM
-[    0.015278] clocksource: refined-jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645519600211568 ns
-[    0.020479] setup_percpu: NR_CPUS:240 nr_cpumask_bits:240 nr_cpu_ids:32 nr_node_ids:1
-[    0.021723] percpu: Embedded 42 pages/cpu s143360 r0 d28672 u262144
-[    0.021732] pcpu-alloc: s143360 r0 d28672 u262144 alloc=1*2097152
-[    0.021734] pcpu-alloc: [0] 00 01 02 03 04 05 06 07 [0] 08 09 10 11 12 13 14 15
-[    0.021744] pcpu-alloc: [0] 16 17 18 19 20 21 22 23 [0] 24 25 26 27 28 29 30 31
-[    0.027310] kvm-guest: KVM setup async PF for cpu 0
-[    0.027318] kvm-guest: stealtime: cpu 0, msr 7d622080
-[    0.027332] Built 1 zonelists, mobility grouping on.  Total pages: 512748
-[    0.027335] Kernel command line: tsc=reliable no_timer_check rcupdate.rcu_expedited=1 i8042.direct=1 i8042.dumbkbd=1 i8042.nopnp=1 i8042.noaux=1 noreplace-smp reboot=k console=hvc0 console=hvc1 console=ttyS0 cryptomgr.notests net.ifnames=0 pci=lastbus=0 debug panic=1 nr_cpus=32 scsi_mod.scan=none agent.log=debug
-[    0.027480] printk: log_buf_len individual max cpu contribution: 4096 bytes
-[    0.027481] printk: log_buf_len total cpu_extra contributions: 126976 bytes
-[    0.027483] printk: log_buf_len min size: 131072 bytes
-[    0.027731] printk: log_buf_len: 262144 bytes
-[    0.027733] printk: early log buf free: 123344(94%)
-[    0.027942] Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes, linear)
-[    0.028047] Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes, linear)
-[    0.028190] mem auto-init: stack:off, heap alloc:off, heap free:off
-[    0.041061] Memory: 1815804K/2090972K available (10242K kernel code, 956K rwdata, 1456K rodata, 892K init, 3564K bss, 274912K reserved, 0K cma-reserved)
-[    0.041173] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=32, Nodes=1
-[    0.041309] rcu: Hierarchical RCU implementation.
-[    0.041311] rcu: 	RCU restricting CPUs from NR_CPUS=240 to nr_cpu_ids=32.
-[    0.041312] 	All grace periods are expedited (rcu_expedited).
-[    0.041313] 	Tracing variant of Tasks RCU enabled.
-[    0.041315] rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies.
-[    0.041316] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=32
-[    0.041372] NR_IRQS: 15616, nr_irqs: 680, preallocated irqs: 16
-[    0.041910] rcu: 	Offload RCU callbacks from CPUs: (none).
-[    0.042080] random: get_random_bytes called from start_kernel+0x2fc/0x4ae with crng_init=0
-[    0.042159] Console: colour dummy device 80x25
-[    0.162231] printk: console [ttyS0] enabled
-[    0.175286] AMD Memory Encryption Features active: SEV
-[    0.176044] ACPI: Core revision 20200925
-[    0.176768] clocksource: hpet: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604467 ns
-[    0.178070] APIC: Switch to symmetric I/O mode setup
-[    0.180011] x2apic enabled
-[    0.182376] Switched APIC routing to physical x2apic.
-[    0.183044] kvm-guest: setup PV IPIs
-[    0.189694] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
-[    0.190655] clocksource: tsc-early: mask: 0xffffffffffffffff max_cycles: 0x2b29812ce43, max_idle_ns: 440795323173 ns
-[    0.191992] Calibrating delay loop (skipped) preset value.. 5988.74 BogoMIPS (lpj=11977488)
-[    0.193096] pid_max: default: 32768 minimum: 301
-[    0.224045] LSM: Security Framework initializing
-[    0.225340] Mount-cache hash table entries: 4096 (order: 3, 32768 bytes, linear)
-[    0.226368] Mountpoint-cache hash table entries: 4096 (order: 3, 32768 bytes, linear)
-[    0.227912] x86/cpu: User Mode Instruction Prevention (UMIP) activated
-[    0.228021] Last level iTLB entries: 4KB 512, 2MB 255, 4MB 127
-[    0.228758] Last level dTLB entries: 4KB 512, 2MB 255, 4MB 127, 1GB 0
-[    0.229578] Spectre V1 : Mitigation: usercopy/swapgs barriers and __user pointer sanitization
-[    0.230655] Spectre V2 : Mitigation: Full AMD retpoline
-[    0.231993] Spectre V2 : Spectre v2 / SpectreRSB mitigation: Filling RSB on context switch
-[    0.233038] Spectre V2 : Enabling Restricted Speculation for firmware calls
-[    0.234868] Spectre V2 : mitigation: Enabling conditional Indirect Branch Prediction Barrier
-[    0.235997] Speculative Store Bypass: Mitigation: Speculative Store Bypass disabled via prctl and seccomp
-[    0.237657] Freeing SMP alternatives memory: 28K
-[    0.238528] smpboot: CPU0: AMD EPYC 7302P 16-Core Processor (family: 0x17, model: 0x31, stepping: 0x0)
-[    0.239991] Performance Events: Fam17h+ core perfctr, AMD PMU driver.
-[    0.239991] ... version:                0
-[    0.239991] ... bit width:              48
-[    0.239991] ... generic registers:      6
-[    0.239997] ... value mask:             0000ffffffffffff
-[    0.240552] ... max period:             00007fffffffffff
-[    0.241107] ... fixed-purpose events:   0
-[    0.241610] ... event mask:             000000000000003f
-[    0.242405] rcu: Hierarchical SRCU implementation.
-[    0.243319] smp: Bringing up secondary CPUs ...
-[    0.243787] smp: Brought up 1 node, 1 CPU
-[    0.244000] smpboot: Max logical packages: 32
-[    0.244475] smpboot: Total of 1 processors activated (5988.74 BogoMIPS)
-[    0.245487] devtmpfs: initialized
-[    0.245852] x86/mm: Memory block size: 128MB
-[    0.246502] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
-[    0.247472] futex hash table entries: 8192 (order: 7, 524288 bytes, linear)
-[    0.248308] NET: Registered protocol family 16
-[    0.249031] DMA: preallocated 256 KiB GFP_KERNEL pool for atomic allocations
-[    0.250111] DMA: preallocated 256 KiB GFP_KERNEL|GFP_DMA pool for atomic allocations
-[    0.251331] DMA: preallocated 256 KiB GFP_KERNEL|GFP_DMA32 pool for atomic allocations
-[    0.252043] thermal_sys: Registered thermal governor 'step_wise'
-[    0.252048] cpuidle: using governor menu
-[    0.253569] ACPI: bus type PCI registered
-[    0.253974] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
-[    0.254656] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xb0000000-0xbfffffff] (base 0xb0000000)
-[    0.255546] PCI: MMCONFIG at [mem 0xb0000000-0xbfffffff] reserved in E820
-[    0.256020] PCI: Using configuration type 1 for base access
-[    0.257219] HugeTLB registered 1.00 GiB page size, pre-allocated 0 pages
-[    0.257889] HugeTLB registered 2.00 MiB page size, pre-allocated 0 pages
-[    0.258633] ACPI: Added _OSI(Module Device)
-[    0.259073] ACPI: Added _OSI(Processor Device)
-[    0.259531] ACPI: Added _OSI(3.0 _SCP Extensions)
-[    0.259999] ACPI: Added _OSI(Processor Aggregator Device)
-[    0.260534] ACPI: Added _OSI(Linux-Dell-Video)
-[    0.260979] ACPI: Added _OSI(Linux-Lenovo-NV-HDMI-Audio)
-[    0.261508] ACPI: Added _OSI(Linux-HPI-Hybrid-Graphics)
-[    0.263748] ACPI: 1 ACPI AML tables successfully acquired and loaded
-[    0.264963] ACPI: Interpreter enabled
-[    0.265375] ACPI: (supports S0 S5)
-[    0.265743] ACPI: Using IOAPIC for interrupt routing
-[    0.266290] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
-[    0.267390] ACPI: Enabled 3 GPEs in block 00 to 3F
-[    0.272364] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
-[    0.273025] acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI HPX-Type3]
-[    0.274136] acpi PNP0A08:00: _OSC: platform does not support [PCIeHotplug LTR]
-[    0.275108] acpi PNP0A08:00: _OSC: OS now controls [SHPCHotplug PME PCIeCapability]
-[    0.276009] PCI host bridge to bus 0000:00
-[    0.276413] pci_bus 0000:00: root bus resource [io  0x0000-0x0cf7 window]
-[    0.277047] pci_bus 0000:00: root bus resource [io  0x0d00-0xffff window]
-[    0.277707] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff window]
-[    0.278440] pci_bus 0000:00: root bus resource [mem 0x80000000-0xafffffff window]
-[    0.279154] pci_bus 0000:00: root bus resource [mem 0xc0000000-0xfebfffff window]
-[    0.279885] pci_bus 0000:00: root bus resource [mem 0x1000000000-0x17ffffffff window]
-[    0.279995] pci_bus 0000:00: root bus resource [bus 00-ff]
-[    0.280579] pci 0000:00:00.0: [8086:29c0] type 00 class 0x060000
-[    0.281678] pci 0000:00:01.0: [1af4:1043] type 00 class 0x078000
-[    0.283998] pci 0000:00:01.0: reg 0x14: [mem 0xc0003000-0xc0003fff]
-[    0.287128] pci 0000:00:01.0: reg 0x20: [mem 0x1000000000-0x1000003fff 64bit pref]
-[    0.288918] pci 0000:00:02.0: [1b36:0001] type 01 class 0x060400
-[    0.294626] pci 0000:00:03.0: [1af4:1048] type 00 class 0x010000
-[    0.296349] pci 0000:00:03.0: reg 0x14: [mem 0xc0002000-0xc0002fff]
-[    0.299044] pci 0000:00:03.0: reg 0x20: [mem 0x1000004000-0x1000007fff 64bit pref]
-[    0.300892] pci 0000:00:04.0: [1af4:1044] type 00 class 0x00ff00
-[    0.303526] pci 0000:00:04.0: reg 0x20: [mem 0x1000008000-0x100000bfff 64bit pref]
-[    0.304902] pci 0000:00:05.0: [1af4:1049] type 00 class 0x000200
-[    0.306875] pci 0000:00:05.0: reg 0x14: [mem 0xc0001000-0xc0001fff]
-[    0.309436] pci 0000:00:05.0: reg 0x20: [mem 0x100000c000-0x100000ffff 64bit pref]
-[    0.311525] pci 0000:00:1f.0: [8086:2918] type 00 class 0x060100
-[    0.312373] pci 0000:00:1f.0: quirk: [io  0x0600-0x067f] claimed by ICH6 ACPI/GPIO/TCO
-[    0.314653] pci 0000:00:1f.2: [8086:2922] type 00 class 0x010601
-[    0.318160] pci 0000:00:1f.2: reg 0x20: [io  0x6040-0x605f]
-[    0.319336] pci 0000:00:1f.2: reg 0x24: [mem 0xc0000000-0xc0000fff]
-[    0.320607] pci 0000:00:1f.3: [8086:2930] type 00 class 0x0c0500
-[    0.323429] pci 0000:00:1f.3: reg 0x20: [io  0x6000-0x603f]
-[    0.325167] pci_bus 0000:01: extended config space not accessible
-[    0.325943] acpiphp: Slot [0] registered
-[    0.326344] acpiphp: Slot [1] registered
-[    0.326753] acpiphp: Slot [2] registered
-[    0.327153] acpiphp: Slot [3] registered
-[    0.327557] acpiphp: Slot [4] registered
-[    0.327962] acpiphp: Slot [5] registered
-[    0.328009] acpiphp: Slot [6] registered
-[    0.328416] acpiphp: Slot [7] registered
-[    0.328817] acpiphp: Slot [8] registered
-[    0.329218] acpiphp: Slot [9] registered
-[    0.329625] acpiphp: Slot [10] registered
-[    0.330033] acpiphp: Slot [11] registered
-[    0.330448] acpiphp: Slot [12] registered
-[    0.330854] acpiphp: Slot [13] registered
-[    0.331261] acpiphp: Slot [14] registered
-[    0.331675] acpiphp: Slot [15] registered
-[    0.332008] acpiphp: Slot [16] registered
-[    0.332419] acpiphp: Slot [17] registered
-[    0.332827] acpiphp: Slot [18] registered
-[    0.333234] acpiphp: Slot [19] registered
-[    0.333647] acpiphp: Slot [20] registered
-[    0.334055] acpiphp: Slot [21] registered
-[    0.334468] acpiphp: Slot [22] registered
-[    0.334886] acpiphp: Slot [23] registered
-[    0.335298] acpiphp: Slot [24] registered
-[    0.335702] acpiphp: Slot [25] registered
-[    0.336008] acpiphp: Slot [26] registered
-[    0.336420] acpiphp: Slot [27] registered
-[    0.336824] acpiphp: Slot [28] registered
-[    0.337232] acpiphp: Slot [29] registered
-[    0.337636] acpiphp: Slot [30] registered
-[    0.338041] acpiphp: Slot [31] registered
-[    0.338650] pci 0000:00:02.0: PCI bridge to [bus 01]
-[    0.339776] pci_bus 0000:00: on NUMA node 0
-[    0.340242] ACPI: PCI Interrupt Link [LNKA] (IRQs 5 *10 11)
-[    0.340849] ACPI: PCI Interrupt Link [LNKB] (IRQs 5 *10 11)
-[    0.341462] ACPI: PCI Interrupt Link [LNKC] (IRQs 5 10 *11)
-[    0.342076] ACPI: PCI Interrupt Link [LNKD] (IRQs 5 10 *11)
-[    0.342685] ACPI: PCI Interrupt Link [LNKE] (IRQs 5 *10 11)
-[    0.343300] ACPI: PCI Interrupt Link [LNKF] (IRQs 5 *10 11)
-[    0.343918] ACPI: PCI Interrupt Link [LNKG] (IRQs 5 10 *11)
-[    0.344059] ACPI: PCI Interrupt Link [LNKH] (IRQs 5 10 *11)
-[    0.344636] ACPI: PCI Interrupt Link [GSIA] (IRQs *16)
-[    0.345142] ACPI: PCI Interrupt Link [GSIB] (IRQs *17)
-[    0.345660] ACPI: PCI Interrupt Link [GSIC] (IRQs *18)
-[    0.346245] ACPI: PCI Interrupt Link [GSID] (IRQs *19)
-[    0.346799] ACPI: PCI Interrupt Link [GSIE] (IRQs *20)
-[    0.347365] ACPI: PCI Interrupt Link [GSIF] (IRQs *21)
-[    0.347889] ACPI: PCI Interrupt Link [GSIG] (IRQs *22)
-[    0.348004] ACPI: PCI Interrupt Link [GSIH] (IRQs *23)
-[    0.349647] iommu: Default domain type: Translated
-[    0.350207] vgaarb: loaded
-[    0.350578] SCSI subsystem initialized
-[    0.350959] pps_core: LinuxPPS API ver. 1 registered
-[    0.351500] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
-[    0.352007] PTP clock support registered
-[    0.352415] Registered efivars operations
-[    0.352914] PCI: Using ACPI for IRQ routing
-[    0.353321] PCI: pci_cache_line_size set to 64 bytes
-[    0.353916] e820: reserve RAM buffer [mem 0x00810000-0x008fffff]
-[    0.354487] e820: reserve RAM buffer [mem 0x7f6ef000-0x7fffffff]
-[    0.355053] e820: reserve RAM buffer [mem 0x7fe60000-0x7fffffff]
-[    0.355719] clocksource: Switched to clocksource kvm-clock
-[    0.355991] pnp: PnP ACPI init
-[    0.355991] pnp 00:00: Plug and Play ACPI device, IDs PNP0303 (active)
-[    0.355991] pnp 00:01: Plug and Play ACPI device, IDs PNP0f13 (active)
-[    0.355991] pnp 00:02: Plug and Play ACPI device, IDs PNP0501 (active)
-[    0.355991] pnp 00:03: Plug and Play ACPI device, IDs PNP0b00 (active)
-[    0.355991] system 00:04: [mem 0xb0000000-0xbfffffff window] has been reserved
-[    0.356347] system 00:04: Plug and Play ACPI device, IDs PNP0c01 (active)
-[    0.357410] pnp: PnP ACPI: found 5 devices
-[    0.362961] clocksource: acpi_pm: mask: 0xffffff max_cycles: 0xffffff, max_idle_ns: 2085701024 ns
-[    0.363871] NET: Registered protocol family 2
-[    0.364474] tcp_listen_portaddr_hash hash table entries: 1024 (order: 2, 16384 bytes, linear)
-[    0.365307] TCP established hash table entries: 16384 (order: 5, 131072 bytes, linear)
-[    0.366095] TCP bind hash table entries: 16384 (order: 6, 262144 bytes, linear)
-[    0.366893] TCP: Hash tables configured (established 16384 bind 16384)
-[    0.367563] UDP hash table entries: 1024 (order: 3, 32768 bytes, linear)
-[    0.368255] UDP-Lite hash table entries: 1024 (order: 3, 32768 bytes, linear)
-[    0.369036] NET: Registered protocol family 1
-[    0.369533] pci 0000:00:02.0: PCI bridge to [bus 01]
-[    0.371860] pci_bus 0000:00: resource 4 [io  0x0000-0x0cf7 window]
-[    0.372477] pci_bus 0000:00: resource 5 [io  0x0d00-0xffff window]
-[    0.373092] pci_bus 0000:00: resource 6 [mem 0x000a0000-0x000bffff window]
-[    0.373765] pci_bus 0000:00: resource 7 [mem 0x80000000-0xafffffff window]
-[    0.374428] pci_bus 0000:00: resource 8 [mem 0xc0000000-0xfebfffff window]
-[    0.375109] pci_bus 0000:00: resource 9 [mem 0x1000000000-0x17ffffffff window]
-[    0.375904] PCI: CLS 0 bytes, default 64
-[    0.376370] PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
-[    0.377008] software IO TLB: mapped [mem 0x000000006f600000-0x0000000073600000] (64MB)
-[    0.377807] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x2b29812ce43, max_idle_ns: 440795323173 ns
-[    0.379980] workingset: timestamp_bits=46 max_order=19 bucket_order=0
-[    0.381847] fuse: init (API version 7.32)
-[    0.382462] SGI XFS with security attributes, no debug enabled
-[    0.383337] 9p: Installing v9fs 9p2000 file system support
-[    0.383950] NET: Registered protocol family 38
-[    0.384407] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 249)
-[    0.385291] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4
-[    0.386003] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input0
-[    0.386731] ACPI: Power Button [PWRF]
-[    0.387428] PCI Interrupt Link [GSIF] enabled at IRQ 21
-[    0.388885] PCI Interrupt Link [GSIH] enabled at IRQ 23
-[    0.390255] PCI Interrupt Link [GSIE] enabled at IRQ 20
-[    0.393749] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
-[    0.394570] 00:02: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A
-[    0.409740] software IO TLB: Memory encryption is active and system is using DMA bounce buffers
-[    0.411320] printk: console [hvc0] enabled
-[    0.413415] brd: module loaded
-[    0.414644] loop: module loaded
-[    0.416081] scsi host0: Virtio SCSI HBA
-[    0.417023] random: fast init done
-[    0.417469] VFIO - User Level meta-driver version: 0.3
-[    0.418175] random: crng init done
-[    0.418975] xt_time: kernel timezone is -0000
-[    0.419488] IPVS: Registered protocols (TCP, UDP, SCTP, AH, ESP)
-[    0.420221] IPVS: Connection hash table configured (size=4096, memory=64Kbytes)
-[    0.421119] IPVS: ipvs loaded.
-[    0.421478] IPVS: [rr] scheduler registered.
-[    0.421979] IPVS: [wrr] scheduler registered.
-[    0.422475] IPVS: [lc] scheduler registered.
-[    0.422970] IPVS: [wlc] scheduler registered.
-[    0.423461] IPVS: [fo] scheduler registered.
-[    0.423982] IPVS: [ovf] scheduler registered.
-[    0.424546] IPVS: [lblc] scheduler registered.
-[    0.425067] IPVS: [lblcr] scheduler registered.
-[    0.425580] IPVS: [dh] scheduler registered.
-[    0.426081] IPVS: [sh] scheduler registered.
-[    0.426572] IPVS: [sed] scheduler registered.
-[    0.427084] IPVS: [nq] scheduler registered.
-[    0.427578] IPVS: ftp: loaded support on port[0] = 21
-[    0.428167] IPVS: [sip] pe registered.
-[    0.428794] ipt_CLUSTERIP: ClusterIP Version 0.8 loaded successfully
-[    0.429549] Initializing XFRM netlink socket
-[    0.430136] NET: Registered protocol family 10
-[    0.430960] Segment Routing with IPv6
-[    0.431417] NET: Registered protocol family 17
-[    0.431971] 9pnet: Installing 9P2000 support
-[    0.433142] NET: Registered protocol family 40
-[    0.433718] IPI shorthand broadcast: enabled
-[    0.434218] sched_clock: Marking stable (290414430, 142054672)->(447457221, -14988119)
-[    0.435600] VFS: Cannot open root device "(null)" or unknown-block(0,0): error -6
-[    0.436567] Please append a correct "root=" boot option; here are the available partitions:
-[    0.437750] 0100            4096 ram0
-[    0.437750]  (driver?)
-[    0.438478] 0101            4096 ram1
-[    0.438478]  (driver?)
-[    0.439182] 0102            4096 ram2
-[    0.439183]  (driver?)
-[    0.439896] 0103            4096 ram3
-[    0.439897]  (driver?)
-[    0.440629] 0104            4096 ram4
-[    0.440630]  (driver?)
-[    0.441346] 0105            4096 ram5
-[    0.441346]  (driver?)
-[    0.442052] 0106            4096 ram6
-[    0.442053]  (driver?)
-[    0.442756] 0107            4096 ram7
-[    0.442756]  (driver?)
-[    0.443457] 0108            4096 ram8
-[    0.443457]  (driver?)
-[    0.444177] 0109            4096 ram9
-[    0.444177]  (driver?)
-[    0.444893] 010a            4096 ram10
-[    0.444893]  (driver?)
-[    0.445609] 010b            4096 ram11
-[    0.445610]  (driver?)
-[    0.446339] 010c            4096 ram12
-[    0.446340]  (driver?)
-[    0.447056] 010d            4096 ram13
-[    0.447057]  (driver?)
-[    0.447781] 010e            4096 ram14
-[    0.447781]  (driver?)
-[    0.448512] 010f            4096 ram15
-[    0.448513]  (driver?)
-[    0.449263] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
-[    0.450170] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.10.25 #1
-[    0.450848] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
-[    0.451699] Call Trace:
-[    0.451995]  dump_stack+0x57/0x6a
-[    0.452378]  panic+0xf6/0x292
-[    0.452745]  mount_block_root+0x2aa/0x324
-[    0.453197]  ? rest_init+0xaa/0xaa
-[    0.453587]  prepare_namespace+0x131/0x160
-[    0.454053]  ? rest_init+0xaa/0xaa
-[    0.454442]  kernel_init+0x5/0xf6
-[    0.454838]  ret_from_fork+0x22/0x30
-[    0.455282] Kernel Offset: disabled
-[    0.455676] Rebooting in 1 seconds..
-```
-
-Complete output from QEMU 6.2.0 without SEV :  
-```
-[    0.000000] Linux version 5.10.25 (gitlab-runner@runner-buildah0) (gcc (Debian 11.2.0-12) 11.2.0, GNU ld (GNU Binutils for Debian) 2.37) #1 SMP Tue Dec 7 11:43:22 CET 2021
-[    0.000000] Command line: tsc=reliable no_timer_check rcupdate.rcu_expedited=1 i8042.direct=1 i8042.dumbkbd=1 i8042.nopnp=1 i8042.noaux=1 noreplace-smp reboot=k console=hvc0 console=hvc1 console=ttyS0 cryptomgr.notests net.ifnames=0 pci=lastbus=0 debug panic=1 nr_cpus=32 scsi_mod.scan=none agent.log=debug
-[    0.000000] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
-[    0.000000] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
-[    0.000000] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
-[    0.000000] x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
-[    0.000000] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'compacted' format.
-[    0.000000] BIOS-provided physical RAM map:
-[    0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009ffff] usable
-[    0.000000] BIOS-e820: [mem 0x0000000000100000-0x00000000007fffff] usable
-[    0.000000] BIOS-e820: [mem 0x0000000000800000-0x0000000000807fff] ACPI NVS
-[    0.000000] BIOS-e820: [mem 0x0000000000808000-0x000000000080ffff] usable
-[    0.000000] BIOS-e820: [mem 0x0000000000810000-0x00000000008fffff] ACPI NVS
-[    0.000000] BIOS-e820: [mem 0x0000000000900000-0x000000007f6eefff] usable
-[    0.000000] BIOS-e820: [mem 0x000000007f6ef000-0x000000007f96efff] reserved
-[    0.000000] BIOS-e820: [mem 0x000000007f96f000-0x000000007f97efff] ACPI data
-[    0.000000] BIOS-e820: [mem 0x000000007f97f000-0x000000007f9fefff] ACPI NVS
-[    0.000000] BIOS-e820: [mem 0x000000007f9ff000-0x000000007fe5ffff] usable
-[    0.000000] BIOS-e820: [mem 0x000000007fe60000-0x000000007fe7ffff] reserved
-[    0.000000] BIOS-e820: [mem 0x000000007fe80000-0x000000007fffffff] ACPI NVS
-[    0.000000] BIOS-e820: [mem 0x00000000b0000000-0x00000000bfffffff] reserved
-[    0.000000] NX (Execute Disable) protection: active
-[    0.000000] efi: EFI v2.70 by EDK II
-[    0.000000] efi: SMBIOS=0x7f7ab000 ACPI=0x7f97e000 ACPI 2.0=0x7f97e014 MEMATTR=0x7e687118
-[    0.000000] SMBIOS 2.8 present.
-[    0.000000] DMI: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
-[    0.000000] Hypervisor detected: KVM
-[    0.000000] kvm-clock: Using msrs 4b564d01 and 4b564d00
-[    0.000000] kvm-clock: cpu 0, msr 37201001, primary cpu clock
-[    0.000000] kvm-clock: using sched offset of 2589542167 cycles
-[    0.000002] clocksource: kvm-clock: mask: 0xffffffffffffffff max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 ns
-[    0.000004] tsc: Detected 2994.372 MHz processor
-[    0.000078] e820: update [mem 0x00000000-0x00000fff] usable ==> reserved
-[    0.000081] e820: remove [mem 0x000a0000-0x000fffff] usable
-[    0.000084] last_pfn = 0x7fe60 max_arch_pfn = 0x400000000
-[    0.000106] MTRR default type: write-back
-[    0.000107] MTRR fixed ranges enabled:
-[    0.000108]   00000-9FFFF write-back
-[    0.000109]   A0000-FFFFF uncachable
-[    0.000110] MTRR variable ranges enabled:
-[    0.000111]   0 base 0000C0000000 mask FFFFC0000000 uncachable
-[    0.000111]   1 base 0000B0000000 mask FFFFF0000000 uncachable
-[    0.000112]   2 base 001000000000 mask FFF800000000 uncachable
-[    0.000113]   3 disabled
-[    0.000113]   4 disabled
-[    0.000114]   5 disabled
-[    0.000114]   6 disabled
-[    0.000114]   7 disabled
-[    0.000141] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WP  UC- WT
-[    0.004269] Using GB pages for direct mapping
-[    0.004654] Secure boot could not be determined
-[    0.004655] RAMDISK: [mem 0x6f1ee000-0x757f5fff]
-[    0.004668] ACPI: Early table checksum verification disabled
-[    0.004673] ACPI: RSDP 0x000000007F97E014 000024 (v02 BOCHS )
-[    0.004676] ACPI: XSDT 0x000000007F97D0E8 000054 (v01 BOCHS  BXPC     00000001      01000013)
-[    0.004682] ACPI: FACP 0x000000007F978000 0000F4 (v03 BOCHS  BXPC     00000001 BXPC 00000001)
-[    0.004686] ACPI: DSDT 0x000000007F979000 003EAE (v01 BOCHS  BXPC     00000001 BXPC 00000001)
-[    0.004688] ACPI: FACS 0x000000007F9DD000 000040
-[    0.004690] ACPI: APIC 0x000000007F977000 000170 (v01 BOCHS  BXPC     00000001 BXPC 00000001)
-[    0.004692] ACPI: HPET 0x000000007F976000 000038 (v01 BOCHS  BXPC     00000001 BXPC 00000001)
-[    0.004694] ACPI: SRAT 0x000000007F975000 0002D0 (v01 BOCHS  BXPC     00000001 BXPC 00000001)
-[    0.004696] ACPI: MCFG 0x000000007F974000 00003C (v01 BOCHS  BXPC     00000001 BXPC 00000001)
-[    0.004698] ACPI: WAET 0x000000007F973000 000028 (v01 BOCHS  BXPC     00000001 BXPC 00000001)
-[    0.004703] ACPI: Local APIC address 0xfee00000
-[    0.004734] Zone ranges:
-[    0.004735]   DMA      [mem 0x0000000000001000-0x0000000000ffffff]
-[    0.004736]   DMA32    [mem 0x0000000001000000-0x000000007fe5ffff]
-[    0.004737]   Normal   empty
-[    0.004738]   Device   empty
-[    0.004739] Movable zone start for each node
-[    0.004740] Early memory node ranges
-[    0.004741]   node   0: [mem 0x0000000000001000-0x000000000009ffff]
-[    0.004742]   node   0: [mem 0x0000000000100000-0x00000000007fffff]
-[    0.004743]   node   0: [mem 0x0000000000808000-0x000000000080ffff]
-[    0.004743]   node   0: [mem 0x0000000000900000-0x000000007f6eefff]
-[    0.004744]   node   0: [mem 0x000000007f9ff000-0x000000007fe5ffff]
-[    0.004746] Initmem setup node 0 [mem 0x0000000000001000-0x000000007fe5ffff]
-[    0.004747] On node 0 totalpages: 522743
-[    0.004748]   DMA zone: 59 pages used for memmap
-[    0.004749]   DMA zone: 1814 pages reserved
-[    0.004750]   DMA zone: 3751 pages, LIFO batch:0
-[    0.005315]   DMA zone: 29017 pages in unavailable ranges
-[    0.005316]   DMA32 zone: 8122 pages used for memmap
-[    0.005317]   DMA32 zone: 518992 pages, LIFO batch:63
-[    0.011640]   DMA32 zone: 1200 pages in unavailable ranges
-[    0.012025] ACPI: PM-Timer IO Port: 0x608
-[    0.012028] ACPI: Local APIC address 0xfee00000
-[    0.012037] ACPI: LAPIC_NMI (acpi_id[0xff] dfl dfl lint[0x1])
-[    0.012063] IOAPIC[0]: apic_id 0, version 17, address 0xfec00000, GSI 0-23
-[    0.012065] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
-[    0.012067] ACPI: INT_SRC_OVR (bus 0 bus_irq 5 global_irq 5 high level)
-[    0.012068] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
-[    0.012069] ACPI: INT_SRC_OVR (bus 0 bus_irq 10 global_irq 10 high level)
-[    0.012070] ACPI: INT_SRC_OVR (bus 0 bus_irq 11 global_irq 11 high level)
-[    0.012071] ACPI: IRQ0 used by override.
-[    0.012072] ACPI: IRQ5 used by override.
-[    0.012073] ACPI: IRQ9 used by override.
-[    0.012073] ACPI: IRQ10 used by override.
-[    0.012074] ACPI: IRQ11 used by override.
-[    0.012076] Using ACPI (MADT) for SMP configuration information
-[    0.012077] ACPI: HPET id: 0x8086a201 base: 0xfed00000
-[    0.012082] TSC deadline timer available
-[    0.012085] smpboot: Allowing 32 CPUs, 31 hotplug CPUs
-[    0.012093] kvm-guest: KVM setup pv remote TLB flush
-[    0.012099] kvm-guest: setup PV sched yield
-[    0.012110] [mem 0xc0000000-0xffffffff] available for PCI devices
-[    0.012116] Booting paravirtualized kernel on KVM
-[    0.012119] clocksource: refined-jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645519600211568 ns
-[    0.015048] setup_percpu: NR_CPUS:240 nr_cpumask_bits:240 nr_cpu_ids:32 nr_node_ids:1
-[    0.016599] percpu: Embedded 42 pages/cpu s143360 r0 d28672 u262144
-[    0.016605] pcpu-alloc: s143360 r0 d28672 u262144 alloc=1*2097152
-[    0.016606] pcpu-alloc: [0] 00 01 02 03 04 05 06 07 [0] 08 09 10 11 12 13 14 15
-[    0.016611] pcpu-alloc: [0] 16 17 18 19 20 21 22 23 [0] 24 25 26 27 28 29 30 31
-[    0.016637] kvm-guest: KVM setup async PF for cpu 0
-[    0.016641] kvm-guest: stealtime: cpu 0, msr 6e822080
-[    0.016645] Built 1 zonelists, mobility grouping on.  Total pages: 512748
-[    0.016646] Kernel command line: tsc=reliable no_timer_check rcupdate.rcu_expedited=1 i8042.direct=1 i8042.dumbkbd=1 i8042.nopnp=1 i8042.noaux=1 noreplace-smp reboot=k console=hvc0 console=hvc1 console=ttyS0 cryptomgr.notests net.ifnames=0 pci=lastbus=0 debug panic=1 nr_cpus=32 scsi_mod.scan=none agent.log=debug
-[    0.016721] printk: log_buf_len individual max cpu contribution: 4096 bytes
-[    0.016722] printk: log_buf_len total cpu_extra contributions: 126976 bytes
-[    0.016723] printk: log_buf_len min size: 131072 bytes
-[    0.016904] printk: log_buf_len: 262144 bytes
-[    0.016905] printk: early log buf free: 123296(94%)
-[    0.017240] Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes, linear)
-[    0.017535] Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes, linear)
-[    0.017618] mem auto-init: stack:off, heap alloc:off, heap free:off
-[    0.021841] Memory: 1782444K/2090972K available (10242K kernel code, 956K rwdata, 1456K rodata, 892K init, 3564K bss, 308272K reserved, 0K cma-reserved)
-[    0.021920] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=32, Nodes=1
-[    0.022033] rcu: Hierarchical RCU implementation.
-[    0.022034] rcu: 	RCU restricting CPUs from NR_CPUS=240 to nr_cpu_ids=32.
-[    0.022035] 	All grace periods are expedited (rcu_expedited).
-[    0.022036] 	Tracing variant of Tasks RCU enabled.
-[    0.022037] rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies.
-[    0.022038] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=32
-[    0.022058] NR_IRQS: 15616, nr_irqs: 680, preallocated irqs: 16
-[    0.022381] rcu: 	Offload RCU callbacks from CPUs: (none).
-[    0.022525] random: get_random_bytes called from start_kernel+0x2fc/0x4ae with crng_init=0
-[    0.022585] Console: colour dummy device 80x25
-[    0.103996] printk: console [ttyS0] enabled
-[    0.104387] ACPI: Core revision 20200925
-[    0.104866] clocksource: hpet: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604467 ns
-[    0.105761] APIC: Switch to symmetric I/O mode setup
-[    0.106341] x2apic enabled
-[    0.106708] Switched APIC routing to physical x2apic.
-[    0.107178] kvm-guest: setup PV IPIs
-[    0.108191] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
-[    0.108739] clocksource: tsc-early: mask: 0xffffffffffffffff max_cycles: 0x2b29812ce43, max_idle_ns: 440795323173 ns
-[    0.109650] Calibrating delay loop (skipped) preset value.. 5988.74 BogoMIPS (lpj=11977488)
-[    0.113651] pid_max: default: 32768 minimum: 301
-[    0.129407] LSM: Security Framework initializing
-[    0.129680] Mount-cache hash table entries: 4096 (order: 3, 32768 bytes, linear)
-[    0.130330] Mountpoint-cache hash table entries: 4096 (order: 3, 32768 bytes, linear)
-[    0.131738] x86/cpu: User Mode Instruction Prevention (UMIP) activated
-[    0.132339] Last level iTLB entries: 4KB 512, 2MB 255, 4MB 127
-[    0.132849] Last level dTLB entries: 4KB 512, 2MB 255, 4MB 127, 1GB 0
-[    0.133655] Spectre V1 : Mitigation: usercopy/swapgs barriers and __user pointer sanitization
-[    0.134398] Spectre V2 : Mitigation: Full AMD retpoline
-[    0.134857] Spectre V2 : Spectre v2 / SpectreRSB mitigation: Filling RSB on context switch
-[    0.135570] Spectre V2 : Enabling Restricted Speculation for firmware calls
-[    0.136182] Spectre V2 : mitigation: Enabling conditional Indirect Branch Prediction Barrier
-[    0.136913] Speculative Store Bypass: Mitigation: Speculative Store Bypass disabled via prctl and seccomp
-[    0.137807] Freeing SMP alternatives memory: 28K
-[    0.138326] smpboot: CPU0: AMD EPYC 7302P 16-Core Processor (family: 0x17, model: 0x31, stepping: 0x0)
-[    0.141129] Performance Events: Fam17h+ core perfctr, AMD PMU driver.
-[    0.141649] ... version:                0
-[    0.141657] ... bit width:              48
-[    0.142342] ... generic registers:      6
-[    0.143012] ... value mask:             0000ffffffffffff
-[    0.143904] ... max period:             00007fffffffffff
-[    0.144790] ... fixed-purpose events:   0
-[    0.145529] ... event mask:             000000000000003f
-[    0.145867] rcu: Hierarchical SRCU implementation.
-[    0.147346] smp: Bringing up secondary CPUs ...
-[    0.148411] smp: Brought up 1 node, 1 CPU
-[    0.149351] smpboot: Max logical packages: 32
-[    0.149660] smpboot: Total of 1 processors activated (5988.74 BogoMIPS)
-[    0.151208] devtmpfs: initialized
-[    0.151830] x86/mm: Memory block size: 128MB
-[    0.152836] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
-[    0.153662] futex hash table entries: 8192 (order: 7, 524288 bytes, linear)
-[    0.155199] NET: Registered protocol family 16
-[    0.156041] DMA: preallocated 256 KiB GFP_KERNEL pool for atomic allocations
-[    0.157242] DMA: preallocated 256 KiB GFP_KERNEL|GFP_DMA pool for atomic allocations
-[    0.157661] DMA: preallocated 256 KiB GFP_KERNEL|GFP_DMA32 pool for atomic allocations
-[    0.159023] thermal_sys: Registered thermal governor 'step_wise'
-[    0.159027] cpuidle: using governor menu
-[    0.161335] ACPI: bus type PCI registered
-[    0.161655] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
-[    0.162805] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xb0000000-0xbfffffff] (base 0xb0000000)
-[    0.164441] PCI: MMCONFIG at [mem 0xb0000000-0xbfffffff] reserved in E820
-[    0.165592] PCI: Using configuration type 1 for base access
-[    0.166553] HugeTLB registered 1.00 GiB page size, pre-allocated 0 pages
-[    0.167679] HugeTLB registered 2.00 MiB page size, pre-allocated 0 pages
-[    0.169123] ACPI: Added _OSI(Module Device)
-[    0.169657] ACPI: Added _OSI(Processor Device)
-[    0.170402] ACPI: Added _OSI(3.0 _SCP Extensions)
-[    0.171180] ACPI: Added _OSI(Processor Aggregator Device)
-[    0.172120] ACPI: Added _OSI(Linux-Dell-Video)
-[    0.172866] ACPI: Added _OSI(Linux-Lenovo-NV-HDMI-Audio)
-[    0.173655] ACPI: Added _OSI(Linux-HPI-Hybrid-Graphics)
-[    0.176672] ACPI: 1 ACPI AML tables successfully acquired and loaded
-[    0.178693] ACPI: Interpreter enabled
-[    0.179358] ACPI: (supports S0 S5)
-[    0.179937] ACPI: Using IOAPIC for interrupt routing
-[    0.180969] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
-[    0.181842] ACPI: Enabled 3 GPEs in block 00 to 3F
-[    0.188692] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
-[    0.189662] acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI HPX-Type3]
-[    0.191262] acpi PNP0A08:00: _OSC: platform does not support [PCIeHotplug LTR]
-[    0.192546] acpi PNP0A08:00: _OSC: OS now controls [SHPCHotplug PME PCIeCapability]
-[    0.193820] PCI host bridge to bus 0000:00
-[    0.194509] pci_bus 0000:00: root bus resource [io  0x0000-0x0cf7 window]
-[    0.195642] pci_bus 0000:00: root bus resource [io  0x0d00-0xffff window]
-[    0.196770] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff window]
-[    0.197654] pci_bus 0000:00: root bus resource [mem 0x80000000-0xafffffff window]
-[    0.198902] pci_bus 0000:00: root bus resource [mem 0xc0000000-0xfebfffff window]
-[    0.200182] pci_bus 0000:00: root bus resource [mem 0x1000000000-0x17ffffffff window]
-[    0.201533] pci_bus 0000:00: root bus resource [bus 00-ff]
-[    0.201712] pci 0000:00:00.0: [8086:29c0] type 00 class 0x060000
-[    0.203324] pci 0000:00:01.0: [1af4:1003] type 00 class 0x078000
-[    0.205657] pci 0000:00:01.0: reg 0x10: [io  0x60c0-0x60ff]
-[    0.208353] pci 0000:00:01.0: reg 0x14: [mem 0xc0003000-0xc0003fff]
-[    0.213657] pci 0000:00:01.0: reg 0x20: [mem 0x1000000000-0x1000003fff 64bit pref]
-[    0.218281] pci 0000:00:02.0: [1b36:0001] type 01 class 0x060400
-[    0.223034] pci 0000:00:03.0: [1af4:1004] type 00 class 0x010000
-[    0.225394] pci 0000:00:03.0: reg 0x10: [io  0x6080-0x60bf]
-[    0.226822] pci 0000:00:03.0: reg 0x14: [mem 0xc0002000-0xc0002fff]
-[    0.230911] pci 0000:00:03.0: reg 0x20: [mem 0x1000004000-0x1000007fff 64bit pref]
-[    0.235919] pci 0000:00:04.0: [1af4:1005] type 00 class 0x00ff00
-[    0.237656] pci 0000:00:04.0: reg 0x10: [io  0x6120-0x613f]
-[    0.241656] pci 0000:00:04.0: reg 0x20: [mem 0x1000008000-0x100000bfff 64bit pref]
-[    0.244288] pci 0000:00:05.0: [1af4:1009] type 00 class 0x000200
-[    0.247672] pci 0000:00:05.0: reg 0x10: [io  0x6040-0x607f]
-[    0.249624] pci 0000:00:05.0: reg 0x14: [mem 0xc0001000-0xc0001fff]
-[    0.252855] pci 0000:00:05.0: reg 0x20: [mem 0x100000c000-0x100000ffff 64bit pref]
-[    0.257540] pci 0000:00:1f.0: [8086:2918] type 00 class 0x060100
-[    0.258154] pci 0000:00:1f.0: quirk: [io  0x0600-0x067f] claimed by ICH6 ACPI/GPIO/TCO
-[    0.259985] pci 0000:00:1f.2: [8086:2922] type 00 class 0x010601
-[    0.264875] pci 0000:00:1f.2: reg 0x20: [io  0x6100-0x611f]
-[    0.267416] pci 0000:00:1f.2: reg 0x24: [mem 0xc0000000-0xc0000fff]
-[    0.269582] pci 0000:00:1f.3: [8086:2930] type 00 class 0x0c0500
-[    0.271746] pci 0000:00:1f.3: reg 0x20: [io  0x6000-0x603f]
-[    0.274063] pci_bus 0000:01: extended config space not accessible
-[    0.275352] acpiphp: Slot [0] registered
-[    0.276038] acpiphp: Slot [1] registered
-[    0.277675] acpiphp: Slot [2] registered
-[    0.278353] acpiphp: Slot [3] registered
-[    0.279150] acpiphp: Slot [4] registered
-[    0.279837] acpiphp: Slot [5] registered
-[    0.280509] acpiphp: Slot [6] registered
-[    0.281280] acpiphp: Slot [7] registered
-[    0.281677] acpiphp: Slot [8] registered
-[    0.282360] acpiphp: Slot [9] registered
-[    0.283032] acpiphp: Slot [10] registered
-[    0.283814] acpiphp: Slot [11] registered
-[    0.284510] acpiphp: Slot [12] registered
-[    0.285203] acpiphp: Slot [13] registered
-[    0.285678] acpiphp: Slot [14] registered
-[    0.286378] acpiphp: Slot [15] registered
-[    0.287111] acpiphp: Slot [16] registered
-[    0.288055] acpiphp: Slot [17] registered
-[    0.288803] acpiphp: Slot [18] registered
-[    0.289541] acpiphp: Slot [19] registered
-[    0.289674] acpiphp: Slot [20] registered
-[    0.290384] acpiphp: Slot [21] registered
-[    0.291086] acpiphp: Slot [22] registered
-[    0.291778] acpiphp: Slot [23] registered
-[    0.292480] acpiphp: Slot [24] registered
-[    0.293211] acpiphp: Slot [25] registered
-[    0.293674] acpiphp: Slot [26] registered
-[    0.294385] acpiphp: Slot [27] registered
-[    0.295071] acpiphp: Slot [28] registered
-[    0.295953] acpiphp: Slot [29] registered
-[    0.296769] acpiphp: Slot [30] registered
-[    0.297594] acpiphp: Slot [31] registered
-[    0.297916] pci 0000:00:02.0: PCI bridge to [bus 01]
-[    0.300138] pci_bus 0000:00: on NUMA node 0
-[    0.301275] ACPI: PCI Interrupt Link [LNKA] (IRQs 5 *10 11)
-[    0.301748] ACPI: PCI Interrupt Link [LNKB] (IRQs 5 *10 11)
-[    0.302965] ACPI: PCI Interrupt Link [LNKC] (IRQs 5 10 *11)
-[    0.304172] ACPI: PCI Interrupt Link [LNKD] (IRQs 5 10 *11)
-[    0.305263] ACPI: PCI Interrupt Link [LNKE] (IRQs 5 *10 11)
-[    0.305787] ACPI: PCI Interrupt Link [LNKF] (IRQs 5 *10 11)
-[    0.306849] ACPI: PCI Interrupt Link [LNKG] (IRQs 5 10 *11)
-[    0.308110] ACPI: PCI Interrupt Link [LNKH] (IRQs 5 10 *11)
-[    0.309202] ACPI: PCI Interrupt Link [GSIA] (IRQs *16)
-[    0.309667] ACPI: PCI Interrupt Link [GSIB] (IRQs *17)
-[    0.310565] ACPI: PCI Interrupt Link [GSIC] (IRQs *18)
-[    0.311446] ACPI: PCI Interrupt Link [GSID] (IRQs *19)
-[    0.312329] ACPI: PCI Interrupt Link [GSIE] (IRQs *20)
-[    0.313253] ACPI: PCI Interrupt Link [GSIF] (IRQs *21)
-[    0.313672] ACPI: PCI Interrupt Link [GSIG] (IRQs *22)
-[    0.314722] ACPI: PCI Interrupt Link [GSIH] (IRQs *23)
-[    0.317172] iommu: Default domain type: Translated
-[    0.317728] vgaarb: loaded
-[    0.318310] SCSI subsystem initialized
-[    0.318954] pps_core: LinuxPPS API ver. 1 registered
-[    0.319804] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
-[    0.321326] PTP clock support registered
-[    0.321687] Registered efivars operations
-[    0.322500] PCI: Using ACPI for IRQ routing
-[    0.323211] PCI: pci_cache_line_size set to 64 bytes
-[    0.324206] e820: reserve RAM buffer [mem 0x00810000-0x008fffff]
-[    0.325212] e820: reserve RAM buffer [mem 0x7f6ef000-0x7fffffff]
-[    0.325657] e820: reserve RAM buffer [mem 0x7fe60000-0x7fffffff]
-[    0.326754] clocksource: Switched to clocksource kvm-clock
-[    0.327844] pnp: PnP ACPI init
-[    0.328425] pnp 00:00: Plug and Play ACPI device, IDs PNP0303 (active)
-[    0.329649] pnp 00:01: Plug and Play ACPI device, IDs PNP0f13 (active)
-[    0.329809] pnp 00:02: Plug and Play ACPI device, IDs PNP0501 (active)
-[    0.331078] pnp 00:03: Plug and Play ACPI device, IDs PNP0b00 (active)
-[    0.332465] system 00:04: [mem 0xb0000000-0xbfffffff window] has been reserved
-[    0.333902] system 00:04: Plug and Play ACPI device, IDs PNP0c01 (active)
-[    0.335579] pnp: PnP ACPI: found 5 devices
-[    0.341670] clocksource: acpi_pm: mask: 0xffffff max_cycles: 0xffffff, max_idle_ns: 2085701024 ns
-[    0.343568] NET: Registered protocol family 2
-[    0.345189] tcp_listen_portaddr_hash hash table entries: 1024 (order: 2, 16384 bytes, linear)
-[    0.346697] TCP established hash table entries: 16384 (order: 5, 131072 bytes, linear)
-[    0.348298] TCP bind hash table entries: 16384 (order: 6, 262144 bytes, linear)
-[    0.349954] TCP: Hash tables configured (established 16384 bind 16384)
-[    0.351468] UDP hash table entries: 1024 (order: 3, 32768 bytes, linear)
-[    0.352774] UDP-Lite hash table entries: 1024 (order: 3, 32768 bytes, linear)
-[    0.354001] NET: Registered protocol family 1
-[    0.354738] pci 0000:00:02.0: PCI bridge to [bus 01]
-[    0.359275] pci_bus 0000:00: resource 4 [io  0x0000-0x0cf7 window]
-[    0.360332] pci_bus 0000:00: resource 5 [io  0x0d00-0xffff window]
-[    0.361390] pci_bus 0000:00: resource 6 [mem 0x000a0000-0x000bffff window]
-[    0.362681] pci_bus 0000:00: resource 7 [mem 0x80000000-0xafffffff window]
-[    0.364042] pci_bus 0000:00: resource 8 [mem 0xc0000000-0xfebfffff window]
-[    0.365243] pci_bus 0000:00: resource 9 [mem 0x1000000000-0x17ffffffff window]
-[    0.366666] PCI: CLS 0 bytes, default 64
-[    0.367453] Trying to unpack rootfs image as initramfs...
-[    2.474287] Freeing initrd memory: 104480K
-[    2.474789] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x2b29812ce43, max_idle_ns: 440795323173 ns
-[    2.476083] workingset: timestamp_bits=46 max_order=19 bucket_order=0
-[    2.477757] fuse: init (API version 7.32)
-[    2.478215] SGI XFS with security attributes, no debug enabled
-[    2.478997] 9p: Installing v9fs 9p2000 file system support
-[    2.479591] NET: Registered protocol family 38
-[    2.480035] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 249)
-[    2.480870] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4
-[    2.481582] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input0
-[    2.482309] ACPI: Power Button [PWRF]
-[    2.482943] PCI Interrupt Link [GSIF] enabled at IRQ 21
-[    2.484131] PCI Interrupt Link [GSIH] enabled at IRQ 23
-[    2.485303] PCI Interrupt Link [GSIE] enabled at IRQ 20
-[    2.486896] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
-[    2.487599] 00:02: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A
-[    2.513070] printk: console [hvc0] enabled
-[    2.514550] brd: module loaded
-[    2.515360] random: fast init done
-[    2.516052] loop: module loaded
-[    2.516563] random: crng init done
-[    2.517477] scsi host0: Virtio SCSI HBA
-[    2.518342] VFIO - User Level meta-driver version: 0.3
-[    2.519286] xt_time: kernel timezone is -0000
-[    2.519803] IPVS: Registered protocols (TCP, UDP, SCTP, AH, ESP)
-[    2.520504] IPVS: Connection hash table configured (size=4096, memory=64Kbytes)
-[    2.521364] IPVS: ipvs loaded.
-[    2.521734] IPVS: [rr] scheduler registered.
-[    2.522232] IPVS: [wrr] scheduler registered.
-[    2.522732] IPVS: [lc] scheduler registered.
-[    2.523234] IPVS: [wlc] scheduler registered.
-[    2.523733] IPVS: [fo] scheduler registered.
-[    2.524237] IPVS: [ovf] scheduler registered.
-[    2.524741] IPVS: [lblc] scheduler registered.
-[    2.525253] IPVS: [lblcr] scheduler registered.
-[    2.525778] IPVS: [dh] scheduler registered.
-[    2.526281] IPVS: [sh] scheduler registered.
-[    2.526770] IPVS: [sed] scheduler registered.
-[    2.527273] IPVS: [nq] scheduler registered.
-[    2.527761] IPVS: ftp: loaded support on port[0] = 21
-[    2.528335] IPVS: [sip] pe registered.
-[    2.528913] ipt_CLUSTERIP: ClusterIP Version 0.8 loaded successfully
-[    2.529668] Initializing XFRM netlink socket
-[    2.530243] NET: Registered protocol family 10
-[    2.530990] Segment Routing with IPv6
-[    2.531446] NET: Registered protocol family 17
-[    2.531980] 9pnet: Installing 9P2000 support
-[    2.532904] NET: Registered protocol family 40
-[    2.533452] IPI shorthand broadcast: enabled
-[    2.533957] sched_clock: Marking stable (2450694990, 83251786)->(2555552194, -21605418)
-[    2.535774] Freeing unused decrypted memory: 2036K
-[    2.536717] Freeing unused kernel image (initmem) memory: 892K
-[    2.537482] Write protecting the kernel read-only data: 14336k
-[    2.538869] Freeing unused kernel image (text/rodata gap) memory: 2044K
-[    2.539890] Freeing unused kernel image (rodata/data gap) memory: 592K
-[    2.540714] Run /init as init process
-[    2.541191]   with arguments:
-[    2.541582]     /init
-[    2.541885]   with environment:
-[    2.542325]     HOME=/
-[    2.542640]     TERM=linux
-```
-
-Expected output as previous versions 
-Complete output from QEMU 6.0.0 with SEV :  
-```
-[    0.000000] Linux version 5.10.25 (gitlab-runner@runner-buildah0) (gcc (Debian 11.2.0-12) 11.2.0, GNU ld (GNU Binutils for Debian) 2.37) #1 SMP Tue Dec 7 11:43:22 CET 2021
-[    0.000000] Command line: tsc=reliable no_timer_check rcupdate.rcu_expedited=1 i8042.direct=1 i8042.dumbkbd=1 i8042.nopnp=1 i8042.noaux=1 noreplace-smp reboot=k console=hvc0 console=hvc1 console=ttyS0 cryptomgr.notests net.ifnames=0 pci=lastbus=0 debug panic=1 nr_cpus=32 scsi_mod.scan=none agent.log=debug
-[    0.000000] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
-[    0.000000] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
-[    0.000000] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
-[    0.000000] x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
-[    0.000000] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'compacted' format.
-[    0.000000] BIOS-provided physical RAM map:
-[    0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009ffff] usable
-[    0.000000] BIOS-e820: [mem 0x0000000000100000-0x00000000007fffff] usable
-[    0.000000] BIOS-e820: [mem 0x0000000000800000-0x0000000000807fff] ACPI NVS
-[    0.000000] BIOS-e820: [mem 0x0000000000808000-0x000000000080ffff] usable
-[    0.000000] BIOS-e820: [mem 0x0000000000810000-0x00000000008fffff] ACPI NVS
-[    0.000000] BIOS-e820: [mem 0x0000000000900000-0x000000007f6eefff] usable
-[    0.000000] BIOS-e820: [mem 0x000000007f6ef000-0x000000007f96efff] reserved
-[    0.000000] BIOS-e820: [mem 0x000000007f96f000-0x000000007f97efff] ACPI data
-[    0.000000] BIOS-e820: [mem 0x000000007f97f000-0x000000007f9fefff] ACPI NVS
-[    0.000000] BIOS-e820: [mem 0x000000007f9ff000-0x000000007fe5ffff] usable
-[    0.000000] BIOS-e820: [mem 0x000000007fe60000-0x000000007fe7ffff] reserved
-[    0.000000] BIOS-e820: [mem 0x000000007fe80000-0x000000007fffffff] ACPI NVS
-[    0.000000] BIOS-e820: [mem 0x00000000b0000000-0x00000000bfffffff] reserved
-[    0.000000] NX (Execute Disable) protection: active
-[    0.000000] efi: EFI v2.70 by EDK II
-[    0.000000] efi: SMBIOS=0x7f7ab000 ACPI=0x7f97e000 ACPI 2.0=0x7f97e014 MEMATTR=0x7e9d8118
-[    0.000000] SMBIOS 2.8 present.
-[    0.000000] DMI: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
-[    0.000000] Hypervisor detected: KVM
-[    0.000000] kvm-clock: Using msrs 4b564d01 and 4b564d00
-[    0.000000] kvm-clock: cpu 0, msr 14201001, primary cpu clock
-[    0.000001] kvm-clock: using sched offset of 3987202924 cycles
-[    0.000004] clocksource: kvm-clock: mask: 0xffffffffffffffff max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 ns
-[    0.000006] tsc: Detected 2994.372 MHz processor
-[    0.000158] e820: update [mem 0x00000000-0x00000fff] usable ==> reserved
-[    0.000161] e820: remove [mem 0x000a0000-0x000fffff] usable
-[    0.000168] last_pfn = 0x7fe60 max_arch_pfn = 0x400000000
-[    0.000215] MTRR default type: write-back
-[    0.000216] MTRR fixed ranges enabled:
-[    0.000218]   00000-9FFFF write-back
-[    0.000220]   A0000-FFFFF uncachable
-[    0.000220] MTRR variable ranges enabled:
-[    0.000222]   0 base 0000C0000000 mask FFFFC0000000 uncachable
-[    0.000224]   1 base 0000B0000000 mask FFFFF0000000 uncachable
-[    0.000226]   2 base 001000000000 mask FFF800000000 uncachable
-[    0.000227]   3 disabled
-[    0.000227]   4 disabled
-[    0.000228]   5 disabled
-[    0.000229]   6 disabled
-[    0.000230]   7 disabled
-[    0.000274] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WP  UC- WT
-[    0.008664] Using GB pages for direct mapping
-[    0.009370] Secure boot could not be determined
-[    0.009372] RAMDISK: [mem 0x6f1ee000-0x757f5fff]
-[    0.009399] ACPI: Early table checksum verification disabled
-[    0.009410] ACPI: RSDP 0x000000007F97E014 000024 (v02 BOCHS )
-[    0.009415] ACPI: XSDT 0x000000007F97D0E8 000054 (v01 BOCHS  BXPC     00000001      01000013)
-[    0.009423] ACPI: FACP 0x000000007F978000 0000F4 (v03 BOCHS  BXPC     00000001 BXPC 00000001)
-[    0.009430] ACPI: DSDT 0x000000007F979000 003278 (v01 BOCHS  BXPC     00000001 BXPC 00000001)
-[    0.009435] ACPI: FACS 0x000000007F9DD000 000040
-[    0.009439] ACPI: APIC 0x000000007F977000 000170 (v01 BOCHS  BXPC     00000001 BXPC 00000001)
-[    0.009443] ACPI: HPET 0x000000007F976000 000038 (v01 BOCHS  BXPC     00000001 BXPC 00000001)
-[    0.009448] ACPI: SRAT 0x000000007F975000 0002D0 (v01 BOCHS  BXPC     00000001 BXPC 00000001)
-[    0.009452] ACPI: MCFG 0x000000007F974000 00003C (v01 BOCHS  BXPC     00000001 BXPC 00000001)
-[    0.009456] ACPI: WAET 0x000000007F973000 000028 (v01 BOCHS  BXPC     00000001 BXPC 00000001)
-[    0.009466] ACPI: Local APIC address 0xfee00000
-[    0.009507] Zone ranges:
-[    0.009508]   DMA      [mem 0x0000000000001000-0x0000000000ffffff]
-[    0.009511]   DMA32    [mem 0x0000000001000000-0x000000007fe5ffff]
-[    0.009513]   Normal   empty
-[    0.009514]   Device   empty
-[    0.009516] Movable zone start for each node
-[    0.009517] Early memory node ranges
-[    0.009518]   node   0: [mem 0x0000000000001000-0x000000000009ffff]
-[    0.009520]   node   0: [mem 0x0000000000100000-0x00000000007fffff]
-[    0.009521]   node   0: [mem 0x0000000000808000-0x000000000080ffff]
-[    0.009522]   node   0: [mem 0x0000000000900000-0x000000007f6eefff]
-[    0.009523]   node   0: [mem 0x000000007f9ff000-0x000000007fe5ffff]
-[    0.009525] Initmem setup node 0 [mem 0x0000000000001000-0x000000007fe5ffff]
-[    0.009528] On node 0 totalpages: 522743
-[    0.009529]   DMA zone: 59 pages used for memmap
-[    0.009531]   DMA zone: 1814 pages reserved
-[    0.009532]   DMA zone: 3751 pages, LIFO batch:0
-[    0.009843]   DMA zone: 29017 pages in unavailable ranges
-[    0.009845]   DMA32 zone: 8122 pages used for memmap
-[    0.009846]   DMA32 zone: 518992 pages, LIFO batch:63
-[    0.014033]   DMA32 zone: 1200 pages in unavailable ranges
-[    0.014785] ACPI: PM-Timer IO Port: 0x608
-[    0.014788] ACPI: Local APIC address 0xfee00000
-[    0.014803] ACPI: LAPIC_NMI (acpi_id[0xff] dfl dfl lint[0x1])
-[    0.014994] IOAPIC[0]: apic_id 0, version 32, address 0xfec00000, GSI 0-23
-[    0.014998] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
-[    0.015001] ACPI: INT_SRC_OVR (bus 0 bus_irq 5 global_irq 5 high level)
-[    0.015003] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
-[    0.015005] ACPI: INT_SRC_OVR (bus 0 bus_irq 10 global_irq 10 high level)
-[    0.015006] ACPI: INT_SRC_OVR (bus 0 bus_irq 11 global_irq 11 high level)
-[    0.015007] ACPI: IRQ0 used by override.
-[    0.015009] ACPI: IRQ5 used by override.
-[    0.015010] ACPI: IRQ9 used by override.
-[    0.015011] ACPI: IRQ10 used by override.
-[    0.015011] ACPI: IRQ11 used by override.
-[    0.015014] Using ACPI (MADT) for SMP configuration information
-[    0.015017] ACPI: HPET id: 0x8086a201 base: 0xfed00000
-[    0.015021] TSC deadline timer available
-[    0.015027] smpboot: Allowing 32 CPUs, 31 hotplug CPUs
-[    0.015039] kvm-guest: KVM setup pv remote TLB flush
-[    0.015048] kvm-guest: setup PV sched yield
-[    0.015065] [mem 0xc0000000-0xffffffff] available for PCI devices
-[    0.015066] Booting paravirtualized kernel on KVM
-[    0.015070] clocksource: refined-jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645519600211568 ns
-[    0.020345] setup_percpu: NR_CPUS:240 nr_cpumask_bits:240 nr_cpu_ids:32 nr_node_ids:1
-[    0.021575] percpu: Embedded 42 pages/cpu s143360 r0 d28672 u262144
-[    0.021585] pcpu-alloc: s143360 r0 d28672 u262144 alloc=1*2097152
-[    0.021587] pcpu-alloc: [0] 00 01 02 03 04 05 06 07 [0] 08 09 10 11 12 13 14 15
-[    0.021596] pcpu-alloc: [0] 16 17 18 19 20 21 22 23 [0] 24 25 26 27 28 29 30 31
-[    0.027137] kvm-guest: KVM setup async PF for cpu 0
-[    0.027144] kvm-guest: stealtime: cpu 0, msr 7d622080
-[    0.027159] Built 1 zonelists, mobility grouping on.  Total pages: 512748
-[    0.027161] Kernel command line: tsc=reliable no_timer_check rcupdate.rcu_expedited=1 i8042.direct=1 i8042.dumbkbd=1 i8042.nopnp=1 i8042.noaux=1 noreplace-smp reboot=k console=hvc0 console=hvc1 console=ttyS0 cryptomgr.notests net.ifnames=0 pci=lastbus=0 debug panic=1 nr_cpus=32 scsi_mod.scan=none agent.log=debug
-[    0.027288] printk: log_buf_len individual max cpu contribution: 4096 bytes
-[    0.027290] printk: log_buf_len total cpu_extra contributions: 126976 bytes
-[    0.027291] printk: log_buf_len min size: 131072 bytes
-[    0.027523] printk: log_buf_len: 262144 bytes
-[    0.027524] printk: early log buf free: 123296(94%)
-[    0.027737] Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes, linear)
-[    0.027850] Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes, linear)
-[    0.027991] mem auto-init: stack:off, heap alloc:off, heap free:off
-[    0.040909] Memory: 1711324K/2090972K available (10242K kernel code, 956K rwdata, 1456K rodata, 892K init, 3564K bss, 379392K reserved, 0K cma-reserved)
-[    0.041029] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=32, Nodes=1
-[    0.041170] rcu: Hierarchical RCU implementation.
-[    0.041171] rcu: 	RCU restricting CPUs from NR_CPUS=240 to nr_cpu_ids=32.
-[    0.041173] 	All grace periods are expedited (rcu_expedited).
-[    0.041174] 	Tracing variant of Tasks RCU enabled.
-[    0.041176] rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies.
-[    0.041177] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=32
-[    0.041233] NR_IRQS: 15616, nr_irqs: 680, preallocated irqs: 16
-[    0.041739] rcu: 	Offload RCU callbacks from CPUs: (none).
-[    0.041913] random: get_random_bytes called from start_kernel+0x2fc/0x4ae with crng_init=0
-[    0.041995] Console: colour dummy device 80x25
-[    0.140890] printk: console [ttyS0] enabled
-[    0.154171] AMD Memory Encryption Features active: SEV
-[    0.154858] ACPI: Core revision 20200925
-[    0.155536] clocksource: hpet: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604467 ns
-[    0.156743] APIC: Switch to symmetric I/O mode setup
-[    0.158619] x2apic enabled
-[    0.160959] Switched APIC routing to physical x2apic.
-[    0.161554] kvm-guest: setup PV IPIs
-[    0.168397] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
-[    0.169300] clocksource: tsc-early: mask: 0xffffffffffffffff max_cycles: 0x2b29812ce43, max_idle_ns: 440795323173 ns
-[    0.170521] Calibrating delay loop (skipped) preset value.. 5988.74 BogoMIPS (lpj=11977488)
-[    0.171487] pid_max: default: 32768 minimum: 301
-[    0.202181] LSM: Security Framework initializing
-[    0.202548] Mount-cache hash table entries: 4096 (order: 3, 32768 bytes, linear)
-[    0.203685] Mountpoint-cache hash table entries: 4096 (order: 3, 32768 bytes, linear)
-[    0.205011] x86/cpu: User Mode Instruction Prevention (UMIP) activated
-[    0.205802] Last level iTLB entries: 4KB 512, 2MB 255, 4MB 127
-[    0.206525] Last level dTLB entries: 4KB 512, 2MB 255, 4MB 127, 1GB 0
-[    0.207435] Spectre V1 : Mitigation: usercopy/swapgs barriers and __user pointer sanitization
-[    0.208419] Spectre V2 : Mitigation: Full AMD retpoline
-[    0.209026] Spectre V2 : Spectre v2 / SpectreRSB mitigation: Filling RSB on context switch
-[    0.209975] Spectre V2 : Enabling Restricted Speculation for firmware calls
-[    0.210523] Spectre V2 : mitigation: Enabling conditional Indirect Branch Prediction Barrier
-[    0.211737] Speculative Store Bypass: Mitigation: Speculative Store Bypass disabled via prctl and seccomp
-[    0.213043] Freeing SMP alternatives memory: 28K
-[    0.213721] smpboot: CPU0: AMD EPYC 7302P 16-Core Processor (family: 0x17, model: 0x31, stepping: 0x0)
-[    0.214519] Performance Events: Fam17h+ core perfctr, AMD PMU driver.
-[    0.214519] ... version:                0
-[    0.214519] ... bit width:              48
-[    0.214519] ... generic registers:      6
-[    0.214519] ... value mask:             0000ffffffffffff
-[    0.214525] ... max period:             00007fffffffffff
-[    0.215142] ... fixed-purpose events:   0
-[    0.215616] ... event mask:             000000000000003f
-[    0.216346] rcu: Hierarchical SRCU implementation.
-[    0.217174] smp: Bringing up secondary CPUs ...
-[    0.217714] smp: Brought up 1 node, 1 CPU
-[    0.218184] smpboot: Max logical packages: 32
-[    0.218527] smpboot: Total of 1 processors activated (5988.74 BogoMIPS)
-[    0.219686] devtmpfs: initialized
-[    0.220119] x86/mm: Memory block size: 128MB
-[    0.220864] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
-[    0.221995] futex hash table entries: 8192 (order: 7, 524288 bytes, linear)
-[    0.222863] NET: Registered protocol family 16
-[    0.223660] DMA: preallocated 256 KiB GFP_KERNEL pool for atomic allocations
-[    0.224813] DMA: preallocated 256 KiB GFP_KERNEL|GFP_DMA pool for atomic allocations
-[    0.225857] DMA: preallocated 256 KiB GFP_KERNEL|GFP_DMA32 pool for atomic allocations
-[    0.226565] thermal_sys: Registered thermal governor 'step_wise'
-[    0.226569] cpuidle: using governor menu
-[    0.228447] ACPI: bus type PCI registered
-[    0.228925] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
-[    0.229775] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xb0000000-0xbfffffff] (base 0xb0000000)
-[    0.230527] PCI: MMCONFIG at [mem 0xb0000000-0xbfffffff] reserved in E820
-[    0.231331] PCI: Using configuration type 1 for base access
-[    0.232839] HugeTLB registered 1.00 GiB page size, pre-allocated 0 pages
-[    0.233641] HugeTLB registered 2.00 MiB page size, pre-allocated 0 pages
-[    0.234545] ACPI: Added _OSI(Module Device)
-[    0.235040] ACPI: Added _OSI(Processor Device)
-[    0.235568] ACPI: Added _OSI(3.0 _SCP Extensions)
-[    0.236115] ACPI: Added _OSI(Processor Aggregator Device)
-[    0.236745] ACPI: Added _OSI(Linux-Dell-Video)
-[    0.237264] ACPI: Added _OSI(Linux-Lenovo-NV-HDMI-Audio)
-[    0.237886] ACPI: Added _OSI(Linux-HPI-Hybrid-Graphics)
-[    0.240277] ACPI: 1 ACPI AML tables successfully acquired and loaded
-[    0.242125] ACPI: Interpreter enabled
-[    0.242530] ACPI: (supports S0 S5)
-[    0.242933] ACPI: Using IOAPIC for interrupt routing
-[    0.243537] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
-[    0.244744] ACPI: Enabled 2 GPEs in block 00 to 3F
-[    0.250149] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
-[    0.250531] acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI HPX-Type3]
-[    0.251661] acpi PNP0A08:00: _OSC: platform does not support [LTR]
-[    0.252454] acpi PNP0A08:00: _OSC: OS now controls [PCIeHotplug SHPCHotplug PME PCIeCapability]
-[    0.253626] PCI host bridge to bus 0000:00
-[    0.254115] pci_bus 0000:00: root bus resource [io  0x0000-0x0cf7 window]
-[    0.254526] pci_bus 0000:00: root bus resource [io  0x0d00-0xffff window]
-[    0.255309] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff window]
-[    0.256179] pci_bus 0000:00: root bus resource [mem 0x80000000-0xafffffff window]
-[    0.257045] pci_bus 0000:00: root bus resource [mem 0xc0000000-0xfebfffff window]
-[    0.257910] pci_bus 0000:00: root bus resource [mem 0x1000000000-0x17ffffffff window]
-[    0.258525] pci_bus 0000:00: root bus resource [bus 00-ff]
-[    0.259223] pci 0000:00:00.0: [8086:29c0] type 00 class 0x060000
-[    0.260509] pci 0000:00:01.0: [1af4:1043] type 00 class 0x078000
-[    0.263098] pci 0000:00:01.0: reg 0x14: [mem 0xc0003000-0xc0003fff]
-[    0.267149] pci 0000:00:01.0: reg 0x20: [mem 0x1000000000-0x1000003fff 64bit pref]
-[    0.269843] pci 0000:00:02.0: [1b36:0001] type 01 class 0x060400
-[    0.275338] pci 0000:00:03.0: [1af4:1048] type 00 class 0x010000
-[    0.277811] pci 0000:00:03.0: reg 0x14: [mem 0xc0002000-0xc0002fff]
-[    0.281320] pci 0000:00:03.0: reg 0x20: [mem 0x1000004000-0x1000007fff 64bit pref]
-[    0.284951] pci 0000:00:04.0: [1af4:1044] type 00 class 0x00ff00
-[    0.287749] pci 0000:00:04.0: reg 0x20: [mem 0x1000008000-0x100000bfff 64bit pref]
-[    0.289851] pci 0000:00:05.0: [1af4:1049] type 00 class 0x000200
-[    0.292301] pci 0000:00:05.0: reg 0x14: [mem 0xc0001000-0xc0001fff]
-[    0.295709] pci 0000:00:05.0: reg 0x20: [mem 0x100000c000-0x100000ffff 64bit pref]
-[    0.298275] pci 0000:00:1f.0: [8086:2918] type 00 class 0x060100
-[    0.299038] pci 0000:00:1f.0: quirk: [io  0x0600-0x067f] claimed by ICH6 ACPI/GPIO/TCO
-[    0.300211] pci 0000:00:1f.2: [8086:2922] type 00 class 0x010601
-[    0.306084] pci 0000:00:1f.2: reg 0x20: [io  0x6040-0x605f]
-[    0.307285] pci 0000:00:1f.2: reg 0x24: [mem 0xc0000000-0xc0000fff]
-[    0.309200] pci 0000:00:1f.3: [8086:2930] type 00 class 0x0c0500
-[    0.312072] pci 0000:00:1f.3: reg 0x20: [io  0x6000-0x603f]
-[    0.314207] pci_bus 0000:01: extended config space not accessible
-[    0.314817] pci 0000:00:02.0: PCI bridge to [bus 01]
-[    0.317358] pci_bus 0000:00: on NUMA node 0
-[    0.318107] ACPI: PCI Interrupt Link [LNKA] (IRQs 5 *10 11)
-[    0.318611] ACPI: PCI Interrupt Link [LNKB] (IRQs 5 *10 11)
-[    0.319355] ACPI: PCI Interrupt Link [LNKC] (IRQs 5 10 *11)
-[    0.320094] ACPI: PCI Interrupt Link [LNKD] (IRQs 5 10 *11)
-[    0.320826] ACPI: PCI Interrupt Link [LNKE] (IRQs 5 *10 11)
-[    0.321565] ACPI: PCI Interrupt Link [LNKF] (IRQs 5 *10 11)
-[    0.322302] ACPI: PCI Interrupt Link [LNKG] (IRQs 5 10 *11)
-[    0.322608] ACPI: PCI Interrupt Link [LNKH] (IRQs 5 10 *11)
-[    0.323292] ACPI: PCI Interrupt Link [GSIA] (IRQs *16)
-[    0.323908] ACPI: PCI Interrupt Link [GSIB] (IRQs *17)
-[    0.324522] ACPI: PCI Interrupt Link [GSIC] (IRQs *18)
-[    0.325132] ACPI: PCI Interrupt Link [GSID] (IRQs *19)
-[    0.325746] ACPI: PCI Interrupt Link [GSIE] (IRQs *20)
-[    0.326356] ACPI: PCI Interrupt Link [GSIF] (IRQs *21)
-[    0.326533] ACPI: PCI Interrupt Link [GSIG] (IRQs *22)
-[    0.327148] ACPI: PCI Interrupt Link [GSIH] (IRQs *23)
-[    0.329169] iommu: Default domain type: Translated
-[    0.329808] vgaarb: loaded
-[    0.330245] SCSI subsystem initialized
-[    0.330537] pps_core: LinuxPPS API ver. 1 registered
-[    0.331124] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
-[    0.332182] PTP clock support registered
-[    0.332667] Registered efivars operations
-[    0.333281] PCI: Using ACPI for IRQ routing
-[    0.333783] PCI: pci_cache_line_size set to 64 bytes
-[    0.334528] e820: reserve RAM buffer [mem 0x00810000-0x008fffff]
-[    0.335230] e820: reserve RAM buffer [mem 0x7f6ef000-0x7fffffff]
-[    0.335932] e820: reserve RAM buffer [mem 0x7fe60000-0x7fffffff]
-[    0.336675] clocksource: Switched to clocksource kvm-clock
-[    0.337485] pnp: PnP ACPI init
-[    0.337896] pnp 00:00: Plug and Play ACPI device, IDs PNP0303 (active)
-[    0.338519] pnp 00:01: Plug and Play ACPI device, IDs PNP0f13 (active)
-[    0.338519] pnp 00:02: Plug and Play ACPI device, IDs PNP0501 (active)
-[    0.338519] pnp 00:03: Plug and Play ACPI device, IDs PNP0b00 (active)
-[    0.338920] system 00:04: [mem 0xb0000000-0xbfffffff window] has been reserved
-[    0.339770] system 00:04: Plug and Play ACPI device, IDs PNP0c01 (active)
-[    0.341103] pnp: PnP ACPI: found 5 devices
-[    0.346943] clocksource: acpi_pm: mask: 0xffffff max_cycles: 0xffffff, max_idle_ns: 2085701024 ns
-[    0.348014] NET: Registered protocol family 2
-[    0.348722] tcp_listen_portaddr_hash hash table entries: 1024 (order: 2, 16384 bytes, linear)
-[    0.349720] TCP established hash table entries: 16384 (order: 5, 131072 bytes, linear)
-[    0.350698] TCP bind hash table entries: 16384 (order: 6, 262144 bytes, linear)
-[    0.351620] TCP: Hash tables configured (established 16384 bind 16384)
-[    0.352423] UDP hash table entries: 1024 (order: 3, 32768 bytes, linear)
-[    0.353213] UDP-Lite hash table entries: 1024 (order: 3, 32768 bytes, linear)
-[    0.354115] NET: Registered protocol family 1
-[    0.354654] pci 0000:00:02.0: PCI bridge to [bus 01]
-[    0.357279] pci_bus 0000:00: resource 4 [io  0x0000-0x0cf7 window]
-[    0.358008] pci_bus 0000:00: resource 5 [io  0x0d00-0xffff window]
-[    0.358744] pci_bus 0000:00: resource 6 [mem 0x000a0000-0x000bffff window]
-[    0.359541] pci_bus 0000:00: resource 7 [mem 0x80000000-0xafffffff window]
-[    0.360345] pci_bus 0000:00: resource 8 [mem 0xc0000000-0xfebfffff window]
-[    0.361145] pci_bus 0000:00: resource 9 [mem 0x1000000000-0x17ffffffff window]
-[    0.362089] PCI: CLS 0 bytes, default 64
-[    0.362638] Trying to unpack rootfs image as initramfs...
-[    2.307254] Freeing initrd memory: 104480K
-[    2.307791] PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
-[    2.308521] software IO TLB: mapped [mem 0x0000000069000000-0x000000006d000000] (64MB)
-[    2.309454] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x2b29812ce43, max_idle_ns: 440795323173 ns
-[    2.311063] workingset: timestamp_bits=46 max_order=19 bucket_order=0
-[    2.313608] fuse: init (API version 7.32)
-[    2.314181] SGI XFS with security attributes, no debug enabled
-[    2.315435] 9p: Installing v9fs 9p2000 file system support
-[    2.316233] NET: Registered protocol family 38
-[    2.316827] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 249)
-[    2.317926] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4
-[    2.318847] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input0
-[    2.319752] ACPI: Power Button [PWRF]
-[    2.320661] PCI Interrupt Link [GSIF] enabled at IRQ 21
-[    2.322549] PCI Interrupt Link [GSIH] enabled at IRQ 23
-[    2.324157] PCI Interrupt Link [GSIE] enabled at IRQ 20
-[    2.326555] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
-[    2.327388] 00:02: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A
-[    2.341959] software IO TLB: Memory encryption is active and system is using DMA bounce buffers
-[    2.344242] printk: console [hvc0] enabled
-[    2.346335] brd: module loaded
-[    2.347023] random: fast init done
-[    2.347786] random: crng init done
-[    2.349418] loop: module loaded
-[    2.351182] scsi host0: Virtio SCSI HBA
-[    2.352317] VFIO - User Level meta-driver version: 0.3
-[    2.353380] xt_time: kernel timezone is -0000
-[    2.354028] IPVS: Registered protocols (TCP, UDP, SCTP, AH, ESP)
-[    2.354873] IPVS: Connection hash table configured (size=4096, memory=64Kbytes)
-[    2.355859] IPVS: ipvs loaded.
-[    2.356319] IPVS: [rr] scheduler registered.
-[    2.356933] IPVS: [wrr] scheduler registered.
-[    2.357542] IPVS: [lc] scheduler registered.
-[    2.358152] IPVS: [wlc] scheduler registered.
-[    2.358787] IPVS: [fo] scheduler registered.
-[    2.359343] IPVS: [ovf] scheduler registered.
-[    2.359968] IPVS: [lblc] scheduler registered.
-[    2.360595] IPVS: [lblcr] scheduler registered.
-[    2.361236] IPVS: [dh] scheduler registered.
-[    2.361846] IPVS: [sh] scheduler registered.
-[    2.362468] IPVS: [sed] scheduler registered.
-[    2.363060] IPVS: [nq] scheduler registered.
-[    2.363623] IPVS: ftp: loaded support on port[0] = 21
-[    2.364272] IPVS: [sip] pe registered.
-[    2.364967] ipt_CLUSTERIP: ClusterIP Version 0.8 loaded successfully
-[    2.365818] Initializing XFRM netlink socket
-[    2.366474] NET: Registered protocol family 10
-[    2.367351] Segment Routing with IPv6
-[    2.367888] NET: Registered protocol family 17
-[    2.368518] 9pnet: Installing 9P2000 support
-[    2.369955] NET: Registered protocol family 40
-[    2.370608] IPI shorthand broadcast: enabled
-[    2.371198] sched_clock: Marking stable (2249797515, 120751625)->(2381329269, -10780129)
-[    2.373554] Freeing unused decrypted memory: 2036K
-[    2.374622] Freeing unused kernel image (initmem) memory: 892K
-[    2.375403] Write protecting the kernel read-only data: 14336k
-[    2.377004] Freeing unused kernel image (text/rodata gap) memory: 2044K
-[    2.378219] Freeing unused kernel image (rodata/data gap) memory: 592K
-[    2.379114] Run /init as init process
-[    2.379599]   with arguments:
-[    2.380009]     /init
-[    2.380321]   with environment:
-[    2.380749]     HOME=/
-[    2.381071]     TERM=linux
-```
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/1023 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/1023
deleted file mode 100644
index d3534699b..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_TCG/1023
+++ /dev/null
@@ -1,60 +0,0 @@
-TCG & LA57 (5-level page tables) causes intermittent triple fault when setting %CR3
-Description of problem:
-Enabling LA57 (5-level page tables) + TCG causes an intermittent triple fault when the kernel loads %cr3 in preparation for jumping to protected mode.  It is quite rare, only happening on perhaps 1 in 20 runs.
-
-The observed behaviour for most users is that we see SeaBIOS messages, and no kernel messages, and qemu exits.  (Triple fault in TCG code causes qemu to reset the virtual CPU, and we are using `-no-reboot` so that causes qemu to exit).
-
-There's a simple reproducer below.  I enabled qemu -d options to capture the full instruction traces which can be found here:
-
-http://oirase.annexia.org/tmp/fullexec-failed (error case)
-http://oirase.annexia.org/tmp/fullexec-good (successful run)
-
-I also added an `abort()` into qemu after the triple fault message in order to capture a stack trace, which can be found here: https://bugzilla.redhat.com/show_bug.cgi?id=2082806#c8
-Steps to reproduce:
-1. Save the following script into a file, adjusting the two variables at the top as appropriate:
-
-```
-#!/bin/bash -
-
-# Point this to any kernel in /boot:
-kernel=/boot/vmlinuz-4.18.0-387.el8.x86_64
-
-# Point this to qemu:
-qemu=/usr/libexec/qemu-kvm
-#qemu=/home/rjones/d/qemu/build/qemu-system-x86_64
-
-log=/tmp/log
-
-cpu=max
-#cpu=max,la57=off
-
-while $qemu \
-    -global virtio-blk-pci.scsi=off \
-    -no-user-config \
-    -nodefaults \
-    -display none \
-    -machine accel=tcg,graphics=off \
-    -cpu "$cpu" \
-    -m 2048 \
-    -no-reboot \
-    -rtc driftfix=slew \
-    -no-hpet \
-    -global kvm-pit.lost_tick_policy=discard \
-    -kernel $kernel \
-    -object rng-random,filename=/dev/urandom,id=rng0 \
-    -device virtio-rng-pci,rng=rng0 \
-    -device virtio-serial-pci \
-    -serial stdio \
-    -append "panic=1 console=ttyS0" >& $log &&
-    grep -sq "Linux version" $log; do
-    echo -n .
-done
-```
-
-2. Run the script.  It will run qemu many times, checking that it reaches the kernel.
-3. Eventually the script may exit. 
-4. Check `/tmp/log` and see if you only see SeaBIOS messages.
-5. Modify the script to add `-cpu max,la57=off` and the error will stop happening.
-Additional information:
-Downstream bug report: https://bugzilla.redhat.com/show_bug.cgi?id=2082806
-LA57 was enabled here: https://gitlab.com/qemu-project/qemu/-/issues/661
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/1059 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/1059
deleted file mode 100644
index a336146ad..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_TCG/1059
+++ /dev/null
@@ -1,10 +0,0 @@
-qemu: uncaught target signal 6 (Aborted) - core dumped Issue
-Description of problem:
-When we are trying to use the docker images which is using Qemu internally in mac Os then we are getting the qemu: uncaught target signal 6 (Aborted) - core dumped Issue
-Steps to reproduce:
-1. https://botfront.io/docs/installation/local-machine install in local machine
-2. run bot front run
-3. Go to the docker dashboard and open the botfront-rasa. 
-4. ![Screenshot_2022-06-03_at_12.34.54_PM](/uploads/db4f0ba030cac850e1ae90189d1f8a55/Screenshot_2022-06-03_at_12.34.54_PM.png)
-Additional information:
-Looking forward to get some updates regarding how we can solve this or any hack we can apply here. Thanks in advance.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/1143 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/1143
deleted file mode 100644
index c3576e3b4..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_TCG/1143
+++ /dev/null
@@ -1,78 +0,0 @@
-Breakpoints missed when a function is split into two memory pages.
-Description of problem:
-Qemu seems to ignore some breakpoints when the start of a function is 
-in another page than where the breakpoint is set. 
-
-In my case, I've a function `__gnat_debug_raise_exception` which starts at `0x10bff2` and I've set with gdb a breakpoint at `0x10c00e` (in another page). 
-While running with `qemu -d in_asm,exec`, I can see that the whole function is executed at once and that no breakpoint is fired.
-
-```
-(gdb) b *0x00108fbc
-(gdb) b *0x0010c00e
-(gdb) target remote :1234 
-(gdb) c
-
-Trace 0: 0x7f277c0174c0 [0000000000000000/0000000000108fb9/0040c0b0/ff000201] ada__exceptions__complete_occurrence
-----------------
-
-// gdb hits first breakpoint here. 
-Breakpoint 3, 0x0000000000108fbc ....
-(gdb) ni
-
-IN: ada__exceptions__complete_occurrence
-0x00108fbc:  e8 31 30 00 00           callq    0x10bff2
-
-Trace 0: 0x7f277c000100 [0000000000000000/0000000000108fbc/0040c0b0/ff000e01] ada__exceptions__complete_occurrence
-----------------
-IN: __gnat_debug_raise_exception
-0x0010bff2:  55                       pushq    %rbp
-0x0010bff3:  48 89 e5                 movq     %rsp, %rbp
-0x0010bff6:  48 89 7d f8              movq     %rdi, -8(%rbp)
-0x0010bffa:  48 89 d1                 movq     %rdx, %rcx
-0x0010bffd:  48 89 f0                 movq     %rsi, %rax
-0x0010c000:  48 89 fa                 movq     %rdi, %rdx
-0x0010c003:  48 89 ca                 movq     %rcx, %rdx
-0x0010c006:  48 89 45 e0              movq     %rax, -0x20(%rbp)
-0x0010c00a:  48 89 55 e8              movq     %rdx, -0x18(%rbp)
-0x0010c00e:  48 8b 45 e0              movq     -0x20(%rbp), %rax
-0x0010c012:  90                       nop      
-0x0010c013:  5d                       popq     %rbp
-0x0010c014:  c3                       retq     
-
-Trace 0: 0x7f277c000100 [0000000000000000/000000000010bff2/0040c0b0/ff000000] __gnat_debug_raise_exception
-Digging a bit more, it seems that it seems related to 
-
-// gdb ni stop here. Breakpoints at 0x10c00e have been ignored. 
-```
-
-Note that if I'm setting another breakpoint at `0x0010bffd` (thus not at the start of the function but still in the same page), the execution 
-will be executed step by step and the breakpoint at 0x10c00e will be triggered normally. 
-
-
-```
-IN: ada__exceptions__complete_occurrence
-0x00108fbc:  e8 31 30 00 00           callq    0x10bff2
-
-Trace 0: 0x7f6af4000100 [0000000000000000/0000000000108fbc/0040c0b0/ff000e01] ada__exceptions__complete_occurrence
-----------------
-IN: __gnat_debug_raise_exception
-0x0010bff2:  55                       pushq    %rbp
-
-Trace 0: 0x7f6af4000100 [0000000000000000/000000000010bff2/0040c0b0/ff000201] __gnat_debug_raise_exception
-----------------
-IN: __gnat_debug_raise_exception
-0x0010bff3:  48 89 e5                 movq     %rsp, %rbp
-
-Trace 0: 0x7f6af4000280 [0000000000000000/000000000010bff3/0040c0b0/ff000201] __gnat_debug_raise_exception
-----------------
-IN: __gnat_debug_raise_exception
-0x0010bff6:  48 89 7d f8              movq     %rdi, -8(%rbp)
-...
-```
-
-I've dug a bit into qemu translator code and I guess `check_for_breakpoint` should check that the whole function is in the same page before skipping step by step. But I'm not sure if it's possible because the TB is created after `check_for_breakpoint` IIUC. 
-
-Sadly as of now, I don't have a C reproducer. I can try to provide you my "foo" program which is an Ada program. But maybe if you've a better idea how to reproduce that or an idea of to fix that, I'll be glad to help you.  
-
-Thanks, 
-Clément
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/125 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/125
deleted file mode 100644
index 002916f99..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_TCG/125
+++ /dev/null
@@ -1 +0,0 @@
-x86: ret, lret and iret with noncanonical IP saves wrong IP on the exception stack
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/1269 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/1269
deleted file mode 100644
index 1e96cc928..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_TCG/1269
+++ /dev/null
@@ -1,26 +0,0 @@
-qemu-system-i386 no longer boots NetBSD
-Description of problem:
-Since qemu commit e3a79e0e87831602e41819591a8e6dcc70a2a231, NetBSD
-no longer boots under qemu-system-i386.
-Steps to reproduce:
-1. `wget http://ftp.netbsd.org/pub/NetBSD/NetBSD-9.2/i386/installation/cdrom/boot-com.iso`
-2. `qemu-system-i386 -nographic -cdrom boot-com.iso`
-
-Expected behavior: the system boots and prompts you for a terminal type with
-
-    Terminal type (just hit ENTER for 'vt220'):
-
-Observed incorrect behavior: the guest kernel either hangs during boot at
-
-    Loading /stand/i386/9.2/modules/cd9660/cd9660.kmod  
-    WARNING: 1 module failed to load
-
-or panics during boot with
-
-    kernel: supervisor trap page fault, code=0
-    Stopped in pid 0.1 (system) at  netbsd:idt_vec_reserve+0xa:     cmpb    $0,netbs
-    d:idt_allocmap(%ebx)
-    db{0}>
-Additional information:
-This regression is a critical issue to the NetBSD project as its automated
-testing infrastructure is heavily dependent on qemu-system-i386.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/130 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/130
deleted file mode 100644
index 09099b7d6..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_TCG/130
+++ /dev/null
@@ -1 +0,0 @@
-QEmu translation is incorrect when using REX in combination with LAHF/SAHF
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/132 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/132
deleted file mode 100644
index f655cda63..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_TCG/132
+++ /dev/null
@@ -1 +0,0 @@
-AVX instruction VMOVDQU implementation error for YMM registers
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/1324 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/1324
deleted file mode 100644
index b794f4d64..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_TCG/1324
+++ /dev/null
@@ -1,40 +0,0 @@
-Unhandled exception when booting UEFI x86_64 system image
-Description of problem:
-I have a bootable Ubuntu 20.04-based operating system image that I typically flash to the internal storage of an embedded Intel Atom computer. When I try booting it under QEMU, I reach the GRUB boot menu, but when it attempts to start the kernel, it outputs:
-
-```
-ERROR:../target/i386/tcg/sysemu/excp_helper.c:517:raise_stage2: code should not be reached
-Bail out! ERROR:../target/i386/tcg/sysemu/excp_helper.c:517:raise_stage2: code should not be reached
-Aborted (core dumped)
-``` 
-
-The kernel settings configured in GRUB are:
-
-```
-linux         /boot/vmlinuz-5.4.0-132-generic root=UUID=816fe083-fc26-4a0d-ae4a-68d1b16dfb66 ro console=uart,mmio32,0xd091c000 console=ttyS4,115200n8 console=tty0                                                         ?
-initrd        /boot/initrd.img-5.4.0-132-generic 
-```
-
-If I run an older QEMU 4.2.1 that ships with Ubuntu:
-
-```
-!!!! X64 Exception Type - 0D(#GP - General Protection)  CPU Apic ID - 00000000 !!!!
-ExceptionData - 0000000000000000
-RIP  - 0000000007F2CD0E, CS  - 0000000000000038, RFLAGS - 0000000000200206
-RAX  - AFAFAFAFAFAFAFAF, RCX - 000000000657F408, RDX - AFAFAFAFAFAFAFAF
-RBX  - 0000000000000288, RSP - 0000000007F1BC48, RBP - 0000000007F336A0
-RSI  - 0000000007F336F8, RDI - 0000000000001000
-R8   - 000000000657F408, R9  - 0000000000000320, R10 - 0000000000000000
-R11  - 0000000000000000, R12 - 0000000000000004, R13 - 000000000657F400
-R14  - 0000000000000000, R15 - 0000000000000000
-DS   - 0000000000000030, ES  - 0000000000000030, FS  - 0000000000000030
-GS   - 0000000000000030, SS  - 0000000000000030
-CR0  - 0000000080010033, CR2 - 0000000000000000, CR3 - 0000000007C01000
-CR4  - 0000000000000668, CR8 - 0000000000000000
-DR0  - 0000000000000000, DR1 - 0000000000000000, DR2 - 0000000000000000
-DR3  - 0000000000000000, DR6 - 00000000FFFF0FF0, DR7 - 0000000000000400
-GDTR - 0000000007BEEA98 0000000000000047, LDTR - 0000000000000000
-IDTR - 00000000072D1018 0000000000000FFF,   TR - 0000000000000000
-FXSAVE_STATE - 0000000007F1B8A0
-!!!! Find image based on IP(0x7F2CD0E) /build/edk2-xUnmxG/edk2-0~20191122.bd85bf54/Build/OvmfX64/RELEASE_GCC5/X64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.dll (ImageBase=0000000007F1D000, EntryPoint=0000000007F2FAAE) !!!!
-```
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/1350 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/1350
deleted file mode 100644
index 87fc45ef7..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_TCG/1350
+++ /dev/null
@@ -1,89 +0,0 @@
-Regression in 7.2.0rc3: No snow by efi firmware in advent calendar 2020, door 15 anymore
-Description of problem:
-Advent calendar 2020, door 15 is expected to produce snow on the terminal while executing the provided efi firmware:
-
-> snow in micropython on slimbootloader by eldon
-> -------------------------------------------
-> 
-> Today's advent is a custom efi firmware build of a new bootloader from intel called
-> slimbootloader[1], a recent project by intel which has adapted micropython[2] as a 
-> utility for configuration and board testing. This build, however, will show snowfall on
-> the console for a while. Eventually an exception drops the firmware into the micropython
-> repl.
-> 
-> [1] https://slimbootloader.github.io/supported-hardware/qemu.html
-> [2] http://docs.micropython.org/en/latest/index.html
-
-
-Snow does not fall anymore as it did with 7.1.0, it seems like execution is stopped/not started
-Steps to reproduce:
-- Build & Install from git source
-    ```
-    /home/helge/qemu-project/qemu/configure --prefix=/home/helge/qemu-project/install \
-      --target-list=x86_64-softmmu --disable-linux-user
-    make -j2
-    make install
-    ```
- - Execute 
-   ```
-   PATH="/home/helge/qemu-project/install/bin" qemu-system-x86_64 \
-      -m 256M -machine q35 -serial mon:stdio -vga none \
-      -drive if=pflash,format=raw,file=snow.bin -boot a
-   ```
-Additional information:
-Performing git bisect starting with tag v7.1.0 as good and tag v7.2.0-rc3 as bad reveals 92ec056a6b2fc5d5a5593121c5d9475d2a2461d6 as culprit:
-   ```
-$ git bisect start c4ffd91aba1c3d878e99a3e7ba8aad4826728ece 621da7789083b80d6f1ff1c0fb499334007b4f51
-binäre Suche: danach noch 965 Commits zum Testen übrig (ungefähr 10 Schritte)
-[2ba341b3694cf3cff7b8a1df4cc765900d5c4f60] Merge tag 'kraxel-20221013-pull-request' of https://gitlab.com/kraxel/qemu into staging
-$ git bisect good
-binäre Suche: danach noch 482 Commits zum Testen übrig (ungefähr 9 Schritte)
-[05c049f12b88370de7289bf39b14088c7d656caa] hw/isa/piix3: Remove extra ';' outside of functions
-$ git bisect bad
-binäre Suche: danach noch 228 Commits zum Testen übrig (ungefähr 8 Schritte)
-[08a5d04606292b3cf6f5756bf2a095654a290626] Merge tag 'pull-tcg-20221026' of https://gitlab.com/rth7680/qemu into staging
-$ git bisect bad
-binäre Suche: danach noch 126 Commits zum Testen übrig (ungefähr 7 Schritte)
-[168122419ed1c4087748e21131a523c6d9b632e1] target/arm: Change gen_goto_tb to work on displacements
-$ git bisect bad
-binäre Suche: danach noch 69 Commits zum Testen übrig (ungefähr 6 Schritte)
-[2c65091fd9d387b8dca8115dbdd9c3c61f658a9e] Merge tag 'pull-ppc-20221017' of https://gitlab.com/danielhb/qemu into staging
-$ git bisect good
-binäre Suche: danach noch 34 Commits zum Testen übrig (ungefähr 5 Schritte)
-[92ec056a6b2fc5d5a5593121c5d9475d2a2461d6] target/i386: reimplement 0x0f 0x60-0x6f, add AVX
-$ git bisect bad
-binäre Suche: danach noch 17 Commits zum Testen übrig (ungefähr 4 Schritte)
-[8629e77be5f8106b3497cc197fbd57a12ae6333f] target/i386: Use probe_access_full for final stage2 translation
-$ git bisect good
-binäre Suche: danach noch 8 Commits zum Testen übrig (ungefähr 3 Schritte)
-[20581aadec5e5a9d6836e4612b6f44a7cbda7d16] target/i386: validate VEX prefixes via the instructions' exception classes
-$ git bisect good
-binäre Suche: danach noch 4 Commits zum Testen übrig (ungefähr 2 Schritte)
-[f05f9789f57d5394fc118fe31aa2a9f563311140] target/i386: extend helpers to support VEX.V 3- and 4- operand encodings
-$ git bisect good
-binäre Suche: danach noch 2 Commits zum Testen übrig (ungefähr 1 Schritt)
-[620f75566a5d81d7b82b3788b83d0b95c7d21dcd] target/i386: provide 3-operand versions of unary scalar helpers
-$ git bisect good
-binäre Suche: danach noch 0 Commits zum Testen übrig (ungefähr 1 Schritt)
-[b98f886c8f8661773047197d132efec97810b37a] target/i386: Introduce 256-bit vector helpers
-$ git bisect good
-92ec056a6b2fc5d5a5593121c5d9475d2a2461d6 is the first bad commit
-commit 92ec056a6b2fc5d5a5593121c5d9475d2a2461d6
-Author: Paolo Bonzini <pbonzini@redhat.com>
-Date:   Tue Sep 20 05:42:45 2022 -0400
-
-    target/i386: reimplement 0x0f 0x60-0x6f, add AVX
-    
-    These are both MMX and SSE/AVX instructions, except for vmovdqu.  In both
-    cases the inputs and output is in s->ptr{0,1,2}, so the only difference
-    between MMX, SSE, and AVX is which helper to call.
-    
-    Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
-    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
-
- target/i386/tcg/decode-new.c.inc |  42 ++++++++
- target/i386/tcg/emit.c.inc       | 202 +++++++++++++++++++++++++++++++++++++++
- target/i386/tcg/translate.c      |  19 +++-
- 3 files changed, 262 insertions(+), 1 deletion(-)
-
-   ```
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/1370 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/1370
deleted file mode 100644
index 763211bee..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_TCG/1370
+++ /dev/null
@@ -1,13 +0,0 @@
-x86 BLSI and BLSR semantic bug
-Description of problem:
-The result of instruction BLSI and BLSR is different from the CPU. The value of CF is different.
-Steps to reproduce:
-1. Compile this code
-```
-void main() {
-    asm("blsi rax, rbx");
-}
-```
-2. Execute and compare the result with the CPU. The value of `CF` is exactly the opposite. This problem happens with BLSR, too.
-Additional information:
-This bug is discovered by research conducted by KAIST SoftSec.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/1371 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/1371
deleted file mode 100644
index 833f1dfc9..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_TCG/1371
+++ /dev/null
@@ -1,19 +0,0 @@
-x86 BLSMSK semantic bug
-Description of problem:
-The result of instruction BLSMSK is different with from the CPU. The value of CF is different.
-Steps to 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 information:
-This bug is discovered by research conducted by KAIST SoftSec.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/1372 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/1372
deleted file mode 100644
index c0a7f3da2..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_TCG/1372
+++ /dev/null
@@ -1,20 +0,0 @@
-x86 BEXTR semantic bug
-Description of problem:
-The result of instruction BEXTR is different with from the CPU. The value of destination register is different. I think QEMU does not consider the operand size limit.
-Steps to reproduce:
-1. Compile this code
-```
-void main() {
-    asm("mov rax, 0x17b3693f77fb6e9");
-    asm("mov rbx, 0x8f635a775ad3b9b4");
-    asm("mov rcx, 0xb717b75da9983018");
-    asm("bextr eax, ebx, ecx");
-}
-```
-2. Execute and compare the result with the CPU.
-    - CPU
-        - RAX = 0x5a
-    - QEMU
-        - RAX = 0x635a775a
-Additional information:
-This bug is discovered by research conducted by KAIST SoftSec.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/1373 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/1373
deleted file mode 100644
index c25a3a9e9..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_TCG/1373
+++ /dev/null
@@ -1,20 +0,0 @@
-x86 ADOX and ADCX semantic bug
-Description of problem:
-The result of instruction ADOX and ADCX are different from the CPU. The value of one of EFLAGS is different.
-Steps to reproduce:
-1. Compile this code
-```
-void main() {
-    asm("push 512; popfq;");
-    asm("mov rax, 0xffffffff84fdbf24");
-    asm("mov rbx, 0xb197d26043bec15d");
-    asm("adox eax, ebx");
-}
-```
-2. Execute and compare the result with the CPU. This problem happens with ADCX, too (with CF).
-    - CPU
-        - OF = 0
-    - QEMU
-        - OF = 1
-Additional information:
-This bug is discovered by research conducted by KAIST SoftSec.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/1374 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/1374
deleted file mode 100644
index bf04368e7..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_TCG/1374
+++ /dev/null
@@ -1,22 +0,0 @@
-x86 BZHI semantic bug
-Description of problem:
-The result of instruction BZHI is different from the CPU. The value of destination register and SF of EFLAGS are different.
-Steps to reproduce:
-1. Compile this code
-```
-void main() {
-    asm("mov rax, 0xb1aa9da2fe33fe3");
-    asm("mov rbx, 0x80000000ffffffff");
-    asm("mov rcx, 0xf3fce8829b99a5c6");
-    asm("bzhi rax, rbx, rcx");
-}
-```
-2. Execute and compare the result with the CPU.
-    - CPU
-        - RAX = 0x0x80000000ffffffff
-        - SF = 1
-    - QEMU
-        - RAX = 0xffffffff
-        - SF = 0
-Additional information:
-This bug is discovered by research conducted by KAIST SoftSec.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/1375 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/1375
deleted file mode 100644
index d7847c8e2..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_TCG/1375
+++ /dev/null
@@ -1,19 +0,0 @@
-x86 SSE/SSE2/SSE3 instruction semantic bugs with NaN
-Description of problem:
-The result of SSE/SSE2/SSE3 instructions with NaN is different from the CPU. From Intel manual Volume 1 Appendix D.4.2.2, they defined the behavior of such instructions with NaN. But I think QEMU did not implement this semantic exactly because the byte result is different.
-Steps to reproduce:
-1. Compile this code
-```
-void main() {
-    asm("mov rax, 0x000000007fffffff; push rax; mov rax, 0x00000000ffffffff; push rax; movdqu XMM1, [rsp];");
-    asm("mov rax, 0x2e711de7aa46af1a; push rax; mov rax, 0x7fffffff7fffffff; push rax; movdqu XMM2, [rsp];");
-    asm("addsubps xmm1, xmm2");
-}
-```
-2. Execute and compare the result with the CPU. This problem happens with other SSE/SSE2/SSE3 instructions specified in the manual, Volume 1 Appendix D.4.2.2.
-    - CPU
-        - xmm1[3] = 0xffffffff
-    - QEMU
-        - xmm1[3] = 0x7fffffff
-Additional information:
-This bug is discovered by research conducted by KAIST SoftSec.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/1376 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/1376
deleted file mode 100644
index 06247c64a..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_TCG/1376
+++ /dev/null
@@ -1,15 +0,0 @@
-x86 LSL and LAR fault
-Description of problem:
-From the description of LSL and LAR instructions in manual, `If the segment descriptor cannot be accessed or is an invalid type for the instruction, the ZF flag is cleared and no value is loaded in the destination operand.`. When it happens at the CPU, it seems they do nothing (nop). However, in QEMU, it crashes.
-Steps to reproduce:
-1. Compile this code
-```
-void main() {
-    asm("mov rax, 0xa02e698e741f5a6a");
-    asm("mov rbx, 0x20959ddd7a0aef");
-    asm("lsl ax, bx");
-}
-```
-2. Execute. QEMU crashes but CPU does not. This problem happens with LAR, too.
-Additional information:
-This bug is discovered by research conducted by KAIST SoftSec.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/1377 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/1377
deleted file mode 100644
index 140f34d8e..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_TCG/1377
+++ /dev/null
@@ -1,14 +0,0 @@
-x86 CVT* series instructions fault
-Description of problem:
-For example, CVTSD2SS instruction converts SRC[63:0] double precision floating point to DEST[31:0] single precision floating point. Although the CVTSD2SS instruction uses only 8 bytes, if it overlaps page boundary, I think QEMU tries to access over the valid memory and crashes.
-Steps to reproduce:
-1. Compile this code
-```
-void main() {
-    mmap(0x555555559000, 0x1000, flag, ~~, 0);
-    asm("cvtsd2ss xmm1, qword ptr [0x555555559ff8]");
-}
-```
-2. Execute. QEMU crashes but CPU does not.
-Additional information:
-This bug is discovered by research conducted by KAIST SoftSec.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/1471 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/1471
deleted file mode 100644
index 876a6dce8..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_TCG/1471
+++ /dev/null
@@ -1,16 +0,0 @@
-16fc5726a6 breaks curl SSL connections
-Description of problem:
-`./qemu-x86_64 /path/to/curl-amd64 https://news.bbc.co.uk` should work, just as `./qemu-aarch64 /path/to/curl-aarch64 https://news.bbc.co.uk` does. However, commit 16fc5726a6e296b3f63acec537c299c1dc49d6c4 broke this (determined via `git bisect`).
-Steps to reproduce:
-1. Checkout and build `qemu` commit 16fc5726a6e296b3f63acec537c299c1dc49d6c4
-2. On an aarch64 host system, download the amd64 build of `curl` from https://github.com/moparisthebest/static-curl/releases/tag/v7.87.0
-3. Run `./qemu-x86_64 /path/to/curl-amd64 https://news.bbc.co.uk`
-4. Observe the following error message:
-
-```
-curl: (35) error:1416D07B:SSL routines:tls_process_key_exchange:bad signature
-```
-
-Note that the `aarch64` equivalent works just fine. As does the previous commit using `amd64`. 
-
-Also note, this bug is also present at current tip (13356edb87506c148b163b8c7eb0695647d00c2a).
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/1478 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/1478
deleted file mode 100644
index c32aa0747..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_TCG/1478
+++ /dev/null
@@ -1,66 +0,0 @@
-Qemu 7.2.0 i386: core2: init crash (glibc)
-Description of problem:
-The toolchain-builder project (a side project of Buildroot to build pre-built toolchains) reported an issue with Qemu 7.2.0 for  x86-core2--glibc--bleeding-edge toolchain, see:
-
-https://gitlab.com/buildroot.org/toolchains-builder/-/jobs/3731683337
-
-Reverting back to Qemu 7.1.0, the system boot correctly with the same system image.
-I reproduced the issue with the current Qemu master (6b433719eabf0abc74cff0cfd5687f0137c4198a)
-
-Here is the boot log obtained with Qemu 7.2.0:
-   ```
-Run /sbin/init as init process
-random: fast init done
-EXT4-fs (vda): warning: mounting unchecked fs, running e2fsck is recommended
-EXT4-fs (vda): re-mounted. Opts: (null). Quota mode: disabled.
-Starting syslogd: OK
-traps: syslogd[52] general protection fault ip:b7e21465 sp:bfe59e6c error:0 in libc.so.6[b7d9b000+123000]
-Starting klogd: OK
-traps: klogd[56] general protection fault ip:b7e94465 sp:bf8f069c error:0 in libc.so.6[b7e0e000+123000]
-Running sysctl: traps: logger[62] general protection fault ip:b7e48b6c sp:bfd7d194 error:0 in libc.so.6[b7e05000+123000]
-Segmentation fault
-traps: logger[64] general protection fault ip:b7dd3b6c sp:bf9b8604 error:0 in libc.so.6[b7d90000+123000]
-Segmentation fault
-
-traps: init[100] general protection fault ip:b7dda465 sp:bfd5f42c error:0 in libc.so.6[b7d54000+123000]
-Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
-CPU: 0 PID: 1 Comm: init Not tainted 5.15.18 #1
-Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.1-0-g3208b098f51a-prebuilt.qemu.org 04/01/2014
-Call Trace:
- dump_stack_lvl+0x32/0x41
- dump_stack+0xd/0x10
- panic+0x90/0x206
- do_exit.cold+0xa9/0xa9
- do_group_exit+0x2a/0x90
- get_signal+0x115/0x7e0
- arch_do_signal_or_restart+0x90/0x5a0
- ? put_pid+0xc/0x20
- ? kernel_clone+0x10b/0x3d0
- exit_to_user_mode_prepare+0xf8/0x1c0
- syscall_exit_to_user_mode+0x1b/0x40
- do_int80_syscall_32+0x41/0x90
- entry_INT80_32+0xf0/0xf0
-EIP: 0xb7de5d88
-Code: 37 01 00 00 65 ff 15 10 00 00 00 89 d0 5a 5b 5e 5f 5d c3 66 90 66 90 66 90 66 90 66 90 66 90 66 90 90 59 b8 be 00 00 00 cd 80 <51> 3d 01 f0 ff ff 0f 83 06 e9 f6 ff c3 e8 81 a0 06 00 05 9a a0 0e
-EAX: 00000064 EBX: 0059aa1c ECX: 00561f5b EDX: 00000008
-ESI: 0059cc20 EDI: bfd5fa64 EBP: 0059b138 ESP: bfd5fa20
-DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 007b EFLAGS: 00000246
-Kernel Offset: disabled
----[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]---
-   ```
-I did a git bisect on qemu sources up to this commit:
-
-https://gitlab.com/qemu-project/qemu/-/commit/958e1dd1300f37f18b2161dfb4eb806fc8c19b44
-Steps to reproduce:
-Build the Buildroot qemu_x86_defconfig with BR2_x86_core2 target architecture variant added manually
-1. git clone https://gitlab.com/buildroot.org/buildroot.git
-2. git switch --detach c419ef62d84b5be65599452ab84f7ed719bbe470
-3. make qemu_x86_defconfig
-4. make menuconfig (enable BR2_x86_core2)
-5. make
-6. ./output/images/start-qemu.sh
-Additional information:
-System built with gcc options:
-   ```
-i686-buildroot-linux-gnu-gcc.br_real' '--sysroot' 'output/host/i686-buildroot-linux-gnu/sysroot' '-fstack-protector-strong' '-fPIE' '-pie' '-Wl,-z,now' '-Wl,-z,relro'
-   ```
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/1506 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/1506
deleted file mode 100644
index cbc64641b..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_TCG/1506
+++ /dev/null
@@ -1 +0,0 @@
-QEMU not support 32-bit stack in unreal/flat/big 32-bit mode
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/1517 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/1517
deleted file mode 100644
index 8812cc717..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_TCG/1517
+++ /dev/null
@@ -1 +0,0 @@
-TCG doesn't support requested feature: CPUID.80000001H:EDX.syscall [bit 11]/TCG doesn't support requested feature: CPUID.80000001H:EDX.lm [bit 29]
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/1637 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/1637
deleted file mode 100644
index 5ccb40196..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_TCG/1637
+++ /dev/null
@@ -1 +0,0 @@
-Crash when executing `ucomiss` instructions emulating an x86-64 CPU on an AArch64 host
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/164 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/164
deleted file mode 100644
index a8077bc9e..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_TCG/164
+++ /dev/null
@@ -1 +0,0 @@
-qemu x86 TCG doesn't support AVX insns
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/1661 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/1661
deleted file mode 100644
index 550aaae5a..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_TCG/1661
+++ /dev/null
@@ -1,11 +0,0 @@
-x86 cpu support request: LX Geode
-Description of problem:
-The Geode LX family of CPUs were used in early generations of the One Laptop Per Child (OLPC) systems (XO 1.0).
-
-They are _basically_ i686-compatible but they lack the 'long-nop' (0x0f 0x1f) instruction available on many other i686-class devices.
-
-Since i686 is a reasonably common baseline for toolchains and the software that is distributed using those toolchains, it would be convenient to be able to use QEMU to test boundary compatibility cases for this CPU.
-Steps to reproduce:
-N/A - feature does not currently exist
-Additional information:
-I'm not adding additional context here at the moment, but please let me know what else would be helpful to know (and/or if I'm off-track with this feature request for any reason).  Thank you!
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/1803 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/1803
deleted file mode 100644
index fbed661ed..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_TCG/1803
+++ /dev/null
@@ -1,14 +0,0 @@
-8.x x86_64 system emulation/tcg regression (general protection fault)
-Description of problem:
-Running the ISO available at https://repo.chimera-linux.org/live/20230611/chimera-linux-x86_64-LIVE-20230611-gnome.iso with the above qemu command line, the graphical environment fails to come up. The system boots, and login prompt shows up; then graphical environment startup is attempted, with Wayland (you can tell as the login prompt cursor no longer blinks, being "frozen" for possibly up to a few minutes due to emulation cost). Then the graphical startup crashes (you can tell because the cursor starts blinking again) and an X11-based startup is attempted (you can tell by the X11 cross cursor) which however never fully comes up either.
-Steps to reproduce:
-1. Download the ISO and run with the command line above.
-2. See the issue.
-Additional information:
-It is possible to then switch to tty2 (View->compatmonitor0, `sendkey ctrl-alt-f2`), log in as `root:chimera` or `anon:chimera` as the console prompt instructs, and type in `dmesg` (as `root`) or `doas dmesg` (as `anon`) and see that the `dmesg` contains a number of general protection faults, like this:
-
-![Screenshot_from_2023-08-02_02-08-41](/uploads/b0e613c5191e41fce3958b74dd5dd4b7/Screenshot_from_2023-08-02_02-08-41.png)
-
-The system used to work, but I am not sure which is the last version of QEMU where this worked, I believe 7.x. In 8.0.3 (likewise running in a Chimera environment, but it was also tested on Alpine, and I had somebody on Arch Linux test it with 8.0.2 just to rule out possible issues caused by a musl-based host environment) it crashes. It only appears to affect the `x86_64` guest architecture, as the other-architecture ISOs have graphical environment come up fine after some minutes (e.g. `ppc64le` with `qemu-system-ppc64 -M pseries-2.11,cap-htm=off -m 2048 -boot d -cdrom chimera-linux-ppc64le-LIVE-20230611-gnome.iso` works just fine). It also appears to only affect TCG emulation, as KVM likewise works fine (same command line, just `-enable-kvm` added).
-
-Apologies for a large testcase, but it seems to need specific graphical-adjacent services to reproduce. It should be consistently reproducible though.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/1808 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/1808
deleted file mode 100644
index c5c9ec950..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_TCG/1808
+++ /dev/null
@@ -1,71 +0,0 @@
-qemu-system-i386: Crash in tcg_handle_interrupt on fpu_raise_exception call
-Description of problem:
-While I was messing with an old Linux system, QEMU crashed as I tried to run `make test` on a package:
-```
-ERROR:../accel/tcg/tcg-accel-ops.c:83:tcg_handle_interrupt: assertion failed: (qemu_mutex_iothread_locked())
-Bail out! ERROR:../accel/tcg/tcg-accel-ops.c:83:tcg_handle_interrupt: assertion failed: (qemu_mutex_iothread_locked())
-```
-Running QEMU straight from the master branch (c167c80) didn't help either. The backtrace is as follows:
-```
-(gdb) bt
-#0  0x00007ffff55ac26c in  () at /usr/lib/libc.so.6
-#1  0x00007ffff555ca08 in raise () at /usr/lib/libc.so.6
-#2  0x00007ffff5545538 in abort () at /usr/lib/libc.so.6
-#3  0x00007ffff6bae05e in g_assertion_message
-    (domain=domain@entry=0x0, file=file@entry=0x555555f90a98 "../accel/tcg/tcg-accel-ops.c", line=line@entry=83, func=func@entry=0x55555607a130 <__func__.3> "tcg_handle_interrupt", message=message@entry=0x7fff9c15ee10 "assertion failed: (qemu_mutex_iothread_locked())") at ../glib/glib/gtestutils.c:3450
-#4  0x00007ffff6c0ef40 in g_assertion_message_expr
-    (domain=domain@entry=0x0, file=file@entry=0x555555f90a98 "../accel/tcg/tcg-accel-ops.c", line=line@entry=83, func=func@entry=0x55555607a130 <__func__.3> "tcg_handle_interrupt", expr=expr@entry=0x555555f79cf8 "qemu_mutex_iothread_locked()") at ../glib/glib/gtestutils.c:3476
-#5  0x0000555555c97369 in tcg_handle_interrupt (cpu=0x555557434cb0, mask=2) at ../accel/tcg/tcg-accel-ops.c:83
-#6  tcg_handle_interrupt (cpu=0x555557434cb0, mask=2) at ../accel/tcg/tcg-accel-ops.c:81
-#7  0x0000555555b4d58b in pic_irq_request (opaque=<optimized out>, irq=<optimized out>, level=1) at ../hw/i386/x86.c:555
-#8  0x0000555555b4f218 in gsi_handler (opaque=0x5555579423d0, n=13, level=1) at ../hw/i386/x86.c:611
-#9  0x00007fffa42bde14 in code_gen_buffer ()
-#10 0x0000555555c724bb in cpu_tb_exec (cpu=cpu@entry=0x555557434cb0, itb=<optimized out>, tb_exit=tb_exit@entry=0x7fffe9bfd658) at ../accel/tcg/cpu-exec.c:457
-#11 0x0000555555c7298e in cpu_loop_exec_tb (tb_exit=0x7fffe9bfd658, last_tb=<synthetic pointer>, pc=3221283547, tb=<optimized out>, cpu=<optimized out>) at ../accel/tcg/cpu-exec.c:919
-#12 cpu_exec_loop (cpu=cpu@entry=0x555557434cb0, sc=sc@entry=0x7fffe9bfd6f0) at ../accel/tcg/cpu-exec.c:1040
-#13 0x0000555555c731dd in cpu_exec_setjmp (cpu=cpu@entry=0x555557434cb0, sc=sc@entry=0x7fffe9bfd6f0) at ../accel/tcg/cpu-exec.c:1057
-#14 0x0000555555c73810 in cpu_exec (cpu=cpu@entry=0x555557434cb0) at ../accel/tcg/cpu-exec.c:1083
-#15 0x0000555555c974ff in tcg_cpus_exec (cpu=cpu@entry=0x555557434cb0) at ../accel/tcg/tcg-accel-ops.c:75
-#16 0x0000555555c97657 in mttcg_cpu_thread_fn (arg=arg@entry=0x555557434cb0) at ../accel/tcg/tcg-accel-ops-mttcg.c:95
-#17 0x0000555555e283e8 in qemu_thread_start (args=0x5555574935f0) at ../util/qemu-thread-posix.c:541
-#18 0x00007ffff55aa44b in  () at /usr/lib/libc.so.6
-#19 0x00007ffff562de40 in  () at /usr/lib/libc.so.6
-```
-
-After further testing, it seems related to inftest.awk. However, the crash doesn't occur right after I run the file, but only when I do specific operations afterwards.
-
-With `-accel kvm`
-```
-> gawk -f test/inftest.awk
-(output trimmed)
-1e+305 1e+302
-1e+308 1e+305
-gawk: test/inftest.awk:3: fatal: floating point exception
-> echo Test # No crash
-Test
-> cat test/inftest.awk # No crash
-```
-
-With `-accel tcg`
-```
-> gawk -f test/inftest.awk
-(output trimmed)
-1e+308 1e+305
-Infinity 1e+308
-Infinity Infinity
-loop terminated
-> echo Test # No crash
-Test
-> cat test/inftest.awk # QEMU crash
-```
-Steps to reproduce:
-1. Start the VM
-2. Press any key except for enter to go through the SVGA prompt
-3. Enter `root` to login. No password is required
-4. Run `cd /usr/src2/gawk-2.14`
-5. Run `gawk -f test/inftest.awk`
-6. Run certain commands that interact with the kernel (ex. `ls`, `cat test/inftest.awk`, `whoami`)
-7. Observe the crash
-Additional information:
-[00000-bootFloppy.raw](/uploads/379f6b601132980af4ea721fe77dbae4/00000-bootFloppy.raw)
-[artifact.qcow2](/uploads/d721a35bc55e764e17087e8bc1a7531e/artifact.qcow2)
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/1826 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/1826
deleted file mode 100644
index 906e535aa..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_TCG/1826
+++ /dev/null
@@ -1,29 +0,0 @@
-Segfault in memory_region_dispatch_write()
-Description of problem:
-Several possible outcomes
-- Kernel freeze and rcu lockup messages.
-- segfault
- 
-For segfault, using gdb.
-```
-in memory_region_dispatch_write (mr=mr@entry=0x130013001300013, addr=addr@entry=176, data=dat@entry=0, op=op@entry=M0_42, attrs=...) at ../../softwmmu/memory.c:1515
-1515     if (mr->alias) {
-
-in memory_region_dispatch_write(  .. as above...)
-in io_writex(env=env@entry=0x555556a84320, full=full@entry=0x7ffda010f630, mmu_idx=mmu_idx@entry=0, val=0, addr=addr@entry=18446744073699049648, retaddr=retaddr@entry=140736023420498, op=MO_32) at ../../accel/tcg/cputlb.c:1448
-in do_st_mmio_leN (env=env@entry=0x555556a84320, full=full@entry=0x7ffda010f630, val_le=<optmized out>, val_le@entry=0, addr=addr@entry=18446744073699049648, size=size@entry=4, mmu_idx=mmu_idx@entry=0, ra=140736023420498) at ../../accel/tcg/cputlb.c:2755
-in do_st_4 (ra=<optmized_out>, memop=<optimized out> mmu_idx=0, val=0, p=0x7ffff529c140, env=0x555556a84320) at ../../accel/tcg/cputbl.c:2921
-do_st4_mmu (env=0x555556a84320, addr=<optimized out> val=<optmized out>, oi=<otpmized out> ra=140736023420498) at ../../accel/tcg/cputlb.c:3006
-in code_gen_buffer()
-in cpu_tb_exec(..) //getting lazy on typing as seems unlikely anything useful beyond here.
-in cpu_loop_exec_tb()
-cpu_exec_loop
-in cpu_exec_setjmp()
-in cpu_exec()
-in tcg_cpus_exec()
-```
-Steps to reproduce:
-1. Boot.
-2. Use gdb to grab back trace after segfault.
-Additional information:
-Seems to segfault mid way through PCI enumeration in the kernel.  Which device seems to vary between runs.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/1832 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/1832
deleted file mode 100644
index bb159c825..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_TCG/1832
+++ /dev/null
@@ -1 +0,0 @@
-i386 test registers are not handled
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/1834 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/1834
deleted file mode 100644
index bfa02c1f0..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_TCG/1834
+++ /dev/null
@@ -1,184 +0,0 @@
-qemu-system-x86_64: ../hw/pci/msix.c:227: msix_table_mmio_write: Assertion `addr + size <= dev->msix_entries_nr * PCI_MSIX_ENTRY_SIZE' failed.
-Description of problem:
-
-Steps to reproduce:
-1. Run qemu using the provided command line
-2. linux kernel boot and qemu crashes at pci bus scan step
-3.
-Additional information:
-```
-SeaBIOS (version rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org
-iPXE (http://ipxe.org) 00:02.0 CA00 PCI2.10 PnP PMM+3EFD0CE0+3EF30CE0 CA00
-iPXE (http://ipxe.org) 00:05.0 CB00 PCI2.10 PnP PMM+3EF1FCE0 3EF30CE0 CB00
-Booting from ROM...
-[    0.000000] Linux version 6.1.38-yocto-standard (oe-user@oe-host) (x86_64-poky-linux-gcc (GCC) 12.3.0, GNU ld (GNU Binutils) 2.40.0.20230620) #1 SMP PREEMPT_DYNAMIC Thu Jul  6 18:52:54 UTC 2023
-[    0.000000] Command line: console=ttyS0
-[    0.000000] x86/fpu: x87 FPU will use FXSAVE
-[    0.000000] signal: max sigframe size: 1040
-[    0.000000] BIOS-provided physical RAM map:
-[    0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009fbff] usable
-[    0.000000] BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff] reserved
-[    0.000000] BIOS-e820: [mem 0x00000000000f0000-0x00000000000fffff] reserved
-[    0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000003ffdefff] usable
-[    0.000000] BIOS-e820: [mem 0x000000003ffdf000-0x000000003fffffff] reserved
-[    0.000000] BIOS-e820: [mem 0x00000000b0000000-0x00000000bfffffff] reserved
-[    0.000000] BIOS-e820: [mem 0x00000000fed1c000-0x00000000fed1ffff] reserved
-[    0.000000] BIOS-e820: [mem 0x00000000fffc0000-0x00000000ffffffff] reserved
-[    0.000000] BIOS-e820: [mem 0x000000fd00000000-0x000000ffffffffff] reserved
-[    0.000000] NX (Execute Disable) protection: active
-[    0.000000] SMBIOS 3.0.0 present.
-[    0.000000] DMI: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014
-[    0.000000] last_pfn = 0x3ffdf max_arch_pfn = 0x400000000
-[    0.000000] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WP  UC- WT
-[    0.000000] found SMP MP-table at [mem 0x000f5b80-0x000f5b8f]
-[    0.000000] ACPI: Early table checksum verification disabled
-[    0.000000] ACPI: RSDP 0x00000000000F59A0 000014 (v00 BOCHS )
-[    0.000000] ACPI: RSDT 0x000000003FFE238A 000038 (v01 BOCHS  BXPC     00000001 BXPC 00000001)
-[    0.000000] ACPI: FACP 0x000000003FFE217A 0000F4 (v03 BOCHS  BXPC     00000001 BXPC 00000001)
-[    0.000000] ACPI: DSDT 0x000000003FFE0040 00213A (v01 BOCHS  BXPC     00000001 BXPC 00000001)
-[    0.000000] ACPI: FACS 0x000000003FFE0000 000040
-[    0.000000] ACPI: APIC 0x000000003FFE226E 000080 (v03 BOCHS  BXPC     00000001 BXPC 00000001)
-[    0.000000] ACPI: FACS 0x000000003FFE0000 000040 
-[    0.000000] ACPI: APIC 0x000000003FFE226E 000080 (v03 BOCHS  BXPC     00000001 BXPC 00000001)
-[    0.000000] ACPI: HPET 0x000000003FFE22EE 000038 (v01 BOCHS  BXPC     00000001 BXPC 00000001)
-[    0.000000] ACPI: MCFG 0x000000003FFE2326 00003C (v01 BOCHS  BXPC     00000001 BXPC 00000001)
-[    0.000000] ACPI: WAET 0x000000003FFE2362 000028 (v01 BOCHS  BXPC     00000001 BXPC 00000001)
-[    0.000000] ACPI: Reserving FACP table memory at [mem 0x3ffe217a-0x3ffe226d]
-[    0.000000] ACPI: Reserving DSDT table memory at [mem 0x3ffe0040-0x3ffe2179]
-[    0.000000] ACPI: Reserving FACS table memory at [mem 0x3ffe0000-0x3ffe003f]
-[    0.000000] ACPI: Reserving APIC table memory at [mem 0x3ffe226e-0x3ffe22ed]
-[    0.000000] ACPI: Reserving HPET table memory at [mem 0x3ffe22ee-0x3ffe2325]
-[    0.000000] ACPI: Reserving MCFG table memory at [mem 0x3ffe2326-0x3ffe2361]
-[    0.000000] ACPI: Reserving WAET table memory at [mem 0x3ffe2362-0x3ffe2389]
-[    0.000000] Zone ranges:
-[    0.000000]   DMA      [mem 0x0000000000001000-0x0000000000ffffff]
-[    0.000000]   DMA32    [mem 0x0000000001000000-0x000000003ffdefff]
-[    0.000000]   Normal   empty
-[    0.000000]   Device   empty
-[    0.000000] Movable zone start for each node
-[    0.000000] Early memory node ranges
-[    0.000000]   node   0: [mem 0x0000000000001000-0x000000000009efff]
-[    0.000000]   node   0: [mem 0x0000000000100000-0x000000003ffdefff]
-[    0.000000] Initmem setup node 0 [mem 0x0000000000001000-0x000000003ffdefff]
-[    0.000000] On node 0, zone DMA: 1 pages in unavailable ranges
-[    0.000000] On node 0, zone DMA: 97 pages in unavailable ranges
-[    0.000000] On node 0, zone DMA32: 33 pages in unavailable ranges
-[    0.000000] ACPI: PM-Timer IO Port: 0x608
-[    0.000000] ACPI: LAPIC_NMI (acpi_id[0xff] dfl dfl lint[0x1])
-[    0.000000] IOAPIC[0]: apic_id 0, version 32, address 0xfec00000, GSI 0-23
-[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
-[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 5 global_irq 5 high level)
-[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
-[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 10 global_irq 10 high level)
-[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 11 global_irq 11 high level)
-[    0.000000] ACPI: Using ACPI (MADT) for SMP configuration information
-[    0.000000] ACPI: HPET id: 0x8086a201 base: 0xfed00000
-[    0.000000] smpboot: Allowing 2 CPUs, 0 hotplug CPUs
-[    0.000000] [mem 0x40000000-0xafffffff] available for PCI devices
-[    0.000000] clocksource: refined-jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
-[    0.000000] setup_percpu: NR_CPUS:8 nr_cpumask_bits:2 nr_cpu_ids:2 nr_node_ids:1
-[    0.000000] percpu: Embedded 52 pages/cpu s173288 r8192 d31512 u1048576
-[    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 257759
-[    0.000000] Kernel command line: console=ttyS0
-[    0.000000] Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes, linear)
-[    0.000000] Inode-cache hash table entries: 65536 (order: 7, 524288 bytes, linear)
-[    0.000000] mem auto-init: stack:all(zero), heap alloc:off, heap free:off
-[    0.000000] Memory: 1002116K/1048052K available (12294K kernel code, 1469K rwdata, 2600K rodata, 1488K init, 2040K bss, 45680K reserved, 0K cma-reserved)
-[    0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
-[    0.000000] ftrace: allocating 31276 entries in 123 pages
-[    0.000000] ftrace: allocated 123 pages with 6 groups
-[    0.000000] ftrace: allocating 31276 entries in 123 pages
-[    0.000000] ftrace: allocated 123 pages with 6 groups
-[    0.000000] Dynamic Preempt: none
-[    0.000000] rcu: Preemptible hierarchical RCU implementation.
-[    0.000000] rcu:     RCU event tracing is enabled.
-[    0.000000] rcu:     RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=2.
-[    0.000000]  Trampoline variant of Tasks RCU enabled.
-[    0.000000]  Rude variant of Tasks RCU enabled.
-[    0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 10 jiffies.
-[    0.000000] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=2
-[    0.000000] NR_IRQS: 4352, nr_irqs: 440, preallocated irqs: 16
-[    0.000000] rcu: srcu_init: Setting srcu_struct sizes based on contention.
-[    0.000000] Console: colour VGA+ 80x25
-[    0.000000] printk: console [ttyS0] enabled
-[    0.000000] ACPI: Core revision 20220331
-[    0.000000] clocksource: hpet: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604467 ns
-[    0.020000] APIC: Switch to symmetric I/O mode setup
-[    0.040000] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
-[    0.120000] tsc: Unable to calibrate against PIT
-[    0.120000] tsc: using HPET reference calibration
-[    0.120000] tsc: Detected 2299.960 MHz processor
-[    0.001362] tsc: Marking TSC unstable due to TSCs unsynchronized
-[    0.002851] Calibrating delay loop (skipped), value calculated using timer frequency.. 4599.92 BogoMIPS (lpj=22999600)
-[    0.004441] pid_max: default: 32768 minimum: 301
-[    0.019780] Mount-cache hash table entries: 2048 (order: 2, 16384 bytes, linear)
-[    0.020332] Mountpoint-cache hash table entries: 2048 (order: 2, 16384 bytes, linear)
-[    0.078474] process: using AMD E400 aware idle routine
-[    0.079221] Last level iTLB entries: 4KB 512, 2MB 255, 4MB 127
-[    0.079631] Last level dTLB entries: 4KB 512, 2MB 255, 4MB 127, 1GB 0
-[    0.081092] Spectre V1 : Mitigation: usercopy/swapgs barriers and __user pointer sanitization
-[    0.082698] Spectre V2 : Mitigation: Retpolines
-[    0.083053] Spectre V2 : Spectre v2 / SpectreRSB mitigation: Filling RSB on context switch
-[    0.083616] Spectre V2 : Spectre v2 / SpectreRSB : Filling RSB on VMEXIT
-[    0.348864] Freeing SMP alternatives memory: 32K
-[    0.514732] smpboot: CPU0: AMD QEMU Virtual CPU version 2.5+ (family: 0xf, model: 0x6b, stepping: 0x1)
-[    0.536546] cblist_init_generic: Setting adjustable number of callback queues.
-[    0.537604] cblist_init_generic: Setting shift to 1 and lim to 1.
-[    0.538995] cblist_init_generic: Setting shift to 1 and lim to 1.
-[    0.541338] Performance Events: PMU not available due to virtualization, using software events only.
-[    0.548504] rcu: Hierarchical SRCU implementation.
-[    0.548986] rcu:     Max phase no-delay instances is 1000.
-[    0.563842] smp: Bringing up secondary CPUs ...
-[    0.583950] x86: Booting SMP configuration:
-[    0.584395] .... node  #0, CPUs:      #1
-[    0.802667] smp: Brought up 1 node, 2 CPUs
-[    0.803300] smpboot: Max logical packages: 1
-[    0.803821] smpboot: Total of 2 processors activated (9202.49 BogoMIPS)
-[    0.864556] devtmpfs: initialized
-[    0.897545] x86/mm: Memory block size: 128MB
-[    0.936982] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
-[    0.938878] futex hash table entries: 512 (order: 3, 32768 bytes, linear)
-[    0.980994] NET: Registered PF_NETLINK/PF_ROUTE protocol family
-[    1.004001] thermal_sys: Registered thermal governor 'step_wise'
-[    1.004143] thermal_sys: Registered thermal governor 'user_space'
-[    1.009528] cpuidle: using governor menu
-[    1.022723] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
-[    1.043717] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xb0000000-0xbfffffff] (base 0xb0000000)
-[    1.050546] PCI: MMCONFIG at [mem 0xb0000000-0xbfffffff] reserved in E820
-[    1.060576] PCI: Using configuration type 1 for base access
-[    1.074215] mtrr: your CPUs had inconsistent fixed MTRR settings
-[    1.075157] mtrr: your CPUs had inconsistent variable MTRR settings
-[    1.076043] mtrr: your CPUs had inconsistent MTRRdefType settings
-[    1.076840] mtrr: probably your BIOS does not setup all CPUs.
-[    1.077612] mtrr: corrected configuration.
-[    1.453630] HugeTLB: registered 2.00 MiB page size, pre-allocated 0 pages
-[    1.454286] HugeTLB: 28 KiB vmemmap can be freed for a 2.00 MiB page
-[    1.467152] raid6: skipped pq benchmark and selected sse2x4
-[    1.467152] raid6: using intx1 recovery algorithm
-[    1.485004] ACPI: Added _OSI(Module Device)
-[    1.485539] ACPI: Added _OSI(Processor Device)
-[    1.485909] ACPI: Added _OSI(3.0 _SCP Extensions)
-[    1.486309] ACPI: Added _OSI(Processor Aggregator Device)
-[    1.578101] ACPI: 1 ACPI AML tables successfully acquired and loaded
-[    1.670966] ACPI: Interpreter enabled
-[    1.676848] ACPI: PM: (supports S0 S3 S5)
-[    1.677404] ACPI: Using IOAPIC for interrupt routing
-[    1.683268] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
-[    1.684107] PCI: Using E820 reservations for host bridge windows
-[    1.691382] ACPI: Enabled 2 GPEs in block 00 to 3F
-[    1.828171] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
-[    1.831923] acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI EDR HPX-Type3]
-[    1.839401] acpi PNP0A08:00: _OSC: platform does not support [PCIeHotplug LTR DPC]
-[    1.843631] acpi PNP0A08:00: _OSC: OS now controls [SHPCHotplug PME AER PCIeCapability]
-[    1.867627] PCI host bridge to bus 0000:00
-[    1.868866] pci_bus 0000:00: root bus resource [io  0x0000-0x0cf7 window]
-[    1.870044] pci_bus 0000:00: root bus resource [io  0x0d00-0xffff window]
-[    1.870572] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff window]
-[    1.871151] pci_bus 0000:00: root bus resource [mem 0x40000000-0xafffffff window]
-[    1.871719] pci_bus 0000:00: root bus resource [mem 0xc0000000-0xfebfffff window]
-[    1.872269] pci_bus 0000:00: root bus resource [mem 0x100000000-0x8ffffffff window]
-[    1.873668] pci_bus 0000:00: root bus resource [bus 00-ff]
-[    1.880983] pci 0000:00:00.0: [8086:29c0] type 00 class 0x060000
-[    1.898659] pci 0000:00:01.0: [1234:1111] type 00 class 0x030000
-qemu-system-x86_64: ../hw/pci/msix.c:227: msix_table_mmio_write: Assertion `addr + size <= dev->msix_entries_nr * PCI_MSIX_ENTRY_SIZE' failed.
-```
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/184 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/184
deleted file mode 100644
index bacc2f12c..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_TCG/184
+++ /dev/null
@@ -1 +0,0 @@
-SSE CMP ops with 8bit immediate throw sigill with oversized byte
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/1864 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/1864
deleted file mode 100644
index eb381d11c..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_TCG/1864
+++ /dev/null
@@ -1,21 +0,0 @@
-x86 VM with TCG and SMP fails to start on 8.1.0
-Description of problem:
-I'm running Colima on MacOS to run Docker. After upgrading qemu to 8.1.0 my x86_64 VM fails to start. If I downgrade qemu to 8.0.4 everything runs normally. Relevant logs:
-
-```
-[   60.976187] rcu: 	0-...!: (0 ticks this GP) idle=0d58/0/0x0 softirq=44/44 fqs=0 (false positive?)
-[   60.979262] 	(detected by 1, t=6005 jiffies, g=-1171, q=1981 ncpus=2)
-[   60.982317] Sending NMI from CPU 1 to CPUs 0:
-[   11.583693] NMI backtrace for cpu 0 skipped: idling at native_safe_halt+0xb/0x10
-[   11.583693] INFO: NMI handler (nmi_cpu_backtrace_handler) took too long to run: 2.006 msecs
-[   60.982317] rcu: rcu_preempt kthread timer wakeup didn't happen for 6004 jiffies! g-1171 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402
-[   60.982317] rcu: 	Possible timer handling issue on cpu=0 timer-softirq=15
-[   60.982317] rcu: rcu_preempt kthread starved for 6005 jiffies! g-1171 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402 ->cpu=0
-[   60.982317] rcu: 	Unless rcu_preempt kthread gets sufficient CPU time, OOM is now expected behavior.
-[   60.982317] rcu: RCU grace-period kthread stack dump:
-[   60.982317] task:rcu_preempt     state:I stack:0     pid:15    ppid:2      flags:0x00004000
-```
-
-[serial.log](/uploads/1039eceff37133504eb93401df1db137/serial.log)
-Steps to reproduce:
-1. `colima start --arch x86_64`
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/1964 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/1964
deleted file mode 100644
index 35aaed915..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_TCG/1964
+++ /dev/null
@@ -1,7 +0,0 @@
-QEMU TCG faulted in RUNDLL32 at Windows 98SE Display Properties
-Description of problem:
-QEMU TCG faulted in RUNDLL32 at Windows 98SE Display Properties. 100% consistently reproducible across multiple host operating systems and CPU architectures and all types of QEMU emulated display controllers supported by Windows 98SE (`VGA, cirrus-vga and vmware-svga`). It is a user-mode fault so the OS simply terminated the faulting process, OS remains fully functional after the fault and the same fault can be repeated. Should be extremely helpful in debugging. Last known good QEMU version without this bug is 7.1.0. For x86_64, KVM and WHPX do not have the issue and can be used to gain access to Display Properties. On AArch64, last known good QEMU version is the only way to gain access to Display Properties.
-Steps to reproduce:
-See attached recorded video.
-
-![Screen_Recording_2023-10-27_at_2.44.18_AM](/uploads/0b8cff9b70606532312593d48b7df79a/Screen_Recording_2023-10-27_at_2.44.18_AM.mov)
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/2022 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/2022
deleted file mode 100644
index ea35fbbd2..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_TCG/2022
+++ /dev/null
@@ -1,11 +0,0 @@
-Win32s crashes qemu (regression, bisected)
-Description of problem:
-Whenever I start a Win32s application (FREECELL.EXE), qemu says "qemu: Bad ram pointer 0x7f4b13a80000" and aborts. I tried a few different versions of Win32s (I specifically remember 1.15a and 1.25a), but it does not seem to matter. I am using only the standard VGA driver and nothing else that would not be present in a standard install of the guest components.
-Steps to reproduce:
-1. Run any Win32s application
-2.
-3.
-Additional information:
-It worked fine before this commit, both on stable-8.1 as well as the master branch:
-
-4f8f41272e accel: Replace target_ulong with vaddr in probe_*()
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/2040 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/2040
deleted file mode 100644
index 1b3e8b6c9..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_TCG/2040
+++ /dev/null
@@ -1,24 +0,0 @@
-x86 TCG incorrectly truncates physical addresses to 32 bits when PAE is enabled
-Description of problem:
-Originally observed as 32-bit Windows failing to boot on systems with RAM above 4G when using TCG (but working fine under KVM).  Windows kernel debugger showed the kernel allocating a block of memory but somehow failing to create a page table mapping for it.
-
-Bisection in QEMU produced the first bad commit as 4a1e9d4 ("target/i386: Use atomic operations for pte updates"), which changed the PTE accessing code from using e.g. `x86_ldq_phys()` to using `probe_access_full()` and `ldq_p()`.
-
-Further deconstruction of the changes in this commit found that at some point during the boot, the value obtained from `ldq_p()` was completely different to the value obtained from `x86_ldq_phys()`.  Debugging revealed that the underlying host addresses used by each method were exactly 4G apart, with the new method (`ldq_p()`) accessing a host location 4G below the correct address.
-
-Inspection of the code revealed one place where addresses are truncated to 32 bits, which would cause this 4G offset: in `get_physical_address()` we have the code:
-
-```
-    if (!(env->hflags & HF_LMA_MASK)) {
-        /* Without long mode we can only address 32bits in real mode */
-        out->paddr = (uint32_t)out->paddr;
-    }
-```
-
-This looks wrong, since PAE allows for physical addresses above 4G to be accessed without long mode.  (This is the whole point of PAE.)
-
-A quick experiment shows that commenting out the above block of code fixes the symptom and allows Windows 10 to boot with RAM above 4G.
-
-I suspect that the test should be checking for PAE being enabled rather than long mode being enabled.  (Enabling PAE is part of setting up the CPU for long mode, so it is impossible to be in long mode without PAE already enabled.)
-Steps to reproduce:
-Run the command given above.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/2092 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/2092
deleted file mode 100644
index 5e891e4da..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_TCG/2092
+++ /dev/null
@@ -1,70 +0,0 @@
-i386: TCG + virtiofs fails to boot Fedora/CentOS/OpenSUSE since QEMU v7.2
-Description of problem:
-When booting from virtiofs with TCG acceleration, after switch root from initramfs to rootfs, the system crashes horribly, see logs below. The failures only happen when TCG acceleration is used with a virtiofs rootfs. Switching TCG for KVM acceleration or virtiofs for a disk image makes the issue disappear. This has started happening since QEMU version 7.2. Using any qemu version before QEMU version 7.2 works fine. Additionally, it only seems to happen with CentOS Stream, Fedora and OpenSUSE. Using Debian, Ubuntu or Arch Linux, this combination boots fine.
-
-cc @bonzini since you made quite a few changes to TCG acceleration in QEMU v7.2.
-Steps to reproduce:
-1. `git clone https://github.com/systemd/mkosi`
-2. `cd mkosi`
-3. `bin/mkosi -d fedora -t directory --tools-tree=default --qemu-kvm=no --debug qemu` (this will build an image first so will take a while. Depending on your distribution you might need to install `dnf` and `bubblewrap`)
-Additional information:
-```
-<initramfs boot logs skipped for brevity>
-Welcome to Fedora Linux 39 (Thirty Nine)!
-
-[   37.137287] systemd[1]: Initializing machine ID from random generator.
-[   37.209193] kauditd_printk_skb: 9 callbacks suppressed
-[   37.209227] audit: type=1334 audit(1704961693.242:45): prog-id=16 op=LOAD
-[   37.210718] audit: type=1334 audit(1704961693.243:46): prog-id=16 op=UNLOAD
-[   37.211491] audit: type=1334 audit(1704961693.244:47): prog-id=17 op=LOAD
-[   37.212766] audit: type=1334 audit(1704961693.245:48): prog-id=17 op=UNLOAD
-[   37.241136] audit: type=1334 audit(1704961693.274:49): prog-id=18 op=LOAD
-[   37.242803] audit: type=1334 audit(1704961693.275:50): prog-id=18 op=UNLOAD
-[   37.244114] audit: type=1334 audit(1704961693.277:51): prog-id=19 op=LOAD
-[   37.245790] audit: type=1334 audit(1704961693.278:52): prog-id=19 op=UNLOAD
-[   37.259849] audit: type=1334 audit(1704961693.291:53): prog-id=20 op=LOAD
-[   37.260072] audit: type=1334 audit(1704961693.292:54): prog-id=20 op=UNLOAD
-[   37.870091] systemd[1]: bpf-lsm: BPF LSM hook not enabled in the kernel, BPF LSM not supported
-[   38.074465] Process 299(false) has RLIMIT_CORE set to 1
-[   38.074793] Aborting core
-[   38.077885] Process 297(false) has RLIMIT_CORE set to 1
-[   38.078066] Aborting core
-[   38.079360] Process 298(false) has RLIMIT_CORE set to 1
-[   38.079516] Aborting core
-[   38.114888] Process 301(false) has RLIMIT_CORE set to 1
-[   38.115072] Aborting core
-[   38.217830] Process 305(false) has RLIMIT_CORE set to 1
-[   38.218038] Aborting core
-[   38.219161] Process 304(false) has RLIMIT_CORE set to 1
-[   38.219337] Aborting core
-[   38.287937] Process 308(false) has RLIMIT_CORE set to 1
-[   38.288169] Aborting core
-[   38.323829] Process 309(false) has RLIMIT_CORE set to 1
-[   38.324045] Aborting core
-[   38.325457] Process 310(false) has RLIMIT_CORE set to 1
-[   38.325811] Aborting core
-[   38.447773] Process 315(false) has RLIMIT_CORE set to 1
-[   38.447934] Aborting core
-[   38.449525] Process 314(false) has RLIMIT_CORE set to 1
-[   38.449768] Aborting core
-[   38.462210] (sd-execu[291]: /usr/lib/systemd/system-generators/systemd-integritysetup-generator terminated by signal SEGV.
-[   38.478826] Process 316(false) has RLIMIT_CORE set to 1
-[   38.479001] Aborting core
-[   42.397416] systemd[1]: Populated /etc with preset unit settings.
-[   42.532156] show_signal_msg: 68 callbacks suppressed
-[   42.535164] systemd[1]: segfault at b0 ip 00007f3ca95074ed sp 00007ffc7aa5f1c0 error 4 in libsystemd-core-254.7-1.fc39.so[7f3ca944c000+135000] likely on CPU 0 (core 0, socket 0)
-[   42.536289] Code: 00 48 89 fb 75 6f c6 87 88 04 00 00 01 48 8b 7f 70 45 31 ed 48 85 ff 75 1e e9 7f 00 00 00 0f 1f 80 00 00 00 00 e8 f3 24 f5 ff <48> 8b 7b 70 41 83 c5 01 48 85 ff 74 66 f6 87 63 04 00 00 01 75 e5
-[   42.543019] systemd[1]: Caught <SEGV> from PID 176.
-[   42.543516] audit: type=1701 audit(1704961698.576:99): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=317 comm="systemd" exe="/usr/lib/systemd/systemd" sig=11 res=1
-[   42.593878] traps: false[318] general protection fault ip:7fcccd942fa0 sp:7ffd528a8020 error:0 in libc.so.6[7fcccd928000+160000]
-[   42.594494] Process 318(false) has RLIMIT_CORE set to 1
-[   42.594831] Aborting core
-[   42.595808] audit: type=1701 audit(1704961698.627:100): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=318 comm="false" exe="/usr/bin/false" sig=11 res=1
-[   42.603224] systemd[1]: Caught <SEGV>, dumped core as pid 317.
-[   42.604202] systemd[1]: Freezing execution.
-[   42.656248] audit: type=1335 audit(1704961698.689:101): pid=1 uid=0 auid=4294967295 tty=(none) ses=4294967295 comm="systemd" exe="/usr/lib/systemd/systemd" nl-mcgrp=1 op=disconnect res=1
-[   42.657685] audit: type=1334 audit(1704961698.690:102): prog-id=14 op=UNLOAD
-[   42.657852] audit: type=1334 audit(1704961698.690:103): prog-id=15 op=UNLOAD
-[   42.658011] audit: type=1334 audit(1704961698.690:104): prog-id=11 op=UNLOAD
-[   42.658201] audit: type=1334 audit(1704961698.690:105): prog-id=12 op=UNLOAD
-```
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/2096 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/2096
deleted file mode 100644
index c0f7c1f24..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_TCG/2096
+++ /dev/null
@@ -1 +0,0 @@
-test-x86-cpuid-compat qtest produces warnings on TCG
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/215 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/215
deleted file mode 100644
index 78dee6788..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_TCG/215
+++ /dev/null
@@ -1 +0,0 @@
-x86 Floating point exceptions - incorrect support?
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/2170 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/2170
deleted file mode 100644
index 4ad38a0ff..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_TCG/2170
+++ /dev/null
@@ -1,44 +0,0 @@
-qemu-x86_64 crashes when the application calls pthread_getattr_np()
-Description of problem:
-QEMU user emulation crashes with this program:
-```
-#define _GNU_SOURCE
-#include <stdio.h>
-#include <pthread.h>
-
-int main()
-{
-        pthread_attr_t attr;
-        int error = pthread_getattr_np(pthread_self(), &attr);
-
-        printf("%d\n", error);
-        return 0;
-}
-```
-Steps to reproduce:
-1. Compile the program above
-2. Run QEMU
-Additional information:
-QEMU crashes with:
-```
-qemu-x86_64: QEMU internal SIGSEGV {code=MAPERR, addr=0x20}
-Segmentation fault (core dumped)
-
-```
-
-In gdb I get this backtrace:
-```
-#0  0x0000555555627d6d in open_self_maps_2 (opaque=0x7fffffffc020, guest_start=18446744073699065856, guest_end=<optimized out>, flags=12) at ../linux-user/syscall.c:8089
-#1  0x000055555560ce67 in walk_memory_regions (priv=priv@entry=0x7fffffffc020, fn=fn@entry=0x555555627d30 <open_self_maps_2>) at ../accel/tcg/user-exec.c:176
-#2  0x0000555555628b3a in open_self_maps_1 (smaps=<optimized out>, fd=<optimized out>, env=<optimized out>) at ../linux-user/syscall.c:8112
-#3  open_self_maps (cpu_env=<optimized out>, fd=3) at ../linux-user/syscall.c:8122
-#4  0x0000555555631e24 in do_guest_openat (cpu_env=cpu_env@entry=0x55555583ae20, dirfd=dirfd@entry=-100, fname=fname@entry=0x2aaaab496eb4 "/proc/self/maps", flags=524288, mode=mode@entry=0, safe=safe@entry=true) at ../linux-user/syscall.c:8381
-#5  0x0000555555638f71 in do_syscall1 (cpu_env=cpu_env@entry=0x55555583ae20, num=num@entry=257, arg1=arg1@entry=4294967196, arg2=arg2@entry=46912506523316, arg3=arg3@entry=524288, arg4=arg4@entry=0, arg5=<optimized out>, arg6=<optimized out>, arg8=0, arg7=0) at ../linux-user/syscall.c:9075
-#6  0x000055555563b659 in do_syscall (cpu_env=cpu_env@entry=0x55555583ae20, num=257, arg1=4294967196, arg2=46912506523316, arg3=524288, arg4=0, arg5=8, arg6=1, arg7=0, arg8=0) at ../linux-user/syscall.c:13658
-#7  0x000055555558db19 in cpu_loop (env=env@entry=0x55555583ae20) at ../linux-user/x86_64/../i386/cpu_loop.c:242
-#8  0x00005555555898d8 in main (argc=<optimized out>, argv=0x7fffffffdd38, envp=<optimized out>) at ../linux-user/main.c:1012
-
-```
-
-This bug was introduced in the rewrite of `open_self_maps` in 7b7a3366e142d3baeb3fd1d3660a50e7956c19eb.
-The current master (5767815218efd3cbfd409505ed824d5f356044ae) is still affected.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/2175 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/2175
deleted file mode 100644
index a5c9ec5e7..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_TCG/2175
+++ /dev/null
@@ -1,38 +0,0 @@
-Intel BLSI CF computation bug
-Description of problem:
-CF flag computation of BLSI instruction is wrong. It seems #1370 was not completely fixed.
-Steps to reproduce:
-1. Compile `example.c` using this command: `gcc -o example.bin example.c`. My gcc version is 12.3.0, but other versions may work.
-```
-int main() {
-  __asm__ (
-    "movq $0x1, %r8\n"
-    "mov $0xedbf530a, %r9\n"
-    "push $0x1\n"
-    "popf\n"
-    "blsi %r9d, %r8d\n"
-    "pushf\n"
-    "pop %rax\n"
-    "pop %rbp\n"
-    "ret\n"
-  );
-
-  return 0;
-}
-```
-2. Run `./example.bin`. Then check the return code using `echo $?`. It should be 3.
-```
-$ ./example.bin
-$ echo $?
-3
-```
-3. Run `./qemu-x86_64 ./example.bin`. Then check the return code using `echo $?`. It should be 2.
-```
-$ ./qemu-x86_64 ./example.bin
-$ echo $?
-2
-```
-
-The return code of `./example.bin` contains the value of the `RFLAGS` register after executing the `BLSI` instruction.
-Additional information:
-
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/2180 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/2180
deleted file mode 100644
index 7596ba7d8..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_TCG/2180
+++ /dev/null
@@ -1,36 +0,0 @@
-QEMU crashes when an interrupt is triggered whose descriptor is not in physical memory
-Description of problem:
-When an interrupt is triggered whose descriptor is mapped but not in physical memory, QEMU crashes with the following message:
-```
-**
-ERROR:../system/cpus.c:524:bql_lock_impl: assertion failed: (!bql_locked())
-Bail out! ERROR:../system/cpus.c:524:bql_lock_impl: assertion failed: (!bql_locked())
-Aborted (core dumped)
-```
-
-The given code triggers the bug by moving the IDT's base address, but it can also be triggered by any other method of moving the IDT's physical memory location, f.ex paging. With KVM enabled, this specific example loops forever instead of crashing, but if the code is altered to use paging, an internal KVM error is reported and the VM is paused.
-Steps to reproduce:
-1. Assemble the code listed below using NASM: `nasm test.asm -o test.bin`
-2. Run the code using `qemu-system-i386 -drive format=raw,file=test.bin`. Note that the given code only triggers the bug if the guest has 2 gigabytes or less of physical memory.
-3. QEMU crashes.
-Additional information:
-NASM assembly of the code used:
-```
-bits 16
-org 0x7c00
-
-_start:
-    ; Disable interrupts and load new IDT
-    cli
-    o32 lidt [idtdesc]
-    ; Descriptor for INT 0 is in nonexistent physical memory, which crashes QEMU.
-    int 0x00
-
-idtdesc:
-    dw 0x3ff      ; Limit: 1 KiB for IDT
-    dd 0x80000000 ; Base: 2 GiB
-
-; Like most BIOSes, SeaBIOS requires this magic number to boot
-times 510-($-$$) db 0
-dw 0xaa55
-```
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/2195 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/2195
deleted file mode 100644
index ffcc3d9d6..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_TCG/2195
+++ /dev/null
@@ -1,39 +0,0 @@
-qemu-system-x86_64 : cannot resume from S3 suspend for Q35 + OVMF
-Description of problem:
-There is a specific configuration where the resume from S3 does not work:
-
-- Q35 machine + OVMF.fd (https://retrage.github.io/edk2-nightly/)
-- TCG acceleration (it works when --accel=kvm is set)
-
-The output at resume is:
-
-```
-!!!! X64 Exception Type - 05(#BR - BOUND Range Exceeded)  CPU Apic ID - 00000000 !!!!
-RIP  - 0000000000006237, CS  - 0000000000000028, RFLAGS - 0000000000000002
-RAX  - 0000000080000027, RCX - 0000000000000000, RDX - 0000000000000000
-RBX  - 0000000099200000, RSP - 000000000FF96236, RBP - 000000000FF96320
-RSI  - 000000000F74E000, RDI - 0000000000833F31
-R8   - 0000002800000000, R9  - 0000000000000000, R10 - 000000000FF968F0
-R11  - 0000000000828B30, R12 - 000000000FF9ACD0, R13 - 000000000F76B000
-R14  - 000000000F76A000, R15 - 0000000000000000
-DS   - 0000000000000030, ES  - 0000000000000030, FS  - 0000000000000030
-GS   - 0000000000000030, SS  - 0000000000000030
-CR0  - 0000000080000033, CR2 - 0000000000000000, CR3 - 000000000F75B000
-CR4  - 0000000000000668, CR8 - 0000000000000000
-DR0  - 0000000000000000, DR1 - 0000000000000000, DR2 - 0000000000000000
-DR3  - 0000000000000000, DR6 - 00000000FFFF0FF0, DR7 - 0000000000000400
-GDTR - 0000000000833DE0 0000000000000047, LDTR - 0000000000000000
-IDTR - 000000000FF97D70 000000000000021F,   TR - 0000000000000000
-FXSAVE_STATE - 000000000FF95E90
-!!!! Can't find image information. !!!!
-```
-
-After bisecting, this is caused by commit : 18a536f1f8d6222e562f59179e837fdfd8b92718 If i revert this comment, the resume works nicely.
-
-I used a script to generate a tiny initrd to test but i think the problem can be reproduced with any guest kernel + rootfs. I also verify that this problem can be reproduced with different host kernels (6.5) than the one i used (6.8)
-Steps to reproduce:
-1. Use https://gitlab.com/berrange/tiny-vm-tools/-/blob/master/make-tiny-image.py to generate tiny-initrd.img
-2. Run qemu and drop into shell
-3. Put machine into S3 (echo mem \> /sys/power/state)
-4. Use socat to connect to QEMU monitor and wake up the machine (system_wakeup)
-5. The machine does not resume correctly
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/2198 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/2198
deleted file mode 100644
index 92b007105..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_TCG/2198
+++ /dev/null
@@ -1,25 +0,0 @@
-Unable to run OS/2 Warp4.52
-Description of problem:
-Operating system crashes upon boot.
-Steps to reproduce:
-1. Install OS/2 Warp4
-2. Apply Fixpack15
-3. Try to boot the system
-Additional information:
-This is a very old bug that seems to render a whole family of Operating Systems (OS/2 Warp4 and eComStation) unusable under Qemu.
-Warp4 works, in the sense that it does install and run, but just until it is updated to 4.52 (which is necessary to get a useable guest)
-
-I found traces of its existence as far as:
-https://bugs.launchpad.net/qemu/+bug/1743441
-https://lists.gnu.org/archive/html/qemu-devel/2019-02/msg02337.html
-
-And i found the issue brieffly commented at https://www.os2world.com/forum/index.php?topic=2346.0
-I quote: 
- 
-'Regarding QEMU/KVM, OS/2 runs in QEMU mostly fine. Except the trap in os2lvm.dmd and non-working netbeui.os2 and
-tcpbeui.os2. The problem with os2lvm.dmd is because QEMU closely follows the intel spec, which is incorrect. The spec says
-that 16-bit SGDT instruction behaves the same like in i286 processor. But it's not true, it behaves like i386 instruction. So, QEMU
-emulates SGDT 16-bit instruction incorrectly. OS2LVM.DMD uses 16-bit SGDT instruction and it hits the problem.'
-
-After a brief discussion on the Warp4 group at groups.io where I was told that this is indeed a Qemu bug, I thought someone has 
-to report on that.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/2206 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/2206
deleted file mode 100644
index 5d2803a04..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_TCG/2206
+++ /dev/null
@@ -1,10 +0,0 @@
-PAGE_FAULT_IN_NONPAGED_AREA in Windows 7 x64.
-Description of problem:
-When trying to install Windows 7, it always crashes with PAGE_FAULT_IN_NONPAGED_AREA. This also impacts Windows 8.1, but crashes when it tries to start up the installation disc.
-Steps to reproduce:
-1. Create A VM with the Windows 7 installation disc inside the cdrom.
-2. Go through the installation
-3. At some point, it will pull a blue screen with a PAGE_FAULT_IN_NONPAGED_AREA. (around expanding windows files or completing installation)
-Additional information:
-It looks like this bsod is relating to some non-canonical (illegal) virtual address being referenced. (It's just my guess based on the stop code)
-![image](/uploads/910a863461a99713ff8566e5c2212ce2/image.png)
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/2207 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/2207
deleted file mode 100644
index be799c2ed..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_TCG/2207
+++ /dev/null
@@ -1,11 +0,0 @@
-WerFault.exe – Application Error. The memory could not be read in Win7 i386
-Description of problem:
-WerFault Application Errors always occur when I open IE or even control panel. It's OK on QEMU 7.2 & 8.0 version according to my debug experience about qemu-system-i386 flavor in the last few months.
-Steps to reproduce:
-1. pulling _tag: v8.2.0_ code 
-2. emulating Windows 7 OS on aarch64 Host with TCG acceleration mechanism
-3. just opening IE for maybe two or three times after the virtual machine has started
-Additional information:
-The error is displayed by Chinese. It says _WerFault.exe – Application Error. The instruction at 0x779f77b2 referenced memory at 0x6d0f6d20. The memory could not be read._ in English
-
-![20240305141310](https://juststayrealpicgo.oss-cn-hangzhou.aliyuncs.com/wiz/20240305141310.png)
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/2220 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/2220
deleted file mode 100644
index b6e1816be..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_TCG/2220
+++ /dev/null
@@ -1,528 +0,0 @@
-Intermittent QEMU segfaults on x86_64 with TCG accelerator
-Description of problem:
-Recently(-ish) in our upstream systemd CI we started seeing an uptrend of QEMU segfaults when running our integration tests. This was first observed in CentOS Stream 9 runs, but was later followed by Fedora Rawhide and Ubuntu Noble, once they picked up the QEMU 8.x branch. I filed a RHEL-only ticked first (before we started seeing it on other distros as well), so I'll share the same information here as well.
-
-This seems to happen only with TCG - in the CentOS CI infrastructure, where this was first observed, we run two jobs - one on a baremetal, that runs the test VMs with KVM, and one already on VMs that runs the same jobs using TCG; only the TCG job suffer from this issue. The same goes for the Fedora Rawhide and Ubuntu Noble jobs - they also use TCG.
-
-I managed to get a stack trace from one of the segmentation faults on CentOS Stream 9:
-```gdb
-[coredumpctl_collect] Collecting coredumps for '/usr/libexec/qemu-kvm'
-           PID: 1154719 (qemu-system-x86)
-           UID: 0 (root)
-           GID: 0 (root)
-        Signal: 11 (SEGV)
-     Timestamp: Thu 2024-02-01 21:50:04 UTC (1min 23s ago)
-  Command Line: /bin/qemu-system-x86_64 -smp 8 -net none -m 768M -nographic -kernel /boot/vmlinuz-5.14.0-412.el9.x86_64 -drive format=raw,cache=unsafe,file=/var/tmp/systemd-test-TEST-63-PATH_1/default.img -device virtio-rng-pci,max-bytes=1024,period=1000 -cpu max -initrd /var/tmp/ci-initramfs-5.14.0-412.el9.x86_64.img -append $'root=LABEL=systemd_boot rw raid=noautodetect rd.luks=0 loglevel=2 init=/usr/lib/systemd/systemd console=ttyS0 SYSTEMD_UNIT_PATH=/usr/lib/systemd/tests/testdata/testsuite-63.units:/usr/lib/systemd/tests/testdata/units: systemd.unit=testsuite.target systemd.wants=testsuite-63.service noresume oops=panic panic=1 softlockup_panic=1 systemd.wants=end.service enforcing=0 watchdog_thresh=60 workqueue.watchdog_thresh=120'
-    Executable: /usr/libexec/qemu-kvm
- Control Group: /user.slice/user-0.slice/session-1.scope
-          Unit: session-1.scope
-         Slice: user-0.slice
-       Session: 1
-     Owner UID: 0 (root)
-       Boot ID: 011f8fd0783c464184955c281ce2c1b7
-    Machine ID: af8d424897a0479fa2fc0e5afcff3198
-      Hostname: n27-39-6.pool.ci.centos.org
-       Storage: /var/lib/systemd/coredump/core.qemu-system-x86.0.011f8fd0783c464184955c281ce2c1b7.1154719.1706824204000000.zst (present)
-  Size on Disk: 124.7M
-       Message: Process 1154719 (qemu-system-x86) of user 0 dumped core.
-                
-                Stack trace of thread 1154728:
-                #0  0x0000557669385a13 address_space_translate_for_iotlb (qemu-kvm + 0x73ba13)
-                #1  0x00005576693d149f tlb_set_page_full (qemu-kvm + 0x78749f)
-                #2  0x0000557669248a18 x86_cpu_tlb_fill (qemu-kvm + 0x5fea18)
-                #3  0x00005576693db519 mmu_lookup1 (qemu-kvm + 0x791519)
-                #4  0x00005576693db31b mmu_lookup.llvm.5973256065011438912 (qemu-kvm + 0x79131b)
-                #5  0x00005576693d3173 do_ld4_mmu.llvm.5973256065011438912 (qemu-kvm + 0x789173)
-                #6  0x00005576692d44cf do_interrupt_all (qemu-kvm + 0x68a4cf)
-                #7  0x000055766924f605 x86_cpu_exec_interrupt (qemu-kvm + 0x605605)
-                #8  0x00005576693bdc25 cpu_exec_loop (qemu-kvm + 0x773c25)
-                #9  0x00005576693bcee1 cpu_exec_setjmp (qemu-kvm + 0x772ee1)
-                #10 0x00005576693bcd64 cpu_exec (qemu-kvm + 0x772d64)
-                #11 0x00007fe0c5e4011c mttcg_cpu_thread_fn (accel-tcg-x86_64.so + 0x411c)
-                #12 0x0000557669662ada qemu_thread_start.llvm.13264588188580115644 (qemu-kvm + 0xa18ada)
-                #13 0x00007fe0c68a1912 start_thread (libc.so.6 + 0xa1912)
-                #14 0x00007fe0c683f450 __clone3 (libc.so.6 + 0x3f450)
-                
-                Stack trace of thread 1154721:
-                #0  0x00007fe0c69159e5 clock_nanosleep@GLIBC_2.2.5 (libc.so.6 + 0x1159e5)
-                #1  0x00007fe0c691a597 __nanosleep (libc.so.6 + 0x11a597)
-                #2  0x00007fe0c6b70c87 g_usleep (libglib-2.0.so.0 + 0x7ec87)
-                #3  0x0000557669670c18 call_rcu_thread (qemu-kvm + 0xa26c18)
-                #4  0x0000557669662ada qemu_thread_start.llvm.13264588188580115644 (qemu-kvm + 0xa18ada)
-                #5  0x00007fe0c68a1912 start_thread (libc.so.6 + 0xa1912)
-                #6  0x00007fe0c683f450 __clone3 (libc.so.6 + 0x3f450)
-                
-                Stack trace of thread 1154727:
-                #0  0x00007fe0c689e4aa __futex_abstimed_wait_common (libc.so.6 + 0x9e4aa)
-                #1  0x00007fe0c68a0cb0 pthread_cond_wait@@GLIBC_2.3.2 (libc.so.6 + 0xa0cb0)
-                #2  0x00005576696620c6 qemu_cond_wait_impl (qemu-kvm + 0xa180c6)
-                #3  0x000055766919425b qemu_wait_io_event (qemu-kvm + 0x54a25b)
-                #4  0x00007fe0c5e40180 mttcg_cpu_thread_fn (accel-tcg-x86_64.so + 0x4180)
-                #5  0x0000557669662ada qemu_thread_start.llvm.13264588188580115644 (qemu-kvm + 0xa18ada)
-                #6  0x00007fe0c68a1912 start_thread (libc.so.6 + 0xa1912)
-                #7  0x00007fe0c683f450 __clone3 (libc.so.6 + 0x3f450)
-                
-                Stack trace of thread 1154719:
-                #0  0x00007fe0c689e670 __GI___lll_lock_wait (libc.so.6 + 0x9e670)
-                #1  0x00007fe0c68a4d02 __pthread_mutex_lock@GLIBC_2.2.5 (libc.so.6 + 0xa4d02)
-                #2  0x0000557669661b76 qemu_mutex_lock_impl (qemu-kvm + 0xa17b76)
-                #3  0x000055766967c937 main_loop_wait (qemu-kvm + 0xa32937)
-                #4  0x00005576691a30c7 qemu_main_loop (qemu-kvm + 0x5590c7)
-                #5  0x0000557668fe3cca qemu_default_main (qemu-kvm + 0x399cca)
-                #6  0x00007fe0c683feb0 __libc_start_call_main (libc.so.6 + 0x3feb0)
-                #7  0x00007fe0c683ff60 __libc_start_main@@GLIBC_2.34 (libc.so.6 + 0x3ff60)
-                #8  0x0000557668fe33e5 _start (qemu-kvm + 0x3993e5)
-                
-                Stack trace of thread 1154725:
-                #0  0x00007fe0c689e670 __GI___lll_lock_wait (libc.so.6 + 0x9e670)
-                #1  0x00007fe0c68a4d02 __pthread_mutex_lock@GLIBC_2.2.5 (libc.so.6 + 0xa4d02)
-                #2  0x0000557669661b76 qemu_mutex_lock_impl (qemu-kvm + 0xa17b76)
-                #3  0x00005576693dc514 do_st_mmio_leN.llvm.5973256065011438912 (qemu-kvm + 0x792514)
-                #4  0x00005576693d3d22 do_st4_mmu.llvm.5973256065011438912 (qemu-kvm + 0x789d22)
-                #5  0x00007fe07cbfe35b n/a (n/a + 0x0)
-                ELF object binary architecture: AMD x86-64
-
-
-[coredumpctl_collect] Trying to run gdb with 'set print pretty on\nbt full' for '/usr/libexec/qemu-kvm'
-GNU gdb (GDB) Red Hat Enterprise Linux 10.2-13.el9
-Copyright (C) 2021 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-redhat-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"...
-/root/.gdbinit:1: Error in sourced command file:
-No symbol table is loaded.  Use the "file" command.
-Reading symbols from /usr/libexec/qemu-kvm...
-Downloading separate debug info for /usr/libexec/qemu-kvm...
-Reading symbols from /root/.cache/debuginfod_client/6fdfad7763b68956a31a335edd490cef23088a9a/debuginfo...
-Downloading separate debug info for /root/.cache/debuginfod_client/6fdfad7763b68956a31a335edd490cef23088a9a/debuginfo...
-[New LWP 1154728]
-[New LWP 1154721]
-[New LWP 1154727]
-[New LWP 1154719]
-[New LWP 1154725]
-[New LWP 1154729]
-[New LWP 1154726]
-[New LWP 1154723]
-[New LWP 1154730]
-[New LWP 1154724]
-[New LWP 1154722]
-Downloading separate debug info for /lib64/libpixman-1.so.0...
-Downloading separate debug info for /lib64/libcapstone.so.4...
-Downloading separate debug info for /root/.cache/debuginfod_client/fabd9508a8df77430d74e376fc1853545deaa9a4/debuginfo...
-Downloading separate debug info for /lib64/libgnutls.so.30...
-Downloading separate debug info for /root/.cache/debuginfod_client/3ca805ea0a9583fc8272d443181745507c6c1391/debuginfo...
-Downloading separate debug info for /lib64/libpng16.so.16...
-Downloading separate debug info for /lib64/libz.so.1...
-Downloading separate debug info for /lib64/libsasl2.so.3...
-Downloading separate debug info for /root/.cache/debuginfod_client/d5669a4356bbdf6b9dba9d25fe4674098af42f8d/debuginfo...
-Downloading separate debug info for /lib64/libsnappy.so.1...
-Downloading separate debug info for /lib64/liblzo2.so.2...
-Downloading separate debug info for /lib64/libpmem.so.1...
-Downloading separate debug info for /root/.cache/debuginfod_client/571e30ee251154a37d94e8c45def4e0b40fdaa92/debuginfo...
-Downloading separate debug info for /lib64/libseccomp.so.2...
-Downloading separate debug info for /lib64/libfdt.so.1...
-Downloading separate debug info for /root/.cache/debuginfod_client/31a56e0009a8824c7a09267c8205034c91cb4095/debuginfo...
-Downloading separate debug info for /lib64/libnuma.so.1...
-Downloading separate debug info for /root/.cache/debuginfod_client/e78797386b6fc540350223e432c3bfee6034d2e1/debuginfo...
-Downloading separate debug info for /lib64/libgio-2.0.so.0...
-Downloading separate debug info for /root/.cache/debuginfod_client/56c6122b97d5e4dd5fdf68756bdc02058ce02bbf/debuginfo...
-Downloading separate debug info for /lib64/libgobject-2.0.so.0...
-Downloading separate debug info for /lib64/libglib-2.0.so.0...
-Downloading separate debug info for /lib64/librdmacm.so.1...
-Downloading separate debug info for /root/.cache/debuginfod_client/7714785fff3ebddc1077a3fad30fffa35283766f/debuginfo...
-Downloading separate debug info for /lib64/libibverbs.so.1...
-Downloading separate debug info for /lib64/libslirp.so.0...
-Downloading separate debug info for /lib64/liburing.so.2...
-Downloading separate debug info for /root/.cache/debuginfod_client/8f52f15e8dff019c877c3c25083ef4a459429b99/debuginfo...
-Downloading separate debug info for /lib64/libgmodule-2.0.so.0...
-Downloading separate debug info for /lib64/libaio.so.1...
-Downloading separate debug info for /root/.cache/debuginfod_client/9b75d21282f8e17ddfa06aff78dae4f8dcce4106/debuginfo...
-Downloading separate debug info for /lib64/libm.so.6...
-Downloading separate debug info for /lib64/libresolv.so.2...
-Downloading separate debug info for /root/.cache/debuginfod_client/8a914905acea217452c928c2e200afceb83341c5/debuginfo...
-Downloading separate debug info for /lib64/libgcc_s.so.1...
-Downloading separate debug info for /root/.cache/debuginfod_client/ef4c928f1372ad155fea761f0e840ecd264fb153/debuginfo...
-Downloading separate debug info for /lib64/libc.so.6...
-Downloading separate debug info for /lib64/libp11-kit.so.0...
-Downloading separate debug info for /root/.cache/debuginfod_client/b935d795aaf6f8cbc392c922b6c97a4c8db44c41/debuginfo...
-Downloading separate debug info for /lib64/libidn2.so.0...
-Downloading separate debug info for /root/.cache/debuginfod_client/958c50fc94ecb196b24f3619762e7ec3f28a5b40/debuginfo...
-Downloading separate debug info for /lib64/libunistring.so.2...
-Downloading separate debug info for /lib64/libtasn1.so.6...
-Downloading separate debug info for /lib64/libnettle.so.8...
-Downloading separate debug info for /root/.cache/debuginfod_client/0dd622456d9a5330679490d3bd9d812582d9f9d3/debuginfo...
-Downloading separate debug info for /lib64/libhogweed.so.6...
-Downloading separate debug info for /lib64/libcrypt.so.2...
-Downloading separate debug info for /root/.cache/debuginfod_client/6ce4e5eb200e61d07398af52f8bcb316cf8466e0/debuginfo...
-Downloading separate debug info for /lib64/libgssapi_krb5.so.2...
-Downloading separate debug info for /root/.cache/debuginfod_client/5ce5f00c8b502e99ab96853950db60f97a710b28/debuginfo...
-Downloading separate debug info for /lib64/libkrb5.so.3...
-Downloading separate debug info for /lib64/libk5crypto.so.3...
-Downloading separate debug info for /lib64/libcom_err.so.2...
-Downloading separate debug info for /root/.cache/debuginfod_client/2313e22f074e5b67e97bb22e01a722cc727512b1/debuginfo...
-Downloading separate debug info for /lib64/libstdc++.so.6...
-Downloading separate debug info for /lib64/libndctl.so.6...
-Downloading separate debug info for /root/.cache/debuginfod_client/e2e24fd2c7061434b2a0cc849cdcd2854a4a0557/debuginfo...
-Downloading separate debug info for /lib64/libdaxctl.so.1...
-Downloading separate debug info for /lib64/libmount.so.1...
-Downloading separate debug info for /root/.cache/debuginfod_client/98bababfe2b3d1d0ca128831439521f2b5b7aa95/debuginfo...
-Downloading separate debug info for /lib64/libselinux.so.1...
-Downloading separate debug info for /root/.cache/debuginfod_client/bdc4adbb0901b548f448d6f0d92b49c352e3b9f6/debuginfo...
-Downloading separate debug info for /lib64/libffi.so.8...
-Downloading separate debug info for /lib64/libpcre.so.1...
-Downloading separate debug info for /root/.cache/debuginfod_client/cffb947bcc416dca3cd249cdb0a1c6f614549c30/debuginfo...
-Downloading separate debug info for /lib64/libnl-3.so.200...
-Downloading separate debug info for /root/.cache/debuginfod_client/22262a5a1956360f9f4c1daa89e592b1be03cd14/debuginfo...
-Downloading separate debug info for /lib64/libnl-route-3.so.200...
-Downloading separate debug info for /lib64/libkrb5support.so.0...
-Downloading separate debug info for /lib64/libkeyutils.so.1...
-Downloading separate debug info for /root/.cache/debuginfod_client/5f6459dcec3e266d994b8d4e5b23507c4c0df11e/debuginfo...
-Downloading separate debug info for /lib64/libcrypto.so.3...
-Downloading separate debug info for /root/.cache/debuginfod_client/fb8a738ffca8bdbe3172c842ee9d56f969516473/debuginfo...
-Downloading separate debug info for /lib64/libuuid.so.1...
-Downloading separate debug info for /lib64/libkmod.so.2...
-Downloading separate debug info for /root/.cache/debuginfod_client/9057cef69769e25914be12563e5d821aef1bd9cb/debuginfo...
-Downloading separate debug info for /lib64/libblkid.so.1...
-Downloading separate debug info for /lib64/libpcre2-8.so.0...
-Downloading separate debug info for /root/.cache/debuginfod_client/10357f8fa75891b03cd08344d56efa49ad9d607f/debuginfo...
-Downloading separate debug info for /lib64/libcap.so.2...
-Downloading separate debug info for /root/.cache/debuginfod_client/94e5c930fa02b381df948b2d2909d96da9f31407/debuginfo...
-Downloading separate debug info for /lib64/libzstd.so.1...
-Downloading separate debug info for /root/.cache/debuginfod_client/f0c68ad1b3f8941857af47c6887736d835317ccc/debuginfo...
-Downloading separate debug info for /lib64/liblzma.so.5...
-Downloading separate debug info for /usr/libexec/../lib64/qemu-kvm/accel-tcg-x86_64.so...
-Downloading separate debug info for /root/systemd/system-supplied DSO at 0x7ffd4cb6b000...
-[Thread debugging using libthread_db enabled]
-Using host libthread_db library "/lib64/libthread_db.so.1".
-Core was generated by `/bin/qemu-system-x86_64 -smp 8 -net none -m 768M -nographic -kernel /boot/vmlin'.
-Program terminated with signal SIGSEGV, Segmentation fault.
-#0  memory_region_get_iommu (mr=0x418c0fdb85f05d8b)
-    at /usr/src/debug/qemu-kvm-8.2.0-2.el9.x86_64/include/exec/memory.h:1715
-Downloading source file /usr/src/debug/qemu-kvm-8.2.0-2.el9.x86_64/include/exec/memory.h...
-1715	    if (mr->alias) {
-[Current thread is 1 (Thread 0x7fe033fff640 (LWP 1154728))]
-(gdb) (gdb) #0  memory_region_get_iommu (mr=0x418c0fdb85f05d8b)
-    at /usr/src/debug/qemu-kvm-8.2.0-2.el9.x86_64/include/exec/memory.h:1715
-        addr = 18446603473123421792
-        d = 0x7fe03c135150
-        section = 0x7fe03c621e70
-        imrc = <optimized out>
-        iommu_idx = <optimized out>
-        iotlb = {
-          target_as = <optimized out>,
-          iova = <optimized out>,
-          translated_addr = <optimized out>,
-          addr_mask = <optimized out>,
-          perm = <optimized out>
-        }
-#1  address_space_translate_for_iotlb
-    (cpu=0x55766c32c480, asidx=<optimized out>, orig_addr=472023040, xlat=0x7fe048df9ea0, plen=0x7fe048df9e98, attrs=..., prot=0x7fe048df9e94)
-    at ../system/physmem.c:688
-        addr = 18446603473123421792
-        d = 0x7fe03c135150
-        section = 0x7fe03c621e70
-        imrc = <optimized out>
-        iommu_idx = <optimized out>
-        iotlb = {
-          target_as = <optimized out>,
-          iova = <optimized out>,
-          translated_addr = <optimized out>,
-          addr_mask = <optimized out>,
-          perm = <optimized out>
-        }
-#2  0x00005576693d149f in tlb_set_page_full
-    (cpu=0x55766c32c480, mmu_idx=<optimized out>, addr=18446741874686296064, full=0x7fe048df9ed8) at ../accel/tcg/cputlb.c:1140
-        sz = 4096
-        addr_page = 18446741874686296064
-        paddr_page = 472023040
-        prot = 1
-        asidx = -536727968
-        xlat = 18599936
-        section = <optimized out>
-        read_flags = <optimized out>
-        is_romd = <optimized out>
-        addend = <optimized out>
-        write_flags = <optimized out>
-        iotlb = <optimized out>
-        wp_flags = <optimized out>
-        index = <optimized out>
-        te = <optimized out>
-        tn = {
-          {
-            addr_read = <optimized out>,
-            addr_write = <optimized out>,
-            addr_code = <optimized out>,
-            addend = <optimized out>
-          },
-          addr_idx = {<optimized out>, <optimized out>, <optimized out>, <optimized out>}
-        }
-#3  0x0000557669248a18 in tlb_set_page_with_attrs
-    (cpu=0x55766c32c480, addr=18446741874686296064, paddr=<optimized out>, attrs=..., prot=<optimized out>, mmu_idx=0, size=<optimized out>)
-    at ../accel/tcg/cputlb.c:1290
-        out = {
-          paddr = 472027056,
-          prot = 1,
-          page_size = 4096
-        }
-        err = {
-          exception_index = 472064000,
-          error_code = 0,
-          cr2 = 13915309287368685568,
-          stage2 = (unknown: 0x1c232b28)
-        }
-        env = <optimized out>
-#4  x86_cpu_tlb_fill
-    (cs=0x55766c32c480, addr=<optimized out>, size=<optimized out>, access_type=MMU_DATA_LOAD, mmu_idx=0, probe=<optimized out>, retaddr=0)
-    at ../target/i386/tcg/sysemu/excp_helper.c:610
-        out = {
-          paddr = 472027056,
-          prot = 1,
-          page_size = 4096
-        }
-        err = {
-          exception_index = 472064000,
-          error_code = 0,
-          cr2 = 13915309287368685568,
-          stage2 = (unknown: 0x1c232b28)
-        }
-        env = <optimized out>
-#5  0x00005576693db519 in tlb_fill
-    (addr=18446741874686300080, size=-2047844981, access_type=MMU_DATA_LOAD, mmu_idx=0, retaddr=0, cpu=<optimized out>) at ../accel/tcg/cputlb.c:1315
-        ok = <optimized out>
-        addr = 18446741874686300080
-        index = <optimized out>
-        entry = 0x7fe028017080
-        tlb_addr = <optimized out>
-        maybe_resized = false
-        full = <optimized out>
-        flags = <optimized out>
-#6  mmu_lookup1
-    (cpu=<optimized out>, data=0x7fe048df9f00, mmu_idx=0, access_type=MMU_DATA_LOAD, ra=0) at ../accel/tcg/cputlb.c:1713
-        addr = 18446741874686300080
-        index = <optimized out>
-        entry = 0x7fe028017080
-        tlb_addr = <optimized out>
-        maybe_resized = false
-        full = <optimized out>
-        flags = <optimized out>
-#7  0x00005576693db31b in mmu_lookup
-    (cpu=0x55766c32c480, addr=18446741874686300080, oi=<optimized out>, ra=0, type=MMU_DATA_LOAD, l=0x7fe048df9f00) at ../accel/tcg/cputlb.c:1803
-        a_bits = <optimized out>
-        flags = <optimized out>
-#8  0x00005576693d3173 in do_ld4_mmu
-    (cpu=0x7fe03c135150, addr=18446603473123421792, oi=2247122315, ra=140601056453952, access_type=MMU_DATA_LOAD) at ../accel/tcg/cputlb.c:2416
-        l = {
-          page = {{
-              full = 0x1c232000,
-              haddr = 0xc0700000000,
-              addr = 18446741874686300080,
-              flags = 88995840,
-              size = 4
-            }, {
-              full = 0x7fe033fff458,
-              haddr = 0xc11d1c12054df800,
-              addr = 18446741874686296064,
-              flags = 88995840,
-              size = 0
-            }},
-          memop = MO_32,
-          mmu_idx = 0
-        }
-        crosspage = <optimized out>
-        ret = <optimized out>
-#9  0x00005576692d44cf in cpu_ldl_mmu
-    (env=0x55766c32ec30, addr=18446741874686300080, oi=2247122315, ra=0)
-    at ../accel/tcg/ldst_common.c.inc:158
-        oi = 2247122315
-        has_error_code = <optimized out>
-        old_eip = 18446744072005078059
-        dt = 0x55766c32edc0
-        ptr = 18446741874686300080
-        e1 = <optimized out>
-        e2 = <optimized out>
-        e3 = <optimized out>
-        type = <optimized out>
-        dpl = <optimized out>
-        cpl = <optimized out>
-        selector = <optimized out>
-        offset = <optimized out>
-        ist = <optimized out>
-        new_stack = <optimized out>
-        esp = <optimized out>
-        ss = <optimized out>
-        count = 0
-        env = 0x55766c32ec30
-#10 cpu_ldl_le_mmuidx_ra
-    (env=0x55766c32ec30, addr=18446741874686300080, mmu_idx=<optimized out>, ra=0) at ../accel/tcg/ldst_common.c.inc:294
-        oi = 2247122315
-        has_error_code = <optimized out>
-        old_eip = 18446744072005078059
-        dt = 0x55766c32edc0
-        ptr = 18446741874686300080
-        e1 = <optimized out>
-        e2 = <optimized out>
-        e3 = <optimized out>
-        type = <optimized out>
-        dpl = <optimized out>
-        cpl = <optimized out>
-        selector = <optimized out>
-        offset = <optimized out>
-        ist = <optimized out>
-        new_stack = <optimized out>
-        esp = <optimized out>
-        ss = <optimized out>
-        count = 0
-        env = 0x55766c32ec30
-#11 do_interrupt64
-    (env=0x55766c32ec30, intno=251, is_int=0, error_code=0, next_eip=<optimized out>, is_hw=<optimized out>) at ../target/i386/tcg/seg_helper.c:889
-        has_error_code = <optimized out>
-        old_eip = 18446744072005078059
-        dt = 0x55766c32edc0
-        ptr = 18446741874686300080
-        e1 = <optimized out>
-        e2 = <optimized out>
-        e3 = <optimized out>
-        type = <optimized out>
-        dpl = <optimized out>
-        cpl = <optimized out>
-        selector = <optimized out>
-        offset = <optimized out>
-        ist = <optimized out>
-        new_stack = <optimized out>
-        esp = <optimized out>
-        ss = <optimized out>
-        count = 0
-        env = 0x55766c32ec30
-#12 do_interrupt_all
-    (cpu=0x55766c32c480, intno=251, is_int=0, error_code=0, next_eip=<optimized out>, is_hw=<optimized out>) at ../target/i386/tcg/seg_helper.c:1130
-        count = 0
-        env = 0x55766c32ec30
-#13 0x000055766924f605 in do_interrupt_x86_hardirq
-    (env=<optimized out>, intno=<optimized out>, is_hw=<optimized out>)
-    at ../target/i386/tcg/seg_helper.c:1162
-        cpu = 0x55766c32c480
-        env = <optimized out>
-        intno = <optimized out>
-#14 0x000055766924f605 in x86_cpu_exec_interrupt ()
-#15 0x00005576693bdc25 in cpu_handle_interrupt
-    (cpu=0x55766c32c480, last_tb=<optimized out>)
-    at ../accel/tcg/cpu-exec.c:865
-        cc = <optimized out>
-        interrupt_request = 2
-        last_tb = <optimized out>
-        tb_exit = <optimized out>
-        ret = <optimized out>
-#16 cpu_exec_loop (cpu=0x55766c32c480, sc=0x7fe048df9fb0)
-    at ../accel/tcg/cpu-exec.c:974
-        last_tb = <optimized out>
-        tb_exit = <optimized out>
-        ret = <optimized out>
-#17 0x00005576693bcee1 in cpu_exec_setjmp
-    (cpu=0x55766c32c480, sc=0x7fe048df9fb0) at ../accel/tcg/cpu-exec.c:1058
-#18 0x00005576693bcd64 in cpu_exec (cpu=0x55766c32c480)
-    at ../accel/tcg/cpu-exec.c:1084
-        sc = {
-          diff_clk = 0,
-          last_cpu_icount = 0,
-          realtime_clock = 0
-        }
-        ret = <optimized out>
-#19 0x00007fe0c5e4011c in tcg_cpus_exec (cpu=0x55766c32c480)
-    at ../accel/tcg/tcg-accel-ops.c:76
-        ret = <optimized out>
-        r = <optimized out>
-        force_rcu = {
-          notifier = {
-            notify = 0x7fe0c5e40250 <mttcg_force_rcu>,
-            node = {
-              le_next = 0x0,
-              le_prev = 0x7fe033fff478
-            }
-          },
-          cpu = 0x55766c32c480
-        }
-#20 mttcg_cpu_thread_fn (arg=0x55766c32c480)
-    at ../accel/tcg/tcg-accel-ops-mttcg.c:95
-        r = <optimized out>
-        force_rcu = {
-          notifier = {
-            notify = 0x7fe0c5e40250 <mttcg_force_rcu>,
-            node = {
-              le_next = 0x0,
-              le_prev = 0x7fe033fff478
-            }
-          },
-          cpu = 0x55766c32c480
-        }
-#21 0x0000557669662ada in qemu_thread_start (args=0x55766c3a1870)
-    at ../util/qemu-thread-posix.c:541
-        __clframe = {
-          __cancel_routine = <optimized out>,
-          __cancel_arg = 0x0,
-          __do_it = 1,
-          __cancel_type = <synthetic pointer>
-        }
-        qemu_thread_args = 0x55766c3a1870
-        start_routine = 0x7fe0c5e40000 <mttcg_cpu_thread_fn>
-        arg = 0x55766c32c480
-        r = <optimized out>
-#22 0x00007fe0c68a1912 in start_thread (arg=<optimized out>)
-    at pthread_create.c:443
-        ret = <optimized out>
-        pd = <optimized out>
-        unwind_buf = {
-          cancel_jmp_buf = {{
-              jmp_buf = {140725889877392, 270352123062618637, 140600921814592, 0, 140603380340288, 0, -288199396121933299, -287677566653593075},
-              mask_was_saved = 0
-            }},
-          priv = {
-            pad = {0x0, 0x0, 0x0, 0x0},
-            data = {
-              prev = 0x0,
-              cleanup = 0x0,
-              canceltype = 0
-            }
-          }
-        }
-        not_first_call = <optimized out>
-#23 0x00007fe0c683f450 in clone3 ()
-    at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
-```
-
-Also, a couple runs failed with:
-```
-+ /usr/libexec/qemu-kvm -smp 8 -net none -m 768M -nographic -kernel /boot/vmlinuz-5.14.0-427.el9.x86_64 -drive format=raw,cache=unsafe,file=/var/tmp/systemd-test.7FKAS9/basic.img -device virtio-rng-pci,max-bytes=1024,period=1000 -cpu Nehalem -initrd /var/tmp/ci-sanity-initramfs-5.14.0-390.el9.x86_64.img -append 'root=LABEL=systemd_boot rw raid=noautodetect rd.luks=0 loglevel=2 init=/usr/lib/systemd/systemd console=ttyS0 SYSTEMD_UNIT_PATH=/usr/lib/systemd/tests/testdata/testsuite-01.units:/usr/lib/systemd/tests/testdata/units: systemd.unit=testsuite.target systemd.wants=testsuite-01.service oops=panic panic=1 softlockup_panic=1 systemd.wants=end.service debug systemd.log_level=debug rd.systemd.log_target=console systemd.default_standard_output=journal+console systemd.unified_cgroup_hierarchy=1 systemd.legacy_systemd_cgroup_controller=0
-'
-Could not access KVM kernel module: No such file or directory
-qemu-kvm: failed to initialize kvm: No such file or directory
-qemu-kvm: falling back to tcg
-qemu-kvm: warning: Machine type 'pc-i440fx-rhel7.6.0' is deprecated: machine types for previous major releases are deprecated
-c[?7lSeaBIOS (version 1.16.3-2.el9)
-Booting from ROM...
-early console in setup codae
-Probing EDD (edd=off to disable)... oc[?7lk
-[    0.000000] Linux version 5.14.0-427.el9.x86_64 (mockbuild@x86-05.stream.rdu2.redhat.com) (gcc (GCC) 11.4.1 20231218 (Red Hat 11.4.1-3), GNU ld version 2.35.2-42.el9) #1 SMP PREEMPT_DYNAMIC Fri Feb 23 04:45:07 UTC 2024
-...
-[    2.152522] pci 0000:00:02.0: reg 0x30: [mem 0xfebe0000-0xfebeffff pref]
-[    2.153914] pci 0000:00:02.0: Video device with shadowed ROM at [mem 0x000c0000-0x000dffff]
-[    2.156615] pci 0000:00:03.0: [1af4:1005] type 00 class 0x00ff00
-[    2.159388] pci 0000:00:03.0: reg 0x10: [io  0xc000-0xc01f]
-qemu-kvm: ../system/memory.c:2424: void *memory_region_get_ram_ptr(MemoryRegion *): Assertion `mr->ram_block' failed.
-/bin/qemu-system-x86_64: line 4: 137172 Aborted                 (core dumped) "/usr/libexec/qemu-kvm" "$@"
-```
-
-I'm not sure if the two issues are related, or if the assertion is something completely different.
-Steps to reproduce:
-I, unfortunately, don't have any concrete steps to reproduce the issue, it happens randomly throughout CI runs. However, when needed, I can reproduce the issue in some reliable-ish manner by running the integration tests in a loop (the issue manifests itself usually in a couple of hours in this case).
-Additional information:
-
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/2302 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/2302
deleted file mode 100644
index b77301c24..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_TCG/2302
+++ /dev/null
@@ -1,25 +0,0 @@
-qemu-x86_64 crashes with "Illegal Instruction" on SPECCPU2017 Benchmarks
-Description of problem:
-I am running qemu-x86_64 with SPEC CPU 2017 benchmarks, and the compiled benchmarks such as Perlbench will crash unexpectedly. I have changed to three other machines to run it and still get crashes on two of them, I don't know what's the problem and want some help.
-Steps to reproduce:
-1. Compile SPEC CPU 2017 basic Perlbench binary. 
-2. Use the above command line to run it.
-Additional information:
-I have added some debugging flags to qemu-x86_64 to test it. The "-d in_asm" flag gives me the instructions before the crash like this:
-```
-----------------
-IN: Perl_lex_start
-0x555555678a79:  48 89 83 a8 00 00 00     movq     %rax, 0xa8(%rbx)
-0x555555678a80:  e9 01 ff ff ff           jmp      0x555555678986
-
-----------------
-IN: Perl_lex_start
-0x555555678986:  48 8b 50 10              movq     0x10(%rax), %rdx
-0x55555567898a:  41 83 e4 16              andl     $0x16, %r12d
-0x55555567898e:  48 89 93 d0 00 00 00     movq     %rdx, 0xd0(%rbx)
-0x555555678995:  48 89 93 c0 00 00 00     movq     %rdx, 0xc0(%rbx)
-0x55555567899c:  62                       .byte    0x62
-
-qemu: uncaught target signal 4 (Illegal instruction) - core dumped
-Illegal instruction (core dumped)
-```
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/2380 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/2380
deleted file mode 100644
index 196393378..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_TCG/2380
+++ /dev/null
@@ -1,105 +0,0 @@
-Crash on x86_64 vm launch
-Description of problem:
-When I started using QEMU for x86 OS programming about a year or 2 ago it ran fine until about a year ago where it just does not launch for more than a few seconds, it always crashes with no output at all, even when running with debug options enabled, it still outputs normal values before just crashing or exiting, this happens when running with an OS image or not, I have tried everything possible (wiping the whole system of anything including "qemu" including the registry, disabling all AV including windows defender, using SFC and DISM to repair corrupt files, installing the oldest versions of qemu up to the newest, running the program in different compatibility modes, running as admin, changing install directories, disabling overclocking, and many more) the only way it runs is if I use a VM to run qemu or reinstall windows, I am not reinstalling windows and im not running a vm to run another vm, my OS is very stable apart from this one program, I need to use QEMU as it is very important for my OS builds as it allows me to automate many things.
-Steps to reproduce:
-1. launch qemu-system-x86_64
-
-unable to reproduce on other clean OS installs
-Additional information:
-upon clean building QEMU from latest build using MSYS2 and running GDB here is the output
-
-```
-(gdb) run
-Starting program: C:\qemu\build\qemu-system-x86_64.exe
-[New Thread 22292.0x250c]
-[New Thread 22292.0x2004]
-[New Thread 22292.0x1d2c]
-[New Thread 22292.0x5614]
-[New Thread 22292.0x5b3c]
-[New Thread 22292.0x5ae8]
-[New Thread 22292.0x2d04]
-[New Thread 22292.0x5588]
-[New Thread 22292.0x3ce8]
-gdb: unknown target exception 0xc0000409 at 0x7ffac8f83e74
-
-Thread 8 received signal ?, Unknown signal.
-[Switching to Thread 22292.0x2d04]
-0x00007ffac8f83e74 in strerror_s () from C:\Windows\System32\msvcrt.dll
-
-```
-
-the error code leads to STATUS_STACK_BUFFER_OVERRUN
-
-upon back tracing this it leads to this output
-
-```
-(gdb) bt
-#0  0x00007ffac8f83e74 in strerror_s () from C:\Windows\System32\msvcrt.dll
-#1  0x00007ffac8f82c04 in msvcrt!longjmp () from C:\Windows\System32\msvcrt.dll
-#2  0x00007ff670af2b8e in advance_pc (env=0x34d3c60, s=0x4beff8d0, num_bytes=4)
-    at ../target/i386/tcg/translate.c:2131
-#3  0x00007ff670af2d33 in x86_ldl_code (env=0x34d3c60, s=0x4beff8d0)
-    at ../target/i386/tcg/translate.c:2169
-#4  0x00007ff670af3939 in insn_get (env=0x34d3c60, s=0x4beff8d0, ot=MO_32)
-    at ../target/i386/tcg/translate.c:2454
-#5  0x00007ff670b0c4ca in disas_insn (s=0x4beff8d0, cpu=0x34d1450)
-    at ../target/i386/tcg/translate.c:5148
-#6  0x00007ff670b1253f in i386_tr_translate_insn (dcbase=0x4beff8d0, cpu=0x34d1450)
-    at ../target/i386/tcg/translate.c:7023
-#7  0x00007ff670ba30b2 in translator_loop (cpu=0x34d1450, tb=0x3b3a280, max_insns=0x4beffba4,
-    pc=954352, host_pc=0x43de8ff0, ops=0x7ff671a9b480 <i386_tr_ops>, db=0x4beff8d0)
-    at ../accel/tcg/translator.c:164
-#8  0x00007ff670b127ef in gen_intermediate_code (cpu=0x34d1450, tb=0x3b3a280,
-    max_insns=0x4beffba4, pc=954352, host_pc=0x43de8ff0) at ../target/i386/tcg/translate.c:7099
-#9  0x00007ff670ba1abd in setjmp_gen_code (env=0x34d3c60, tb=0x3b3a280, pc=954352,
-    host_pc=0x43de8ff0, max_insns=0x4beffba4, ti=0x4beffbc0) at ../accel/tcg/translate-all.c:278
-#10 0x00007ff670ba1de3 in tb_gen_code (cpu=0x34d1450, pc=954352, cs_base=0, flags=176,
-    cflags=-16646144) at ../accel/tcg/translate-all.c:358
-#11 0x00007ff670b96508 in cpu_exec_loop (cpu=0x34d1450, sc=0x4beffd60)
-    at ../accel/tcg/cpu-exec.c:989
-#12 0x00007ff670b96689 in cpu_exec_setjmp (cpu=0x34d1450, sc=0x4beffd60)
-    at ../accel/tcg/cpu-exec.c:1035
-#13 0x00007ff670b96728 in cpu_exec (cpu=0x34d1450) at ../accel/tcg/cpu-exec.c:1061
---Type <RET> for more, q to quit, c to continue without paging--
-#14 0x00007ff670bc1fb7 in tcg_cpu_exec (cpu=0x34d1450) at ../accel/tcg/tcg-accel-ops.c:76
-#15 0x00007ff670bc28a2 in mttcg_cpu_thread_fn (arg=0x34d1450)
-    at ../accel/tcg/tcg-accel-ops-mttcg.c:95
-#16 0x00007ff670de8587 in win32_start_routine (arg=0x3537c60) at ../util/qemu-thread-win32.c:411
-#17 0x00007ffac8f8e634 in msvcrt!_beginthreadex () from C:\Windows\System32\msvcrt.dll
-#18 0x00007ffac8f8e70c in msvcrt!_endthreadex () from C:\Windows\System32\msvcrt.dll
-#19 0x00007ffac901257d in KERNEL32!BaseThreadInitThunk () from C:\Windows\System32\kernel32.dll
-#20 0x00007ffacae0aa48 in ntdll!RtlUserThreadStart () from C:\Windows\SYSTEM32\ntdll.dll
-#21 0x0000000000000000 in ?? ()
-
-```
-
-if I am reading the output correctly   qemu/target/i386/tcg/translate.c:2131     is the last file (in source) it accesses before moving to msvcrt.dll,  inside of the advance_pc function
-
-
-this is the function
-
-```
-static uint64_t advance_pc(CPUX86State *env, DisasContext *s, int num_bytes) {
-    uint64_t pc = s->pc;
-
-    if (s->base.num_insns > 1 && !is_same_page(&s->base, s->pc + num_bytes - 1)) {
-        siglongjmp(s->jmpbuf, 2);   <--------------------------------------------------   The line is the last function call
-    }
-
-    s->pc += num_bytes;
-
-    if (unlikely(cur_insn_len(s) > X86_MAX_INSN_LENGTH)) {
-        if (((s->pc - 1) ^ (pc - 1)) & TARGET_PAGE_MASK) {
-            volatile uint8_t unused = cpu_ldub_code(env, (s->pc - 1) & TARGET_PAGE_MASK);
-            (void)unused;
-        }
-        siglongjmp(s->jmpbuf, 1);
-    }
-
-    return pc;
-}
-```
-
-if I had to guess this problem could be caused by some windows configuration, something to do with memory, or maybe some corrupt files, but I am unsure
-
-I am not a c programmer so I don't know much about the code but I can debug more if needed
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/2474 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/2474
deleted file mode 100644
index 24a035905..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_TCG/2474
+++ /dev/null
@@ -1,96 +0,0 @@
-x86_64: strange translation of "vpgatherqq"
-Description of problem:
-The translate of instruction "vpgatherqq" is confusing.
-
-It happens when register xmm4 is in the middle, like "vpgatherqq %xmmi,0x0(,%xmm4,1),%xmmj".
-Steps to reproduce:
-1. Make a simple embedded assembly code named test.c:
-```
-int main()
-{
-    asm("vpgatherqq %xmm6,0x123(,%xmm2,4),%xmm7");
-    asm("vpgatherqq %xmm6,0x123(,%xmm3,4),%xmm7");
-    asm("vpgatherqq %xmm6,0x123(,%xmm4,4),%xmm7");
-    asm("vpgatherqq %xmm6,0x123(,%xmm5,4),%xmm7");
-    return 0;
-}
-```
-and compile it:
-```
-gcc -o test test.c -static
-```
-
-2. Run it with QEMU, print the micro ops:
-```
-qemu-x86_64 -d op -D a.out test
-```
-We can get output like this (only contain vpgatherqq):
-```
- ---- 000000000040174d 0000000000000000
- mov_i64 loc2,$0x123
- add_i64 loc14,env,$0x3d0      #This is xmm2
- add_i64 loc16,env,$0x4d0
- add_i64 loc18,env,$0x510
- call vpgatherqq_xmm,$0x0,$0,env,loc18,loc16,loc14,loc2,$0x2
- mov_vec v128,e8,tmp20,v128$0x0
- st_vec v128,e8,tmp20,env,$0x4e0
- mov_vec v128,e8,tmp22,v128$0x0
- st_vec v128,e8,tmp22,env,$0x520
-
- ---- 0000000000401757 0000000000000000
- mov_i64 loc2,$0x123
- add_i64 loc23,env,$0x410      #This is xmm3
- add_i64 loc25,env,$0x4d0
- add_i64 loc26,env,$0x510
- call vpgatherqq_xmm,$0x0,$0,env,loc26,loc25,loc23,loc2,$0x2
- mov_vec v128,e8,tmp27,v128$0x0
- st_vec v128,e8,tmp27,env,$0x4e0
- mov_vec v128,e8,tmp28,v128$0x0
- st_vec v128,e8,tmp28,env,$0x520
-
- ---- 0000000000401761 0000000000000000
- mov_i64 loc2,$0x123
- add_i64 loc29,env,$0x310      #This is xmm4 ???
- add_i64 loc31,env,$0x4d0
- add_i64 loc32,env,$0x510
- call vpgatherqq_xmm,$0x0,$0,env,loc32,loc31,loc29,loc2,$0x2
- mov_vec v128,e8,tmp33,v128$0x0
- st_vec v128,e8,tmp33,env,$0x4e0
- mov_vec v128,e8,tmp34,v128$0x0
- st_vec v128,e8,tmp34,env,$0x520
-
- ---- 000000000040176b 0000000000000000
- mov_i64 loc2,$0x123
- add_i64 loc35,env,$0x490      #This is xmm5
- add_i64 loc37,env,$0x4d0
- add_i64 loc38,env,$0x510
- call vpgatherqq_xmm,$0x0,$0,env,loc38,loc37,loc35,loc2,$0x2
- mov_vec v128,e8,tmp39,v128$0x0
- st_vec v128,e8,tmp39,env,$0x4e0
- mov_vec v128,e8,tmp40,v128$0x0
- st_vec v128,e8,tmp40,env,$0x520
-```
-3.
-
-Since the register xmms are continuous within the structure CPUArchState, the offset of xmm2, xmm3, xmm4, xmm5 should be a arithmetic sequence.
-
-From the output, we can infer that the common difference should be 0x40 and the offset of xmm4 should be 0x450 but not 0x310.
-
-I used GDB to track it, the location where the change occurred is:
-
-target/i386/tcg/translate.c, gen_lea_modrm_0(), line 2215:
-```
-        if (rm == 4) {
-            int code = x86_ldub_code(env, s);
-            scale = (code >> 6) & 3;
-            index = ((code >> 3) & 7) | REX_X(s);
-            if (index == 4) {
-                index = -1;  /* no index */
-            }
-            base = (code & 7) | REX_B(s);
-            havesib = 1;
-        }
-```
-This code turned 4 into -1, and -1 do explain the offset 0x310 (xmm0 has offset 0x350).
-Additional information:
-Monitoring the function "helper_vpgatherqq_xmm" can draw similar conclusions: it used wrong value but not xmm4.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/2489 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/2489
deleted file mode 100644
index a158b25aa..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_TCG/2489
+++ /dev/null
@@ -1,92 +0,0 @@
-qemu-system-x86_64 TCG coredumps when using qemu_plugin_register_vcpu_mem_cb
-Description of problem:
-QEMU freezes, then exits with `Segmentation fault (core dumped)`.
-Steps to reproduce:
-1. Install Windows 7 SP1 into `disk.qcow2`.
-2. Start the machine, and use `savevm snapshot` at the login screen, then exit.
-3. `./qemu-system-x86_64 -m 1G -M q35 -drive file=disk.qcow2 -nic none -loadvm snapshot -plugin contrib/plugins/libexeclog.so`
-Additional information:
-QEMU runs normally without the plugin.
-
-This bug can also be reproduced with a simpler plugin just calling `qemu_plugin_register_vcpu_mem_cb` once per instruction:
-[minimal_plugin.diff](/uploads/6e6c1af21df90379e726e693a53f7b8f/minimal_plugin.diff).
-
-Log using `-d op,in_asm,out_asm,plugin -D log`: [log.gz](/uploads/ccfd26c4845422d63f72a357f8fc1137/log.gz)
-
-GDB full backtrace:
-```
-(gdb) bt f
-#0  stw_he_p (v=0, ptr=0x2) at /REDACTED/qemu/include/qemu/bswap.h:265
-No locals.
-#1  stw_le_p (v=0, ptr=0x2) at /REDACTED/qemu/include/qemu/bswap.h:319
-No locals.
-#2  access_stw (ac=ac@entry=0x7f1652dfec70, addr=addr@entry=18446735827410705922, val=val@entry=0) at ../target/i386/tcg/access.c:143
-        p = 0x2
-#3  0x000055dfca88534e in do_xsave_fpu (ac=ac@entry=0x7f1652dfec70, ptr=ptr@entry=18446735827410705920) at ../target/i386/tcg/fpu_helper.c:2537
-        env = 0x55dff34fe630
-        fpus = 0
-        fptag = <optimized out>
-        i = <optimized out>
-        addr = <optimized out>
-#4  0x000055dfca88caf8 in do_fxsave (ptr=18446735827410705920, ac=0x7f1652dfec70) at ../target/i386/tcg/fpu_helper.c:2632
-        env = 0x55dff34fe630
-        env = <optimized out>
-#5  helper_fxsave (env=<optimized out>, ptr=18446735827410705920) at ../target/i386/tcg/fpu_helper.c:2656
-        ra = <optimized out>
-        ac = {vaddr = 18446735827410705920, haddr1 = 0x0, haddr2 = 0x0, size = 512, size1 = 512, mmu_idx = 4, env = 0x55dff34fe630, 
-          ra = 139732667533971}
-#6  0x00007f160c030a93 in code_gen_buffer ()
-No locals.
-#7  0x000055dfca979986 in cpu_tb_exec (cpu=cpu@entry=0x55dff34fbe70, itb=itb@entry=0x7f160c030940 <code_gen_buffer+198931>, 
-    tb_exit=tb_exit@entry=0x7f1652dff228) at ../accel/tcg/cpu-exec.c:458
-        ret = <optimized out>
-        last_tb = <optimized out>
-        tb_ptr = 0x7f160c030a00 <code_gen_buffer+199123>
-        __PRETTY_FUNCTION__ = "cpu_tb_exec"
-#8  0x000055dfca979edd in cpu_loop_exec_tb (tb_exit=0x7f1652dff228, last_tb=<synthetic pointer>, pc=<optimized out>, 
-    tb=0x7f160c030940 <code_gen_buffer+198931>, cpu=0x55dff34fbe70) at ../accel/tcg/cpu-exec.c:908
-        insns_left = <optimized out>
-        __PRETTY_FUNCTION__ = "cpu_loop_exec_tb"
-        insns_left = <optimized out>
-        _a15 = <optimized out>
-        _b16 = <optimized out>
-#9  cpu_exec_loop (cpu=cpu@entry=0x55dff34fbe70, sc=sc@entry=0x7f1652dff2c0) at ../accel/tcg/cpu-exec.c:1022
-        tb = 0x7f160c030940 <code_gen_buffer+198931>
-        flags = <optimized out>
-        cflags = 4278321152
-        pc = <optimized out>
-        cs_base = <optimized out>
-        last_tb = <optimized out>
-        tb_exit = 1
-        ret = <optimized out>
-#10 0x000055dfca97a6fd in cpu_exec_setjmp (cpu=cpu@entry=0x55dff34fbe70, sc=sc@entry=0x7f1652dff2c0) at ../accel/tcg/cpu-exec.c:1039
-No locals.
-#11 0x000055dfca97ae79 in cpu_exec (cpu=cpu@entry=0x55dff34fbe70) at ../accel/tcg/cpu-exec.c:1065
-        ret = <optimized out>
-        sc = {diff_clk = 0, last_cpu_icount = 0, realtime_clock = 0}
-        _rcu_read_auto = 0x1
-#12 0x000055dfca9a35af in tcg_cpu_exec (cpu=cpu@entry=0x55dff34fbe70) at ../accel/tcg/tcg-accel-ops.c:78
---Type <RET> for more, q to quit, c to continue without paging--c
-        ret = <optimized out>
-        __PRETTY_FUNCTION__ = "tcg_cpu_exec"
-#13 0x000055dfca9a3703 in mttcg_cpu_thread_fn (arg=arg@entry=0x55dff34fbe70) at ../accel/tcg/tcg-accel-ops-mttcg.c:95
-        r = <optimized out>
-        force_rcu = {notifier = {notify = 0x55dfca9a37f0 <mttcg_force_rcu>, node = {le_next = 0x0, le_prev = 0x7f1652e00528}}, cpu = 0x55dff34fbe70}
-        cpu = 0x55dff34fbe70
-        __PRETTY_FUNCTION__ = "mttcg_cpu_thread_fn"
-        __func__ = "mttcg_cpu_thread_fn"
-#14 0x000055dfcab7e898 in qemu_thread_start (args=0x55dff355dd80) at ../util/qemu-thread-posix.c:541
-        __cancel_buf = {__cancel_jmp_buf = {{__cancel_jmp_buf = {94420348558720, 3438567870158976394, -1656, 0, 140727865026624, 139734089805824, 
-                8803266606146106762, 3438582454403577226}, __mask_was_saved = 0}}, __pad = {0x7f1652dff430, 0x0, 0x0, 0x0}}
-        __cancel_routine = 0x55dfcab7e8f0 <qemu_thread_atexit_notify>
-        __cancel_arg = <optimized out>
-        __not_first_call = <optimized out>
-        qemu_thread_args = <optimized out>
-        start_routine = 0x55dfca9a3600 <mttcg_cpu_thread_fn>
-        arg = 0x55dff34fbe70
-        r = <optimized out>
-#15 0x00007f165e090272 in start_thread () from /nix/store/dbcw19dshdwnxdv5q2g6wldj6syyvq7l-glibc-2.39-52/lib/libc.so.6
-No symbol table info available.
-#16 0x00007f165e10bdec in clone3 () from /nix/store/dbcw19dshdwnxdv5q2g6wldj6syyvq7l-glibc-2.39-52/lib/libc.so.6
-No symbol table info available.
-```
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/249 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/249
deleted file mode 100644
index 6a6789a26..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_TCG/249
+++ /dev/null
@@ -1 +0,0 @@
-guest OS catches a page  fault bug when running dotnet
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/2495 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/2495
deleted file mode 100644
index 4d6c2322c..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_TCG/2495
+++ /dev/null
@@ -1,72 +0,0 @@
-A bug in x86-64 MMX instructions
-Description of problem:
-It seems QEMU emits invalid TCG when lifting MMX instructions with redundant REX prefixes. For example, when lifting `490f7ec0 (movq r8, mm0)`, QEMU generates the following valid TCG.
-
-```
- ---- 00000000004011f2 0000000000000000
- call enter_mmx,$0x0,$0,env
- ld_i64 loc0,env,$0x270
- mov_i64 r8,loc0
- mov_i64 rip,$0x4011f6
- exit_tb $0x0
- set_label $L0
- exit_tb $0x7f84f82ec143
-```
-
-However, after changing the value of the rex prefix to `4f` , so the instruction becomes `4f0f7ec0 (rex.WRXB movq r8, mm0)`, the lifted TCG is changed to:
-
-```
- ---- 00000000004011f2 0000000000000000
- call enter_mmx,$0x0,$0,env
- ld_i64 loc0,env,$0x2f0 // The offset to MM0 is changed
- mov_i64 r8,loc0
- mov_i64 rip,$0x4011f6
- exit_tb $0x0
- set_label $L0
- exit_tb $0x7f98e82ec143
-```
-
-I have observed this bug in numerous MMX instructions. For example, `410fdaff (rex.B pminub mm7, mm7)` is lifted to the wrong TCGs.
-
-It seems this bug looks similar to #2474.
-Steps to reproduce:
-1. Write `test.c` 
-```
-#include <stdint.h>
-#include <stdio.h>
-#include <string.h>
-
-uint8_t i_R8[8] = { 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0 };
-uint8_t i_MM0[8] = { 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff };
-uint8_t o_R8[8];
-
-void __attribute__ ((noinline)) show_state() {
-    printf("R8: ");
-    for (int i = 0; i < 8; i++) {
-        printf("%02x ", o_R8[i]);
-    }
-    printf("\n");
-}
-
-void __attribute__ ((noinline)) run() {
-    __asm__ (
-        ".intel_syntax noprefix\n"
-        "mov r8, qword ptr [rip + i_R8]\n"
-        "movq mm0, qword ptr [rip + i_MM0]\n"
-        ".byte 0x4f, 0x0f, 0x7e, 0xc0\n"
-        "mov qword ptr [rip + o_R8], r8\n"
-        ".att_syntax\n"
-    );
-}
-
-int main(int argc, char **argv) {
-    run();
-    show_state();
-    return 0;
-}
-```    
-2. Compile `test.bin` using this command: `gcc-12 -O2 -no-pie ./test.c -o ./test.bin`
-3. Run QEMU using this command: `qemu-x86_64 ./test.bin` 
-4. The program, runs on top of the buggy QEMU, prints the value of R8 as `00 00 00 00 00 00 00 00`. It should print `ff ff ff ff ff ff ff ff` after the bug is fixed.
-Additional information:
-
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/2511 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/2511
deleted file mode 100644
index 285afaaa1..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_TCG/2511
+++ /dev/null
@@ -1,32 +0,0 @@
-Regression 9.1.0rc2: target/i386/tcg/access.c:18: access_prepare_mmu: Assertion '...' failed.
-Description of problem:
-Executing QEMU command line crashes with 
-   ```
-qemu-system-x86_64: ../target/i386/tcg/access.c:18: access_prepare_mmu: Assertion `size > 0 && size <= TARGET_PAGE_SIZE' failed.
-   ```
-Steps to reproduce:
-1. Download https://www.qemu-advent-calendar.org/2020/download/day07.tar.gz
-2. Execute with QEMU command line
-Additional information:
-git bisect finishes with:
-   ```
-8b131065080af3cf2dda04e4e190c5a74fec2f31 is the first bad commit
-commit 8b131065080af3cf2dda04e4e190c5a74fec2f31
-Author: Paolo Bonzini <pbonzini@redhat.com>
-Date:   Tue Jun 18 09:13:49 2024 +0200
-
-    target/i386/tcg: use X86Access for TSS access
-    
-    This takes care of probing the vaddr range in advance, and is also faster
-    because it avoids repeated TLB lookups.  It also matches the Intel manual
-    better, as it says "Checks that the current (old) TSS, new TSS, and all
-    segment descriptors used in the task switch are paged into system memory";
-    note however that it's not clear how the processor checks for segment
-    descriptors, and this check is not included in the AMD manual.
-    
-    Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
-    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
-
- target/i386/tcg/seg_helper.c | 110 +++++++++++++++++++++++--------------------
- 1 file changed, 58 insertions(+), 52 deletions(-)
-   ```
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/2567 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/2567
deleted file mode 100644
index 3f0ceb389..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_TCG/2567
+++ /dev/null
@@ -1,78 +0,0 @@
-crash in target/i386/tcg/translate.c on loongarch64 Linux debian 6.11.0-rc7
-Description of problem:
-```
-  ERROR:target/i386/tcg/translate.c:748:gen_helper_out_func: code should not be reached 
-  Bail out! ERROR:target/i386/tcg/translate.c:748:gen_helper_out_func: code should not be reached 
-  已中止（核心已转储）
-  ```
-Steps to reproduce:
-1. windows x64 has been installed into win7_x64.qcow2
-2. windows x64 in win7_x64.qcow2 has been run for several times by the same command line
-3. crash occurred when windows was starting up
-Additional information:
-```
-Hint: You are currently not seeing messages from other users and the system.
-      Users in groups 'adm', 'systemd-journal' can see all messages.
-      Pass -q to turn off this notice.
-           PID: 61627 (qemu-system-x86)
-           UID: 1000 (tsingkong)
-           GID: 1001 (tsingkong)
-        Signal: 6 (ABRT)
-     Timestamp: Tue 2024-09-10 15:59:05 CST (18h ago)
-  Command Line: qemu-system-x86_64 -name win7_x64 -hda /SATA/QEMU/win7_x64.qcow2 -boot c -cpu qemu64 -smp sockets=1,cores=4,threads=1 -m 8G -device VGA -netdev user,id=lan -device rtl8139,netdev=lan -usb -device usb-tablet -rtc base=localtime -monitor stdio
-    Executable: /usr/bin/qemu-system-x86_64
- Control Group: /user.slice/user-1000.slice/user@1000.service/app.slice/app-org.kde.konsole-353cf168c0a84fbe8cdc2b8b72cba71e.scope
-          Unit: user@1000.service
-     User Unit: app-org.kde.konsole-353cf168c0a84fbe8cdc2b8b72cba71e.scope
-         Slice: user-1000.slice
-     Owner UID: 1000 (tsingkong)
-       Boot ID: 49cf5288d7af4b97be341fe599f0c8df
-    Machine ID: 3ab0590011874c2e916d2eeef4585dfb
-      Hostname: debian
-       Storage: /var/lib/systemd/coredump/core.qemu-system-x86.1000.49cf5288d7af4b97be341fe599f0c8df.61627.1725955145000000.zst (present)
-  Size on Disk: 285.9M
-       Message: Process 61627 (qemu-system-x86) of user 1000 dumped core.
-                
-                Module libsystemd.so.0 from deb systemd-256.5-2.loong64
-                Module libgcc_s.so.1 from deb gcc-14-14.2.0-4.loong64
-                Module libstdc++.so.6 from deb gcc-14-14.2.0-4.loong64
-                Module libblkid.so.1 from deb util-linux-2.40.2-8.loong64
-                Module libatomic.so.1 from deb gcc-14-14.2.0-4.loong64
-                Module libmount.so.1 from deb util-linux-2.40.2-8.loong64
-                Module libzstd.so.1 from deb libzstd-1.5.6+dfsg-1.loong64
-                Module libudev.so.1 from deb systemd-256.5-2.loong64
-                Stack trace of thread 61637:
-                #0  0x00007ffff2536968 __pthread_kill_implementation (libc.so.6 + 0x76968)
-                #1  0x00007ffff24f17dc __GI_raise (libc.so.6 + 0x317dc)
-                #2  0x00007ffff24dd238 __GI_abort (libc.so.6 + 0x1d238)
-                #3  0x00007ffff2ccf704 g_assertion_message (libglib-2.0.so.0 + 0x93704)
-                #4  0x00007ffff2ccf768 g_assertion_message_expr (libglib-2.0.so.0 + 0x93768)
-                #5  0x000055555630c440 n/a (qemu-system-x86_64 + 0x830440)
-                #6  0x00005555563286e8 n/a (qemu-system-x86_64 + 0x84c6e8)
-                #7  0x000055555632ef0c n/a (qemu-system-x86_64 + 0x852f0c)
-                #8  0x00005555563f9108 translator_loop (qemu-system-x86_64 + 0x91d108)
-                #9  0x0000555556332474 gen_intermediate_code (qemu-system-x86_64 + 0x856474)
-                #10 0x00005555563f7c08 n/a (qemu-system-x86_64 + 0x91bc08)
-                #11 0x00005555563f8204 tb_gen_code (qemu-system-x86_64 + 0x91c204)
-                #12 0x00005555563ecd54 n/a (qemu-system-x86_64 + 0x910d54)
-                #13 0x00005555563ed288 n/a (qemu-system-x86_64 + 0x911288)
-                #14 0x00005555563edb98 cpu_exec (qemu-system-x86_64 + 0x911b98)
-                #15 0x00007fffdc006c5c tcg_cpu_exec (accel-tcg-x86_64.so + 0x2c5c)
-                #16 0x00007fffdc006df4 n/a (accel-tcg-x86_64.so + 0x2df4)
-                #17 0x0000555556636000 n/a (qemu-system-x86_64 + 0xb5a000)
-                #18 0x00007ffff2534ca4 start_thread (libc.so.6 + 0x74ca4)
-                #19 0x00007ffff259cbcc __thread_start3 (libc.so.6 + 0xdcbcc)
-                
-                Stack trace of thread 61640:
-                #0  0x00005555563fd620 n/a (qemu-system-x86_64 + 0x921620)
-                #1  0x0000555556401b44 get_page_addr_code_hostp (qemu-system-x86_64 + 0x925b44)
-                #2  0x00005555563ebda8 n/a (qemu-system-x86_64 + 0x90fda8)
-                #3  0x00005555563ed5f0 helper_lookup_tb_ptr (qemu-system-x86_64 + 0x9115f0)
-                #4  0x00007fff8d39309c n/a (n/a + 0x0)
-                ELF object binary architecture: LoongArch
-
-```
-
-core.qemu-system-x86.1000.49cf5288d7af4b97be341fe599f0c8df.61627.1725955145000000.zst
-
-https://mega.nz/file/M9ZVzQYS#Z8kw6_cul56nd_p2iwz2SRb4Yb_1K8gqH2YlBBjKk6U
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/2578 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/2578
deleted file mode 100644
index c193ba1f9..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_TCG/2578
+++ /dev/null
@@ -1,14 +0,0 @@
-x86: exception during hardware interrupt pushes wrong error code
-Description of problem:
-Exceptions during IDT traversal push the wrong error code when triggered by a hardware interrupt.
-The EXT bit in TCG mode is never set.  However, it works fine in KVM mode as hardware is generating the number.
-Steps to reproduce:
-1. load a short IDT e.g. with 64 entries
-2. trigger a self IPI through the LAPIC with a vector 100
-3. the pushed error code is 802 instead of 803.
-Additional information:
-It can be fixed in the lines `raise_exception_err(env, EXCP0D_GPF, intno * 8 + 2);` in `seg_helper.c` 
-which must include the `is_hw` field when calculating the error number. Something like `intno * 8 + 2 + (is_hw != 0)` 
-works here.
-
-Nevertheless, all the other exception cases in the `do_interrupt_*` functions have to set the same bit as well.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/2581 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/2581
deleted file mode 100644
index 7c1f3efe5..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_TCG/2581
+++ /dev/null
@@ -1,12 +0,0 @@
-Assert failure "target/i386/tcg/translate.c:748:gen_helper_out_func" when emulating Windows
-Description of problem:
-qemu crashes with:
-```
-ERROR:../target/i386/tcg/translate.c:748:gen_helper_out_func: code should not be reached
-```
-Steps to reproduce:
-1. Run the command listed above
-2. Wait a random amount of time (anywhere between 30mins to 2hours)
-3. Qemu will crash at some point
-Additional information:
-- Relevant part of the macOS crash log: [qemu-crash.txt](/uploads/5cc296fd0e8c603ba08379749a67071d/qemu-crash.txt)
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/2599 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/2599
deleted file mode 100644
index 341068d4d..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_TCG/2599
+++ /dev/null
@@ -1 +0,0 @@
-[x86] RET imm16 not align with native machine
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/2605 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/2605
deleted file mode 100644
index d4e401264..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_TCG/2605
+++ /dev/null
@@ -1 +0,0 @@
-amd64/v4 support
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/265 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/265
deleted file mode 100644
index f9a0ab10d..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_TCG/265
+++ /dev/null
@@ -1 +0,0 @@
-x86: retf or iret pagefault sets wrong error code
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/279 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/279
deleted file mode 100644
index f45f25512..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_TCG/279
+++ /dev/null
@@ -1 +0,0 @@
-x86-64 MTTCG Does not update page table entries atomically
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/2821 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/2821
deleted file mode 100644
index e7cc3c88e..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_TCG/2821
+++ /dev/null
@@ -1,23 +0,0 @@
-Emulated newer x86 chipsets are noticably slower on cpu-bound loads than "-cpu qemu64"
-Description of problem:
-I noticed that "-cpu qemu64" is much faster than "-cpu max" or "-cpu Icelake-Server-noTSX" for cpu bound loads, and with more than one cpu under load.
-Steps to reproduce:
-1. Run a guest as per "qemu-system-x86_64 -cpu max [..]" command from above. Any linux distro should do.
-2. run through the setup questions if you use Fedora-Server-KVM-41-1.4.x86_64.qcow2 from the example command line above
-3. log into the guest via ssh, i.e. "ssh chris@amd64" here
-4. cd /dev/shm; wget http://archive.apache.org/dist/httpd/httpd-2.4.57.tar.bz2; wget https://fluxcoil.net/files/tmp/job_httpd_extract_cpu.sh
-6. bash ./job_httpd_extract_cpu.sh 4 300
-8. cat /tmp/counter
-
-Step 6 is executing a script which simply uses 4 parallel loops, where each loop runs "bzcat httpd-2.4.57.tar.bz2" constantly. After 300sec, the successful uncompressions over all 4 loops are summed up and stored in /tmp/counter.
-
-- result with "-cpu qemu64": 96
-- result with "-cpu max": 84
-- result with "-cpu Icelake-Server-noTSX": 44
-Additional information:
-- For "-cpu Icelake-Server-noTSX" on this Thinkpad T590 I get these warnings, I think they are not relevant:
-  qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:ECX.pcid [bit 17]
-  qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:ECX.tsc-deadline [bit 24]
-  [..]
-- I also looked at Broadwell etc, and all of them seem in the same ballpark.
-  Graph over some emulated architectures: https://fluxcoil.net/files/tmp/gnuplot_cpu-performance-emulated-only.png
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/286 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/286
deleted file mode 100644
index f76a347db..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_TCG/286
+++ /dev/null
@@ -1 +0,0 @@
-Performance degradation for WinXP boot time after b55f54bc
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/2878 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/2878
deleted file mode 100644
index b03a49d51..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_TCG/2878
+++ /dev/null
@@ -1 +0,0 @@
-Support for avx512 in qemu user space  emulation.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/2891 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/2891
deleted file mode 100644
index c7bf2e6bc..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_TCG/2891
+++ /dev/null
@@ -1 +0,0 @@
-qemu-system-x86_64 segfaults when executing ipxe selftests
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/314 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/314
deleted file mode 100644
index 3984c1457..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_TCG/314
+++ /dev/null
@@ -1 +0,0 @@
-qemu-user vm86() segfaults handling interrupt with ss:sp in same page as cs:ip
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/318 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/318
deleted file mode 100644
index 3450c0bde..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_TCG/318
+++ /dev/null
@@ -1 +0,0 @@
-QEMU crash after a QuickBASIC program integer overflow
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/330 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/330
deleted file mode 100644
index 7af554a07..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_TCG/330
+++ /dev/null
@@ -1 +0,0 @@
-TCG does not support x2APIC emulation
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/380 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/380
deleted file mode 100644
index 164de1554..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_TCG/380
+++ /dev/null
@@ -1 +0,0 @@
-Windows 7 fails to boot
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/382 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/382
deleted file mode 100644
index a9cfa56a5..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_TCG/382
+++ /dev/null
@@ -1 +0,0 @@
-target/i386/seg_helper.c: 16-bit TSS struct format wrong?
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/394 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/394
deleted file mode 100644
index 8cd4fd3d6..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_TCG/394
+++ /dev/null
@@ -1 +0,0 @@
-Windows 7 crashing due to PAGE_FAULT_IN_NONPAGED_AREA
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/404 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/404
deleted file mode 100644
index c78b2af67..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_TCG/404
+++ /dev/null
@@ -1 +0,0 @@
-Windows XP takes much longer to boot in TCG mode since 5.0
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/420 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/420
deleted file mode 100644
index 3243e66a1..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_TCG/420
+++ /dev/null
@@ -1 +0,0 @@
-Some x86_64 SSE operations have incorrect/erratic behaviours
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/427 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/427
deleted file mode 100644
index c431467cb..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_TCG/427
+++ /dev/null
@@ -1 +0,0 @@
-TCG: QEMU incorrectly raises exception on SSE4.2 CRC32 instruction
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/505 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/505
deleted file mode 100644
index 7f7e4d020..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_TCG/505
+++ /dev/null
@@ -1,12 +0,0 @@
-QEMU crashes when reaching a hardware watchpoint
-Description of problem:
-When using hardware watchpoints, qemu crashes when it hits the watch point.
-See https://github.com/zephyrproject-rtos/zephyr/issues/28613 for the same problem
-Steps to reproduce:
-1. Download https://download.qemu.org/qemu-6.1.0-rc0.tar.xz
-2. Download debian-live-10.10.0-i386-standard.iso from https://cdimage.debian.org/debian-cd/current-live/i386/iso-hybrid/
-3. Build qemu with /configure --target-list=i386-softmmu
-4. Run build/qemu-system-i386 -boot d -cdrom debian-live-10.10.0-i386-standard.iso -m 512 -icount auto -gdb tcp:localhost:1234 -S -display none
-5. Run gdb and inside gdb run "target remote localhost:1234"
-6. In gdb, run "watch *0x0000fff0" and "cont"
-7. qemu will crash with ```qemu: fatal: Raised interrupt while not in I/O function```
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/509 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/509
deleted file mode 100644
index 174c00e84..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_TCG/509
+++ /dev/null
@@ -1 +0,0 @@
-Atomic test-and-set instruction does not work on qemu-user
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/601 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/601
deleted file mode 100644
index f17b0df40..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_TCG/601
+++ /dev/null
@@ -1,20 +0,0 @@
-import tensorflow causes qemu: uncaught target signal 6 (Aborted) - core dumped
-Description of problem:
-Crashes when importing tensorflow in Docker container under --platorm linux/amd64 on M1 Mac
-```
-2021-09-06 13:35:24.435613: F tensorflow/core/lib/monitoring/sampler.cc:42] Check failed: bucket_limits_[i] > bucket_limits_[i - 1] (0 vs. 10)
-qemu: uncaught target signal 6 (Aborted) - core dumped
-```
-Steps to reproduce:
-See https://gitlab.com/ryan-feather/docker-tensorflow-qemu-bug/ for Dockerfile and description of steps repeating here.
-1. Using the dockerfile 
-```
-FROM python:3.9-buster
-RUN pip install tensorflow==2.6.0
-
-```
-2. `docker buildx build --iidfile build.id --platform linux/amd64 . --progress=plain`
-3. ``` docker run --platform linux/amd64  `cat build.id` python -c "import tensorflow"```
-Additional information:
-See 
-https://github.com/docker/for-mac/issues/5342 where the Docker team suggests this is a qemu bug. I couldn't find where anyone had opened one of these here, so hopefully this isn't a duplicate.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/619 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/619
deleted file mode 100644
index 440e98c45..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_TCG/619
+++ /dev/null
@@ -1 +0,0 @@
-Move TCGCPUOps::fake_user_exception() to linux-user/i386/cpu_loop.c
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/661 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/661
deleted file mode 100644
index 5b1f1b34a..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_TCG/661
+++ /dev/null
@@ -1,44 +0,0 @@
-Unable to enable 5 level paging
-Description of problem:
-When attempting to set cr4.LA57, qemu just freezes on that instruction. When I say freeze I mean literally freeze, no exceptions, nothing, it just halts forever on that instruction. When this happened, the first thing I did was
-
-```
-(qemu) info registers 
-EAX=00001000 EBX=00000001 ECX=80224f08 EDX=00000000
-ESI=8034a3a0 EDI=00026520 EBP=000079f8 ESP=000079c8
-EIP=00019648 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
-ES =0020 00000000 ffffffff 00c09300 DPL=0 DS   [-WA]
-CS =0018 00000000 ffffffff 00c09a00 DPL=0 CS32 [-R-]
-SS =0020 00000000 ffffffff 00c09300 DPL=0 DS   [-WA]
-DS =0020 00000000 ffffffff 00c09300 DPL=0 DS   [-WA]
-FS =0020 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
-GS =0020 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
-LDT=0000 00000000 00000000 00008200 DPL=0 LDT
-TR =0000 00000000 0000ffff 00008b00 DPL=0 TSS32-busy
-GDT=     0000e120 00000037
-IDT=     00000000 00000000
-CR0=00000011 CR2=00000000 CR3=00000000 CR4=00000000
-DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 
-DR6=00000000ffff0ff0 DR7=0000000000000400
-EFER=0000000000000000
-...
-```
-
-then using gdb to figure out what instruction it is hanging on, I set a breakpoint at 0x19648 at and ran 
-```
-(gdb) x/1 0x19648
-=> 0x19648:	mov    %rax,%cr4
-(gdb) 
-```
-
-This instruction corresponds to this LOC within limine https://github.com/limine-bootloader/limine/blob/trunk/stage23/protos/stivale.32.c#L33
-Steps to reproduce:
-1. Try to enable 5 level paging
-2. qemu freezes when trying to set cr4.LA57
-3. cry
-Additional information:
-This never happened prior to version 6.1, I test this on multiple different machines and a few of my friends 
-experienced the same issue
-
-I have not tested this on linux, however I assume it will do the same on anything else. 
-Either way, qemu should not be just halting
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/67 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/67
deleted file mode 100644
index eeedac6a4..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_TCG/67
+++ /dev/null
@@ -1 +0,0 @@
-incomplete emulation of fstenv under TCG
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/676 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/676
deleted file mode 100644
index 0ca7eec26..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_TCG/676
+++ /dev/null
@@ -1,54 +0,0 @@
-Throws a PF when it should throw a GF/SS
-Description of problem:
-QEMU misreports what should be a #GP as a #PF 
-```
-check_exception old: 0xffffffff new 0xe
-     0: v=0e e=0001 i=0 cpl=0 IP=0028:ffffffffb28fa53b pc=ffffffffb28fa53b SP=0030:ffffffffb2901210 CR2=1fbf7020000772a4
-RAX=1fbf7020000772a4 RBX=0000000000000000 RCX=ffff80000006a0a8 RDX=ffff80000006a038
-RSI=1fbff0200000d26c RDI=0000000000000080 RBP=ffffffffb2901230 RSP=ffffffffb2901210
-R8 =ffffffffb28fb37f R9 =0000000000000000 R10=0000000000000000 R11=0000000000000000
-R12=0000000000000000 R13=0000000000000000 R14=0000000000000000 R15=0000000000000000
-RIP=ffffffffb28fa53b RFL=00000007 [-----PC] CPL=0 II=0 A20=1 SMM=0 HLT=0
-ES =0030 0000000000000000 00000000 00009300 DPL=0 DS   [-WA]
-CS =0028 0000000000000000 00000000 00209a00 DPL=0 CS64 [-R-]
-SS =0030 0000000000000000 00000000 00009300 DPL=0 DS   [-WA]
-DS =0030 0000000000000000 00000000 00009300 DPL=0 DS   [-WA]
-FS =0030 0000000000000000 00000000 00009300 DPL=0 DS   [-WA]
-GS =0030 0000000000000000 00000000 00009300 DPL=0 DS   [-WA]
-LDT=0000 0000000000000000 00000000 00008200 DPL=0 LDT
-TR =0000 0000000000000000 0000ffff 00008b00 DPL=0 TSS64-busy
-GDT=     000000000000edc0 00000037
-IDT=     000000000002e6a0 000000ff
-CR0=80000013 CR2=1fbf7020000772a4 CR3=0000000000058000 CR4=000006a0
-DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 
-DR6=00000000ffff0ff0 DR7=0000000000000400
-CCS=3f7fe0400001a4d9 CCD=1fbff0200000d26c CCO=SARQ    
-EFER=0000000000000501
-```
-
-Now, `CR2=1fbf7020000772a4` is of course a non-canonical address, and therefore should not generate a #PF, rather it should generate a #GP. I also tried to generate a #SS by dereferencing a non-canonical address through the stack, and that also throws a #PF instead of a #SS
-
-```
-check_exception old: 0xffffffff new 0xe
-     0: v=0e e=0001 i=0 cpl=0 IP=0028:fffffffff4bda92a pc=fffffffff4bda92a SP=0030:1fbf7020000772a4 CR2=1fbf70200007729c
-RAX=0000000000000000 RBX=0000000000000000 RCX=0000000000000000 RDX=fffffffff4bdb998
-RSI=0000000000000000 RDI=fffffffff4bdb998 RBP=fffffffff4bdf290 RSP=1fbf7020000772a4
-R8 =0000000000000000 R9 =0000000000000000 R10=0000000000000000 R11=0000000000000000
-R12=0000000000000000 R13=0000000000000000 R14=0000000000000000 R15=0000000000000000
-RIP=fffffffff4bda92a RFL=00000046 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0
-ES =0030 0000000000000000 00000000 00009300 DPL=0 DS   [-WA]
-CS =0028 0000000000000000 00000000 00209a00 DPL=0 CS64 [-R-]
-SS =0030 0000000000000000 00000000 00009300 DPL=0 DS   [-WA]
-DS =0030 0000000000000000 00000000 00009300 DPL=0 DS   [-WA]
-FS =0030 0000000000000000 00000000 00009300 DPL=0 DS   [-WA]
-GS =0030 0000000000000000 00000000 00009300 DPL=0 DS   [-WA]
-LDT=0000 0000000000000000 00000000 00008200 DPL=0 LDT
-TR =0000 0000000000000000 0000ffff 00008b00 DPL=0 TSS64-busy
-GDT=     000000000000edc0 00000037
-IDT=     000000000002e6a0 000000ff
-CR0=80000011 CR2=1fbf70200007729c CR3=00000000bffa5000 CR4=00000020
-```
-Steps to reproduce:
-1. Dereference a non-canonical address
-2. QEMU gives you a page fault instead of a gpf
-3. reconsider life
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/683 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/683
deleted file mode 100644
index adac15e9b..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_TCG/683
+++ /dev/null
@@ -1 +0,0 @@
-certain programs make QEMU crash with "tcg fatal error"
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/766 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/766
deleted file mode 100644
index 749af1da8..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_TCG/766
+++ /dev/null
@@ -1,27 +0,0 @@
-qemu-system-x86_64: Reboot loop after Machine->Reset
-Description of problem:
-When using tcg, the virtual machine goes into a reboot loop after the VM
-is rebooted through UI->Machine->Reboot menu, or through outb(0xcf9, 0xf).
-There might be other reboot mechanisms that result in the same loop.
-
-The loop doesn't occur when using kvm:
-qemu-system-x86_64 -M q35 -enable-kvm
-Steps to reproduce:
-1. Run the command. (The one without -enable-kvm.)
-2. From the UI, click on Machine->Reset.
-3. See that the VM locks up, instead of resetting.
-Additional information:
-The reboot loop occurs because a variable defined by Seabios cannot be updated, possibly because the memory is read-only.
-
-The variable in question is [HaveRunPost](https://github.com/coreboot/seabios/blob/2dd4b9b3f84019668719344b40dba79d681be41c/src/fw/shadow.c#L194). If HaveRunPost is non-zero, the BIOS follows the resume path. When the reset is clicked, the BIOS does indeed gain control and follow the resume path because HaveRunPost is 2. The control ends up at qemu_reboot, which should reset HaveRunPost to 0 and trigger another reset, so that this second time around, the BIOS sees HaveRunPost as 0, and follows the initialization path instead.
-
-But, even though the instruction to update HaveRunPost seems to run, the value remains non-zero (2 to be exact).
-
-```
-        // HaveRunPost has value 2 here.
-        barrier();
-        HaveRunPost = 0;
-        barrier();
-        // If a dprintf(1, "%x\n", HaveRunPost); is placed here, the value printed is 2 and not 0!
-        // With kvm-enabled, this dprintf prints 0.
-```
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/824 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/824
deleted file mode 100644
index b3c4740c9..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_TCG/824
+++ /dev/null
@@ -1,12 +0,0 @@
-x86_64 Translation Block error (cmp eax, 0x6; jnle 0x524)
-Description of problem:
-`Qemu` produces a Translation block of 4 instructions:
-```
-0x0000558a53039ffc: 83f806       (cmp eax, 0x6)
-0x0000558a53039fff: 0f           (nothing)
-0x0000558a53039ffc: 83f806       (cmp eax, 0x6)
-0x0000558a53039fff: 0f8f1e050000 (jnle 0x524)
-```
-This problem occurs several time with different addresses but the same pattern:
-- 1st and 3th instructions are the same (both addresses and opcodes);
-- 2nd is the prefix of the 4th (same addresses).
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/83 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/83
deleted file mode 100644
index 7a8b27c60..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_TCG/83
+++ /dev/null
@@ -1 +0,0 @@
-QEMU x87 emulation of trig and other complex ops is only at 64-bit precision, not 80-bit
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/844 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/844
deleted file mode 100644
index a1fb8dd2b..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_TCG/844
+++ /dev/null
@@ -1,44 +0,0 @@
-Close gap for x86_64-v3 ABI in TCG - CPU support for fma, f16c, avx, avx2 features required
-Description of problem:
-There are 3 additional ABIs defined by a collaboration of vendors for the `x86_64` architecture, over the original baseline:
-
-* https://gitlab.com/x86-psABIs/x86-64-ABI/-/blob/master/x86-64-ABI/low-level-sys-info.tex
-
-This is no problem for KVM assuming suitable host hardware, but TCG is currently unable to support more than the original baseline and the `x86_64-v2` step.  
-
-For `x86_64-v3` there are some gaps in its emulation coverage. This can be seen by taking `Nehalem` which is a good fit for `x86_64-v2`, and requesting the extra v3 features:
-
-```
-$ qemu-system-x86_64 -accel tcg -cpu Nehalem,+avx,+avx2,+bmi1,+bmi2,+f16c,+fma,+abm,+movbe
-qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:ECX.fma [bit 12]
-qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:ECX.avx [bit 28]
-qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:ECX.f16c [bit 29]
-qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.07H:EBX.avx2 [bit 5]
-```
-
-IOW, the strict bare minimum TCG needs in order to satisfy `x86_64-v3` is  `fma`, `f16c`, `avx` and `avx2` support
-
-If we want to fully support a named CPU model satisfying v3, then `Haswell` is the closest and that has a few additional gaps
-
-```
-$ qemu-system-x86_64 -accel tcg -cpu Haswell-noTSX
-qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:ECX.fma [bit 12]
-qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:ECX.pcid [bit 17]
-qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:ECX.x2apic [bit 21]
-qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:ECX.tsc-deadline [bit 24]
-qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:ECX.avx [bit 28]
-qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:ECX.f16c [bit 29]
-qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.07H:EBX.avx2 [bit 5]
-qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.07H:EBX.invpcid [bit 10]
-
-```
-
-Those additional gaps wouldn't impact ability to execute binaries build for the `x86_64-v3` ABI though, so not as important.
-
-The reason `x86_64-v3` compatibility in TCG matters is because sooner or later some Linux OS are going to set this as the baseline for their compiler toolchain.  There is a proposal to set this in `Fedora ELN`, which is what feeds in to a possible future `RHEL-10`.
-
-I imagine adding these extra features would be non-negligible work in TCG / take some time to complete.
-
-Thus I file this bug for the purpose of suggesting these 4 specific missing features be considered a priority to address, compared to other missing CPU features in TCG that might be considered more of a 'nice to have'.
-
-eg looking further the `x86_64-v4` baseline brings in a requirement for `avx512f`, `avx512bw`, `avx512cd`, `avx512dq`, `avx512vl` which TCG also lacks, but I don't think they really need to be considered important at this point in time.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/870 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/870
deleted file mode 100644
index d6224f82d..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_TCG/870
+++ /dev/null
@@ -1,12 +0,0 @@
-Throws a #GP when it should throw a #SS
-Description of problem:
-When stacks are switched as part of a 64-bit mode privilege-level change (resulting from an interrupt), IA-32e mode loads only an inner-level RSP from the TSS. If the value of rsp from tss is a non-canonical form. It will trigger #SS. But when I test it in qemu it throws #GP instead of #SS
-Steps to reproduce:
-In order to confirm that it is the #SS triggered by the non-canonical address, We can verify on a real machine.  
-1. Set the value of the current core's `TSS.IST7` to the the non-canonical address.
-2. Set the `ist` field of the interrupt 4 (Overflow Exception) descriptor to 7.
-3. Execute the `INT 4` instruction in Ring 3 and it will be taken over by the #SS handler.
-
-Repeat the above steps in qemu this exception will be taken over by #GP
-Additional information:
-
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/888 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/888
deleted file mode 100644
index 0884b1368..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_TCG/888
+++ /dev/null
@@ -1,7 +0,0 @@
-TCG <--> KVM behavior difference (TCG bug)
-Description of problem:
-This app couldn't start in TCG mode in QEMU 6.2, but with KVM everything is good. Until version 6.0 it also works with TCG.
-As I checked - problem git commit is 5f9529006ea37560c97b05661a84472431d25b91.
-Steps to reproduce:
-1. Install Allplayer
-2. Try to run it in TCG and KVM mode with QEMU 6.2
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/973 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/973
deleted file mode 100644
index e0a67c1d0..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_TCG/973
+++ /dev/null
@@ -1,19 +0,0 @@
-qemu 6.2 memory leak when failed to boot and infinitely reboot
-Description of problem:
-qemu allocates tons of memory (very likely memory leak) in certain (rare) cases.
-
-When I misconfigured qemu so that I have run a bigger linux kernel within insufficient memory (for example 8M bzImage while 16M ram and no hdd), the kernel will obviously fail to boot. In this case qemu will reboot (likely the linux kernel reboots). However reboot does not solve the problem, causing qemu to repeatedly reboot.
-
-Memory usage of qemu raises sharply in the progress.
-Steps to reproduce:
-1. Get any linux kernel (tested with 5.15.33)
-2. Run the kernel on qemu, with memory smaller than necessary
-Additional information:
-A reproducing dockerfile:
-```
-FROM alpine:3.15
-
-RUN apk add qemu-system-x86_64 linux-virt
-
-CMD ["/usr/bin/qemu-system-x86_64", "-kernel", "/boot/vmlinuz-virt", "-nographic", "-net", "none", "-m", "16M"]
-```
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/984 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/984
deleted file mode 100644
index 49f544941..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_TCG/984
+++ /dev/null
@@ -1,23 +0,0 @@
-QEMU i386 fldl instruction is affected by the precision control bits of the FPU control word
-Description of problem:
-~~The QEMU softfloat float64_to_floatx80 implementation is broken and does not produce correct results.~~ QEMU i386 fldl instruction is affected by the precision control bits of the FPU control word.
-
-```
-IN = 1234.567890 (0x40934a4584f4c6e7)
-OUT = 1234.567871 (0x40099a522c0000000000)
-```
-
-This bug was introduced in the QEMU commit qemu/qemu@8ae5719 as part of the switchover to FloatParts, and is still present in the latest tag (v7.0.0-rc4 as of now).
-
-Prior to the offending commit:
-
-```
-IN = 1234.567890 (0x40934a4584f4c6e7)
-OUT = 1234.567890 (0x40099a522c27a6373800)
-```
-
-This breaks the i386 emulation of `fldl st(0)` (`helper_fldl_ST0`).
-Steps to reproduce:
-Call `float64_to_floatx80` with the input value of `1234.567890 (0x40934a4584f4c6e7)` and see the returned result.
-Additional information:
-See https://github.com/zephyrproject-rtos/sdk-ng/issues/461
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/993 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/993
deleted file mode 100644
index 5509626af..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_TCG/993
+++ /dev/null
@@ -1,81 +0,0 @@
-Invalid opcode  vzeroupper
-Description of problem:
-Got many invalid opcode error with Fedora 36
-See fedora bug https://bugzilla.redhat.com/show_bug.cgi?id=2076410
-
-Crash stack and disassemble. 
-```
-Downloading separate debug info for /lib64/liblzma.so.5...
-Downloading separate debug info for /home/penghuang/Sources/system-supplied DSO at 0x7fff30f55000...
-[Thread debugging using libthread_db enabled]
-Using host libthread_db library "/lib64/libthread_db.so.1".
-Core was generated by `flatpak remote-add flathub https://flathub.org/repo/flathub.flatpakrepo'.
-Program terminated with signal SIGILL, Illegal instruction.
-#0  0x00007f89783cbe4a in sha512_block_data_order_avx2 () from /lib64/libgnutls.so.30
-[Current thread is 1 (Thread 0x7f8972ada640 (LWP 5083))]
-(gdb) bt
-#0  0x00007f89783cbe4a in sha512_block_data_order_avx2 () from /lib64/libgnutls.so.30
-#1  0x00007f89783bf042 in x86_sha512_update (ctx=0x7f8972ad9090, length=128, data=0x7f8972ad8f90 '\\' <repeats 128 times>, "@\255")
-    at sha-x86-ssse3.c:215
-#2  0x00007f897810879b in nettle_hmac_set_key (outer=<optimized out>, inner=0x7f8972ad9168, state=<optimized out>, 
-    hash=0x7f897848b6c0 <x86_sha384>, key_length=0, key=0x7f89783ff943 "") at /usr/src/debug/nettle-3.7.3-3.fc36.x86_64/hmac.c:83
-#3  0x00007f89783bce3a in wrap_x86_hmac_fast (algo=<optimized out>, nonce=<optimized out>, nonce_size=<optimized out>, key=0x7f89783ff943, 
-    key_size=0, text=0x7f8972ad9430, text_size=48, digest=0x55a79d80b948) at hmac-x86-ssse3.c:294
-#4  0x00007f89782d4b57 in _gnutls_mac_fast (algorithm=GNUTLS_MAC_SHA384, key=0x7f89783ff943, keylen=0, text=0x7f8972ad9430, textlen=48, 
-    digest=0x55a79d80b948) at hash_int.c:167
-#5  0x00007f89782f524d in gnutls_hmac_fast (algorithm=GNUTLS_MAC_SHA384, key=key@entry=0x7f89783ff943, keylen=keylen@entry=0, 
-    ptext=0x7f8972ad9430, ptext_len=ptext_len@entry=48, digest=digest@entry=0x55a79d80b948) at crypto-api.c:640
-#6  0x00007f897830d2ff in _tls13_init_secret2 (prf=0x7f897848f888 <hash_algorithms+168>, psk=<optimized out>, psk@entry=0x0, psk_size=48, 
-    psk_size@entry=0, out=out@entry=0x55a79d80b948) at secrets.c:59
-#7  0x00007f897830d3d0 in _tls13_init_secret (session=session@entry=0x55a79d80a1c0, psk=psk@entry=0x0, psk_size=psk_size@entry=0) at secrets.c:35
-#8  0x00007f89782c66c0 in read_server_hello (datalen=<optimized out>, data=<optimized out>, session=0x55a79d80a1c0) at handshake.c:2097
-#9  _gnutls_recv_handshake (session=session@entry=0x55a79d80a1c0, type=type@entry=GNUTLS_HANDSHAKE_SERVER_HELLO, optional=optional@entry=0, 
-    buf=buf@entry=0x0) at handshake.c:1656
-#10 0x00007f89782c8dbb in handshake_client (session=0x55a79d80a1c0) at handshake.c:3072
-#11 gnutls_handshake (session=0x55a79d80a1c0) at handshake.c:2871
-#12 0x00007f89784a694f in g_tls_connection_gnutls_handshake_thread_handshake (tls=0x55a79d80c250, timeout=<optimized out>, 
-    cancellable=<optimized out>, error=0x7f8972ad9b10) at ../tls/gnutls/gtlsconnection-gnutls.c:968
-#13 0x00007f89784a8942 in handshake_thread (task=0x7f8968007ec0, object=object@entry=0x55a79d80c250, task_data=task_data@entry=0x55a79d766e60, 
-    cancellable=cancellable@entry=0x55a79d748760) at ../tls/base/gtlsconnection-base.c:1564
-#14 0x00007f89784a8c02 in async_handshake_thread (task=<optimized out>, object=0x55a79d80c250, task_data=0x55a79d766e60, 
-    cancellable=0x55a79d748760) at ../tls/base/gtlsconnection-base.c:1848
-#15 0x00007f89882dbaf3 in g_task_thread_pool_thread (thread_data=0x7f8968007ec0, pool_data=<optimized out>) at ../gio/gtask.c:1441
-#16 0x00007f8988111b72 in g_thread_pool_thread_proxy (data=<optimized out>) at ../glib/gthreadpool.c:354
-#17 0x00007f898810f172 in g_thread_proxy (data=0x55a79d7e1360) at ../glib/gthread.c:827
-#18 0x00007f8987efdcc7 in start_thread (arg=<optimized out>) at pthread_create.c:442
-#19 0x00007f8987f82e00 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
-(gdb)
-(gdb) disassemble 
-Dump of assembler code for function sha512_block_data_order_avx2:
-   0x00007f89783cbe00 <+0>:    mov    %rsp,%rax
-   0x00007f89783cbe03 <+3>:    push   %rbx
-   0x00007f89783cbe04 <+4>:    push   %rbp
-   0x00007f89783cbe05 <+5>:    push   %r12
-   0x00007f89783cbe07 <+7>:    push   %r13
-   0x00007f89783cbe09 <+9>:    push   %r14
-   0x00007f89783cbe0b <+11>:    push   %r15
-   0x00007f89783cbe0d <+13>:    sub    $0x520,%rsp
-   0x00007f89783cbe14 <+20>:    shl    $0x4,%rdx
-   0x00007f89783cbe18 <+24>:    and    $0xfffffffffffff800,%rsp
-   0x00007f89783cbe1f <+31>:    lea    (%rsi,%rdx,8),%rdx
-   0x00007f89783cbe23 <+35>:    add    $0x480,%rsp
-   0x00007f89783cbe2a <+42>:    mov    %rdi,0x80(%rsp)
-   0x00007f89783cbe32 <+50>:    mov    %rsi,0x88(%rsp)
-   0x00007f89783cbe3a <+58>:    mov    %rdx,0x90(%rsp)
-   0x00007f89783cbe42 <+66>:    mov    %rax,0x98(%rsp)
-=> 0x00007f89783cbe4a <+74>:    vzeroupper 
-   0x00007f89783cbe4d <+77>:    sub    $0xffffffffffffff80,%rsi
-   0x00007f89783cbe51 <+81>:    mov    (%rdi),%rax
-   0x00007f89783cbe54 <+84>:    mov    %rsi,%r12
-   0x00007f89783cbe57 <+87>:    mov    0x8(%rdi),%rbx
-   0x00007f89783cbe5b <+91>:    cmp    %rdx,%rsi
-   0x00007f89783cbe5e <+94>:    mov    0x10(%rdi),%rcx
-   0x00007f89783cbe62 <+98>:    cmove  %rsp,%r12
-   0x00007f89783cbe66 <+102>:    mov    0x18(%rdi),%rdx
-   0x00007f89783cbe6a <+106>:    mov    0x20(%rdi),%r8
-   0x00007f89783cbe6e <+110>:    mov    0x28(%rdi),%r9
-   0x00007f89783cbe72 <+114>:    mov    0x30(%rdi),%r10
-   0x00007f89783cbe76 <+118>:    mov    0x38(%rdi),%r11
-   0x00007f89783cbe7a <+122>:    jmp    0x7f89783cbe80 <sha512_block_data_order_avx2+128>
-   0x00007f89783cbe7c <+124>:    nopl   0x0(%rax)
-```
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_WHPX/1031 b/gitlab/issues_text/target_i386/host_missing/accel_WHPX/1031
deleted file mode 100644
index 8b2c6e16c..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_WHPX/1031
+++ /dev/null
@@ -1,42 +0,0 @@
-Intel 12th Gen CPU not working with QEMU Hyper-V nested virtualization
-Description of problem:
-When booting with Hyper-V + host-passthrough it gets stuck at tianocore, does not change until I reboot which then loops into windows diagnostics which leads nowhere. Done using Windows 10, tried using newest windows version and 1909.
-
-Specs: Manjaro Gnome 5.15 LTS, i5-12600k, z690 gigabyte aorus elite ddr4, rtx 3070ti.
-
-I’ve spent days trying to figure out what was messing with it and it turned out I could boot when messing with my CPU topology, for some reason my 12th gen + Hyper-V + host-passthrough only works with sockets. Cores and threads above 1 causes boot problems, apart from disabling vme which boots, but the hypervisor does not load.
-
-This fails (normal host-passthrough):
-```
-  <cpu mode="host-passthrough" check="none" migratable="on">
-    <topology sockets="1" dies="1" cores="6" threads="2"/>
-  </cpu>
-```
-
-This boots (-can only change sockets):
-```
-  <cpu mode="host-passthrough" check="none" migratable="on">
-    <topology sockets="12" dies="1" cores="1" threads="1"/>
-  </cpu>
-```
-
-This boots (-no hypervisor):
-```
-<cpu mode="host-passthrough" check="partial" migratable="off">
-    <topology sockets="1" dies="1" cores="6" threads="2"/>
-    <feature policy="disable" name="vme"/>
-  </cpu>
-```
-
-No matter what adjustment I do I cannot change the cores or threads or it will result in a boot failure, host-model just does not work once I boot the machine the host model changes to cooperlake.
-
-My current way of bypassing this is I’ve downloaded the QEMU source code, gone through cpu.c and modified the default skylake-client CPU model to match my CPU, then I added in most of my i5-12600k flags manually, this seems to work with a 35-45% performance drop in CPU and in ram. Without Hyper-V enabled and using the normal host-passthrough I get near bare metal performance.
-
-Tried with multiple versions of QEMU, EDK2, and loads of kernel versions (to add to this my i5-12600k gen does not work on kernel version 5.13 and below) even went ahead to try Ubuntu and had the same problem, my other (i7-9700k) PC works fine with Hyper-V. Also disabled my E-cores through bios resulting in the same issue. CPU pinning the P-cores to the guest does not seem to help.
-Steps to reproduce:
-1. Enable hyper-v in windows features
-2. Restart guest
-3. Boot failure
-Additional information:
-Hyper-V host-passthrough XML:
-https://pst.klgrth.io/paste/yc5wk
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_WHPX/1043 b/gitlab/issues_text/target_i386/host_missing/accel_WHPX/1043
deleted file mode 100644
index cab6db263..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_WHPX/1043
+++ /dev/null
@@ -1,10 +0,0 @@
-QEMU cpu max doesnot work on Windows 11 with ryzen processor and whpx
-Description of problem:
-- System does not boot.
-- WHPX: setting APIC emulation mode in the hypervisor
-- Windows Hypervisor Platform accelerator is operational
-- whpx: injection failed, MSI (0, 0) delivery: 0, dest_mode: 0, trigger mode: 0, vector: 0, lost (c0350005)
-- qemu: WHPX: Unexpected VP exit code 4
-Steps to reproduce:
-1. Windows 11 / Ryzen
-2. qemu-system-x86_64.exe --accel whpx --cpu max
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_WHPX/1137 b/gitlab/issues_text/target_i386/host_missing/accel_WHPX/1137
deleted file mode 100644
index 401e7c5e5..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_WHPX/1137
+++ /dev/null
@@ -1,35 +0,0 @@
-When using qemu-system-x86_64 whpx acceleration, cpu information is set strangely.
-Description of problem:
-When using the guest with whpx acceleration in qemu-system-x86_64, the CPU information of the guest seems to be set strangely.
-
-When the guest is Linux, it seems that individual CPUs are allocated as many as the number of cores when using the -accel whpx option and the -smp option.
-* -smp 4, -smp cores=4, -smp sockes=1, cores=4, threads=1 are all set to have 4 single-core CPUs plugged in
-
-If the guest is Windows, check the information with CPU-Z
- It is recognized as a Pentium 4 and is displayed as a CPU with 1 core and n threads.
-
-Physically, it seems to be set to have n individual CPUs with 1 core plugged in.
-In Windows 11 Home (which seems to be the case for all versions of Windows Home), you cannot give the -smp value more than 5.
-* When booting with the -smp option value of 5 or more, a BSOD saying multiprocessor configuration not supported appears. -smp n, -smp cores=n, -smp sockes=1,cores=n,threads=1 All same symptoms occur
-Steps to reproduce:
-1. Boot Windows or Linux with -accel whpx -smp 4 option (or with the -accel whpx -smp sockets=1,cores=4,threads=1 option to make it deterministic)
-2. For Linux guest, use cat /proc/cpuinfo to check cpu information, for Windows guest, use cpu-z, device manager, task manager, etc. to check cpu information
-3. In the information of the Linux guest, it is displayed as fixed as core id : 0, cpu cores : 1, 
-   In Windows guest, information is displayed as written in "Description of problem" respectively.
-Additional information:
-**Windows 11 Home Guest set to 4 cores :**
-
-qemu-system-x86_64 -M q35 -smp sockets=1,cores=4,threads=1 -m 8g -device qxl-vga,vgamem_mb=256 -display sdl -drive file="Windows 11.vmdk",id=disk,if=none -device ahci,id=ahci -device ide-hd,drive=disk,bus=ahci.0 -rtc base=localtime -usbdevice tablet -accel whpx
-![Windows_Guest](/uploads/7b38889ff4ef20c935f724b0307766c9/Windows_Guest.jpg)
-
-
-**Windows 11 Home Guest set to 5 cores :**
-
-qemu-system-x86_64 -M q35 -smp sockets=1,cores=5,threads=1 -m 8g -device qxl-vga,vgamem_mb=256 -display sdl -drive file="Windows 11.vmdk",id=disk,if=none -device ahci,id=ahci -device ide-hd,drive=disk,bus=ahci.0 -rtc base=localtime -usbdevice tablet -accel whpx
-![BSOD](/uploads/910378cc73140831d9db5c58cb575bb8/BSOD.jpg)
-
-
-**Linux (Debian 11) guest set to 4 cores :**
-
-qemu-system-x86_64 -M q35 -smp sockets=1,cores=4,threads=1 -m 4g -device qxl-vga,vgamem_mb=256 -display sdl -drive file="debian.vdi",id=disk,if=none -device ahci,id=ahci -device ide-hd,drive=disk,bus=ahci.0 -rtc base=localtime -usbdevice tablet -accel whpx
-![Linux_Guest](/uploads/d1dbb2e38fcba57741c43f0f348297a2/Linux_Guest.jpg)
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_WHPX/2063 b/gitlab/issues_text/target_i386/host_missing/accel_WHPX/2063
deleted file mode 100644
index a2413f2ac..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_WHPX/2063
+++ /dev/null
@@ -1,55 +0,0 @@
-Poor performance with -accel whpx on Server 2022 host, windows 10 guest - missing CPUID hypervisor ident data?
-Description of problem:
-**Performance of Windows 10 x64 QEMU virtual machine is essentially unusable, compared to same image running under Hyper-V on the same host system.**
-
-It appears the VM is not being provided the Hyper-V enlightenment hints while running under QEMU.  The hv-XXX cpu options do not appear applicable to -accel WHPX.
-
-Below are dumps of the 0x40000000 cpuid values on the host, QEMU guest, and Hyper-V guest (exact same .VHD file used, nested virtualization not enabled for this VM).
-
-host:
-- 0x40000000 eax=4000000c ebx=7263694d ecx=666f736f edx=76482074
-- 0x40000001 eax=31237648 ebx=0 ecx=0 edx=0
-- 0x40000002 eax=4f7c ebx=a0000 ecx=2 edx=85d
-- 0x40000003 eax=bfff ebx=2bb9ff ecx=22 edx=71fffbf6
-- 0x40000004 eax=50d1c ebx=fff ecx=0 edx=0
-- 0x40000005 eax=400 ebx=400 ecx=ba00 edx=0
-- 0x40000006 eax=1e00be ebx=0 ecx=0 edx=0
-- 0x40000007 eax=80000007 ebx=3 ecx=0 edx=0
-- 0x40000008 eax=100001 ebx=1 ecx=aaaa edx=0
-- 0x40000009 eax=0 ebx=0 ecx=0 edx=0
-- 0x4000000a eax=0 ebx=0 ecx=0 edx=0
-- 0x4000000b eax=0 ebx=0 ecx=0 edx=0
-- 0x4000000c eax=0 ebx=0 ecx=0 edx=0
-
-qemu guest with -accel whpx : 
-- 0x40000000 eax=40000010 ebx=0 ecx=0 edx=0
-- 0x40000001 eax=0 ebx=0 ecx=0 edx=0
-- 0x40000002 eax=0 ebx=0 ecx=0 edx=0
-- 0x40000003 eax=0 ebx=0 ecx=0 edx=0
-- 0x40000004 eax=0 ebx=0 ecx=0 edx=0
-- 0x40000005 eax=0 ebx=0 ecx=0 edx=0
-- 0x40000006 eax=0 ebx=0 ecx=0 edx=0
-- 0x40000007 eax=0 ebx=0 ecx=0 edx=0
-- 0x40000008 eax=0 ebx=0 ecx=0 edx=0
-- 0x40000009 eax=0 ebx=0 ecx=0 edx=0
-- 0x4000000a eax=0 ebx=0 ecx=0 edx=0
-- 0x4000000b eax=0 ebx=0 ecx=0 edx=0
-- 0x4000000c eax=0 ebx=0 ecx=0 edx=0
-- 0x4000000d eax=0 ebx=0 ecx=0 edx=0
-- 0x4000000e eax=0 ebx=0 ecx=0 edx=0
-- 0x4000000f eax=0 ebx=0 ecx=0 edx=0
-- 0x40000010 eax=225519 ebx=30d40 ecx=0 edx=0
-
-hyperv guest VM: (nested virtualization not enabled)
-- 0x40000000 eax=4000000b ebx=7263694d ecx=666f736f edx=76482074
-- 0x40000001 eax=31237648 ebx=0 ecx=0 edx=0
-- 0x40000002 eax=4f7c ebx=a0000 ecx=2 edx=85d
-- 0x40000003 eax=ae7f ebx=388030 ecx=22 edx=e0bed7b2
-- 0x40000004 eax=40c2c ebx=fff ecx=0 edx=0
-- 0x40000005 eax=f0 ebx=400 ecx=ba00 edx=0
-- 0x40000006 eax=e ebx=0 ecx=0 edx=0
-- 0x40000007 eax=0 ebx=0 ecx=0 edx=0
-- 0x40000008 eax=0 ebx=0 ecx=0 edx=0
-- 0x40000009 eax=0 ebx=0 ecx=0 edx=0
-- 0x4000000a eax=0 ebx=0 ecx=0 edx=0
-- 0x4000000b eax=0 ebx=0 ecx=0 edx=0
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_WHPX/2403 b/gitlab/issues_text/target_i386/host_missing/accel_WHPX/2403
deleted file mode 100644
index 1c9951b30..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_WHPX/2403
+++ /dev/null
@@ -1,14 +0,0 @@
-WHPX accelerator fails to boot guest Windows 7
-Description of problem:
-I get Qemu freezed on Starting Windows screen when trying to boot Windows 7 Professional
-Steps to reproduce:
-1. Run qemu with the above command line and until Starting Windows screen appears.
-2. See qemu freezed.
-Additional information:
-tcg accelerator works ok, though (Windows 7 successfully boots as expected on native hardware):
-
-- `qemu-system-x86_64.exe -accel tcg -cpu Westmere,aes=on,avx=on,sse4.1=on,sse4.2=on,ssse3=on,x2apic=on,xsave=on -m 4G -machine q35 -device qxl-vga,vgamem_mb=64 -hda Windows7_Disk.qcow2 -boot d -cdrom Windows7.iso`
-
-  This bug seems to have the same roots: https://gitlab.com/qemu-project/qemu/-/issues/1859
-
-  ![Capture.PNG](/uploads/f934e620a4b3c157fc34e8ff38470a0b/Capture.PNG){width=579 height=477}
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_WHPX/2782 b/gitlab/issues_text/target_i386/host_missing/accel_WHPX/2782
deleted file mode 100644
index 0258cc6d6..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_WHPX/2782
+++ /dev/null
@@ -1,10 +0,0 @@
-WHPX won't enable x86_64v3 level instructions
-Description of problem:
-x86_64v3 support is not available inside guest
-Steps to reproduce:
-1. Boot the image
-2. Open terminal
-3. Run `/lib64/ld-linux-x86-64.so.2 --help` and check which levels are available in the output
-4. Or run `/lib64/ld-linux-x86-64.so.2 --list-diagnostics | grep isa` and check `isa_1` value (expected 7 for v3 (3 bits being set))
-Additional information:
-Due to this some Linux distribution, like Centos Stream 10, will not be able to boot with WHPX acceleration enabled.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_WHPX/346 b/gitlab/issues_text/target_i386/host_missing/accel_WHPX/346
deleted file mode 100644
index 186613738..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_WHPX/346
+++ /dev/null
@@ -1 +0,0 @@
-Guest refuses to accept keyboard input when accelerated with WHPX
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_WHPX/513 b/gitlab/issues_text/target_i386/host_missing/accel_WHPX/513
deleted file mode 100644
index f5294499b..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_WHPX/513
+++ /dev/null
@@ -1 +0,0 @@
-Qemu/WHPX fails on applying UEFI firmware with -pflash
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_WHPX/934 b/gitlab/issues_text/target_i386/host_missing/accel_WHPX/934
deleted file mode 100644
index edf23fb00..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_WHPX/934
+++ /dev/null
@@ -1,45 +0,0 @@
-VM execution fails for tianocore edk2 ovmf uefi based image on windows whpx
-Description of problem:
-Cannot do a UEFI tianocore boot of image with linux installation.
-
-I think the BIOS/UEFI/firmware when run inside a virtual-machine should be oblivious to the type of hypervisor, just probe and enable the emulated hardware. Maybe WHPX is not enabling pflash devices properly. 
-
-My goal is to create a 40Gb fedora linux image with a on-image UEFI boot sequence that I can 
-1. native boot using ventoy (works)
-2. boot using kvm/qemu in linux (works)
-3. boot using whpx/qemu in windows (no success yet)
-
-My original sequence of steps to reproduce was.
-1. Under Linux, in qemu-vm, create a bootable linux image by installing from the fedora livecd installer
-2. Confirm qemu-VM/fedora installation/UEFI boot works fine under Linux/kvm/qemu. One can see tianocore logo booting up.
-3. reboot to windows
-4. attempt to boot with analogous windows qemu command. confirm boot failure and error message
-5. remove ```-accel whpx``` and rerun, confirm boot succeeds with tianocore image, albeit un-accelarated
-
-It turns out the image creation is not required.
-
-The below works under linux
-```
-XDG_RUNTIME_DIR=/run/user/1000 qemu-system-x86_64 -cpu qemu64 -m 4096 -machine "type=q35" -accel "kvm" -smp "sockets=1,cores=8,threads=1" -boot d -drive "index=0,if=pflash,format=raw,readonly=on,file=/usr/share/edk2/ovmf/OVMF_CODE.fd" -drive "index=1,if=pflash,format=raw,file=/vol/15KJ_Images/vstorage/OVMF_VARS.fd" -drive "index=2,format=raw,file=/vol/15KJ_Images/transcend/m02_lnx.raw.img.vtoy"  -device "virtio-vga-gl" -display "gtk,gl=on" -rtc "base=utc" -net "user" -device "virtio-net,netdev=vmnic" -netdev "user,id=vmnic,net=192.168.20.0/24,dns=192.168.20.3,dhcpstart=192.168.20.15" -qmp tcp:0:5955,server,nowait
-```
-The below does not work under windows
-```
-qemu-system-x86_64 -cpu qemu64 -m 4096 -machine "type=q35,kernel-irqchip=off" -accel whpx -smp "sockets=1,cores=8,threads=1" -boot d -drive "index=0,if=pflash,format=raw,readonly=on,file=C:/vol/scoop_01/scoopg/apps/qemu/current/share/edk2-x86_64-code.fd" -drive "index=1,if=pflash,format=raw,file=E:/vstorage/OVMF_VARS.fd" -drive "index=2,if=virtio,media=disk,format=raw,file=H:\m01_lnx.raw.img" -drive "index=3,if=virtio,media=disk,format=raw,file=H:\gkpics01.raw.img"  -drive "index=4,if=virtio,media=disk,format=vhdx,file=E:\test\sgdata.vhdx" -display gtk -vga virtio -rtc base=utc -netdev user,id=vmnic1,net=192.168.20.0/24,dns=192.168.20.3,dhcpstart=192.168.20.15 -device virtio-net,netdev=vmnic1  -qmp "tcp:127.0.0.1:5955,server,nowait"
-:
-Windows Hypervisor Platform accelerator is operational
-qemu-system-x86_64: WHPX: Failed to emulate MMIO access with EmulatorReturnStatus: 2
-qemu-system-x86_64: WHPX: Failed to exec a virtual processor
-```
-
-The image does boot if one removes the hardware hypervisor argument ```-accel whpx```
-Steps to reproduce:
-The full qemu command with disk images is not required. Just the accel whpx and the pflash devices are sufficient.
-1. Confirm that the VM does not execute with the command
-```
-qemu-system-x86_64 -cpu qemu64 -m 4096 -machine "type=q35,kernel-irqchip=off" -accel whpx -boot c -drive "index=0,if=pflash,format=raw,readonly=on,file=C:/vol/scoop_01/scoopg/apps/qemu/current/share/edk2-x86_64-code.fd"
-```
-2. Confirm that the VM does execute and tianocore logo shoes up when ```-accel whpx ``` is removed.
-Additional information:
-- In the planned changes of Fedora 37, going forward, fedora installer will no longer support installing fresh to machines with legacy BIOS and will necessarily require UEFI boot. This means that there is urgency in allowing this mode of booting. 
-  - https://fedoraproject.org/wiki/Releases/37/ChangeSet
-  - https://fedoraproject.org/wiki/Changes/DeprecateLegacyBIOS
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_WHPX/977 b/gitlab/issues_text/target_i386/host_missing/accel_WHPX/977
deleted file mode 100644
index b973d1972..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_WHPX/977
+++ /dev/null
@@ -1 +0,0 @@
-QEMU 6.2, windows 98 doesn't shutdown properly
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_Xen/2294 b/gitlab/issues_text/target_i386/host_missing/accel_Xen/2294
deleted file mode 100644
index c9b03fa5d..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_Xen/2294
+++ /dev/null
@@ -1 +0,0 @@
-x86 microvm machine stuck under Xen accelerator
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/101 b/gitlab/issues_text/target_i386/host_missing/accel_missing/101
deleted file mode 100644
index f59324b31..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/101
+++ /dev/null
@@ -1 +0,0 @@
-Running a virtual machine on a Haswell system produces machine check events
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/1017 b/gitlab/issues_text/target_i386/host_missing/accel_missing/1017
deleted file mode 100644
index f940a63bc..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/1017
+++ /dev/null
@@ -1,13 +0,0 @@
-Qemu Windows 10 restart bluescreen
-Description of problem:
-after shutting down qemu VM box and open some system programs on Host System, getting Bluescreen
-with following issue - Memory Manangement or shutting down you Host system, getting bluescreen.
-Only after stoppingh using qemu vm reboot system.
-Steps to reproduce:
-1. start qemu vm, ty get some operations
-1. then stop the qemu vm via console comands
-1. rebooting or restarting Host system
-1. by shutting down, you get Bluescreen
-2.
-Additional information:
-
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/1035 b/gitlab/issues_text/target_i386/host_missing/accel_missing/1035
deleted file mode 100644
index 99ea0ac1e..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/1035
+++ /dev/null
@@ -1,16 +0,0 @@
-Hyper-V on KVM does not work on AMD CPUs
-Description of problem:
-Can not enable hytper-v on KVM on AMD 3970x
-```
-[ 3743.647780] SVM: kvm [17094]: vcpu0, guest rIP: 0xfffff8125288d7d7 unimplemented wrmsr: 0xc0010115 data 0x0
-[ 3744.014046] SVM: kvm [17094]: vcpu1, guest rIP: 0xfffff8125288d7d7 unimplemented wrmsr: 0xc0010115 data 0x0
-[ 3744.016101] SVM: kvm [17094]: vcpu2, guest rIP: 0xfffff8125288d7d7 unimplemented wrmsr: 0xc0010115 data 0x0
-[ 3744.018011] SVM: kvm [17094]: vcpu3, guest rIP: 0xfffff8125288d7d7 unimplemented wrmsr: 0xc0010115 data 0x0
-[ 3744.020032] SVM: kvm [17094]: vcpu4, guest rIP: 0xfffff8125288d7d7 unimplemented wrmsr: 0xc0010115 data 0x0
-[ 3744.021834] SVM: kvm [17094]: vcpu5, guest rIP: 0xfffff8125288d7d7 unimplemented wrmsr: 0xc0010115 data 0x0
-[ 3744.023644] SVM: kvm [17094]: vcpu6, guest rIP: 0xfffff8125288d7d7 unimplemented wrmsr: 0xc0010115 data 0x0
-[ 3744.025478] SVM: kvm [17094]: vcpu7, guest rIP: 0xfffff8125288d7d7 unimplemented wrmsr: 0xc0010115 data 0x0
-```
-Additional information:
-Related issue:
-https://bugzilla.kernel.org/show_bug.cgi?id=203477
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/1040 b/gitlab/issues_text/target_i386/host_missing/accel_missing/1040
deleted file mode 100644
index 2b5b836e2..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/1040
+++ /dev/null
@@ -1,6 +0,0 @@
-Windows Server 2016 VM totally freezes spontaneously during the day a couple of times for 1-5 minutes. There is no any logs in it during the freeze
-Description of problem:
-Windows Server 2016 VM totally freezes spontaneously during the day a couple of times for 1-5 minutes. There is no any logs inside VM during the freeze. Timestamp of the last log written into journal is right before the freeze and the pretty next log is right after the freeze is gone. Looks like "black hole". No ping from from the host toward the VM. There is no way to connect to the VM even via spice on virt-manager as well. Seems like the VM is suspending. Htop on the host during the time of the freeze shows 100% load of all eight cores dedicated to the VM. But the host system is available and reachable, the lxc's inside this host is available and reachable as well.
-
-
-![12h_12m_59s_17_Mar_22__1_](/uploads/8874ad0220751fa253f8794c2eb6c2d5/12h_12m_59s_17_Mar_22__1_.png)
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/1041 b/gitlab/issues_text/target_i386/host_missing/accel_missing/1041
deleted file mode 100644
index 5bfaba61b..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/1041
+++ /dev/null
@@ -1,31 +0,0 @@
-x86_64 Auxillary vector reports platform as i686 which doesn't match the linux kernel
-Description of problem:
-Based on the kernel source in the auxiliary vector AT_PLATFORM should be `x86_64` (confirmed by running outside qemu). However qemu sets it to `i686`.
-
-This was originally reported with docker-for-mac, but was reduced on `x86_64` which is why it is pointless
-Steps to reproduce:
-1. Compile the following for x86_64 (statically if you don't want have an x86_64 dynamic linker) (code originally from https://stackoverflow.com/questions/26520163/accessing-auxiliary-vectors-c)
-
-```
-#include <stdio.h>
-#include <elf.h>
-
-int main(int argc, char** argv, char* envp[]) {
-  Elf64_auxv_t *auxv;
-  while(*envp++ != NULL);
-
-  /*from stack diagram above: *envp = NULL marks end of envp*/
-  int i = 0 ;
-  for (auxv = (Elf64_auxv_t *)envp; auxv->a_type != AT_NULL; auxv++)
-    /* auxv->a_type = AT_NULL marks the end of auxv */
-  {
-    if( auxv->a_type == AT_PLATFORM)
-      printf("AT_PLATFORM is: %s\n", ((char*)auxv->a_un.a_val));
-  }
-}
-```
-2. Run with `qemu-x86_64-static`
-3. See `AT_PLATFORM is: i686`
-4. Compare to "real" x86_64 bit system which gives `AT_PLATFORM is: x86_64`
-Additional information:
-I think that adding `#define ELF_PLATFORM "x86_64"` [here](https://gitlab.com/qemu-project/qemu/-/blob/master/linux-user/elfload.c#L134) should work (but I don't fully understand the code). Otherwise we just end up getting the 32-bit case.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/1042 b/gitlab/issues_text/target_i386/host_missing/accel_missing/1042
deleted file mode 100644
index 8e340bf0f..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/1042
+++ /dev/null
@@ -1,20 +0,0 @@
-windows 10 guest freezes the host on shutdown
-Description of problem:
-Windows 10 guest sometimes freezes the QEMU host when shutting down.
-
-There has been a bug reported about this in the past here:
-https://bugs.launchpad.net/qemu/+bug/1580459
-
-I am also using PCI Passthrough with an NVIDIA GPU.
-Some users have claimed to have fixed this issue by enabling Message Signaled-based Interrupts-mode on the PCI Devices the (GPU/HDMI-AUDIO). I have have these enabled and confirmed they are enabled, but the issue still persists.
-
-This bug has been effecting me for over a year, I just never bothered to look deeper into it after I seen the issue still persists after enabling the MSI stuff.
-
-There is something I noticed about this issue. Basically, it appears that I can mostly avoid the issue entirely, by making sure that as the guest is shutting down, that I move the mouse a bit.
-The host almost never freezes if I do this, and only happens very rarely.
-But if I start a shutdown, and just don't move the mouse at all, it is very likely the host will lock up, requiring a complete reboot. I am pretty sure the mouse movement, should be a big clue, because I can consistently reproduce the issue. The issue itself does not (atleast) for me appear to be tied to how long the VM is running or if gaming on it or not, though I have not thoroughly tested this.
-
-I have gone through various kernel/qemu/libvirt updates, the issue occurs in all of them, and has been an issue from the very beginning of my setup.
-Steps to reproduce:
-1. Start Windows 10 guest.
-2. Shutdown Windows 10 guest
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/1047 b/gitlab/issues_text/target_i386/host_missing/accel_missing/1047
deleted file mode 100644
index 5e5d377c1..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/1047
+++ /dev/null
@@ -1,104 +0,0 @@
-Single stepping Windows 10 bootloader results in Assertion `ret < cpu->num_ases && ret >= 0' failed.
-Description of problem:
-When I am trying to debug Windows bootloader, I see an assertion error in QEMU when single stepping some instructions in SeaBIOS.
-
-```
-qemu-system-i386: ../hw/core/cpu-sysemu.c:77: cpu_asidx_from_attrs: Assertion `ret < cpu->num_ases && ret >= 0' failed.                                        
-```
-Steps to reproduce:
-1. Download / construct `w.img`, see above
-2. Start QEMU using `./qemu-system-i386 --drive media=disk,file=w.img,format=raw,index=1 -s -S -enable-kvm`
-3. Start GDB using `gdb --ex 'target remote :::1234' --ex 'hb *0x7c00' --ex c --ex 'si 1000' --ex q`
-4. See error message
-Additional information:
-The GDB script first breaks at 0x7c00, then tries to execute 1000 instructions using single step (`si`). On my machine, after executing around 772 instructions, the assertion error in QEMU happens. 
-Here is an interactive GDB session on my machine. 
-
-```
-(gdb) hb *0x7c00
-Hardware assisted breakpoint 1 at 0x7c00
-(gdb) c
-Continuing.
-
-Breakpoint 1, 0x00007c00 in ?? ()
-(gdb) d
-Delete all breakpoints? (y or n) y
-(gdb) si 770
-0x000f7d7b in ?? ()
-(gdb) x/10i $eip
-=> 0xf7d7b:	mov    $0x7d85,%ebx
-   0xf7d80:	out    %al,$0xb2
-   0xf7d82:	pause  
-   0xf7d84:	hlt    
-   0xf7d85:	mov    %bp,%sp
-   0xf7d88:	jmp    0xf7dd1
-   0xf7d8a:	mov    %cx,%si
-   0xf7d8d:	mov    $0x1,%ax
-   0xf7d91:	add    %al,(%eax)
-   0xf7d93:	callw  0x6b66
-(gdb) si
-0x000f7d80 in ?? ()
-(gdb) info reg
-eax            0xb5                181
-ecx            0x5678              22136
-edx            0x0                 0
-ebx            0x7d85              32133
-esp            0xe96d4             0xe96d4
-ebp            0xfed4              0xfed4
-esi            0xe0346             918342
-edi            0xefd91             982417
-eip            0xf7d80             0xf7d80
-eflags         0x6                 [ IOPL=0 PF ]
-cs             0x8                 8
-ss             0x10                16
-ds             0x10                16
-es             0x10                16
-fs             0x10                16
-gs             0x10                16
-fs_base        0x0                 0
-gs_base        0x0                 0
-k_gs_base      0x0                 0
-cr0            0x11                [ ET PE ]
-cr2            0x0                 0
-cr3            0x0                 [ PDBR=0 PCID=0 ]
-cr4            0x0                 [ ]
-cr8            0x0                 0
-efer           0x0                 [ ]
-...
-mxcsr          0x1f80              [ IM DM ZM OM UM PM ]
-(gdb) si
-0x000f7d82 in ?? ()
-(gdb) info reg
-eax            0xb5                181
-ecx            0x5678              22136
-edx            0x0                 0
-ebx            0x7d85              32133
-esp            0xe96d4             0xe96d4
-ebp            0xfed4              0xfed4
-esi            0xe0346             918342
-edi            0xefd91             982417
-eip            0xf7d82             0xf7d82
-eflags         0x6                 [ IOPL=0 PF ]
-cs             0x8                 8
-ss             0x10                16
-ds             0x10                16
-es             0x10                16
-fs             0x10                16
-gs             0x10                16
-fs_base        0x0                 0
-gs_base        0x0                 0
-k_gs_base      0x0                 0
-cr0            0x11                [ ET PE ]
-cr2            0x0                 0
-cr3            0x0                 [ PDBR=0 PCID=0 ]
-cr4            0x0                 [ ]
-cr8            0x0                 0
-efer           0x0                 [ ]
-...
-mxcsr          0x1f80              [ IM DM ZM OM UM PM ]
-(gdb) si
-Remote connection closed
-(gdb) 
-```
-
-This bug was first incorrectly filed in KVM's bug tracker at <https://bugzilla.kernel.org/show_bug.cgi?id=216003>.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/1098 b/gitlab/issues_text/target_i386/host_missing/accel_missing/1098
deleted file mode 100644
index 11a080831..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/1098
+++ /dev/null
@@ -1,11 +0,0 @@
-make check failed at bios-tables-test
-Description of problem:
-run unit test "make check", failed at
-3/177 qemu:qtest+qtest-x86_64 / qtest-x86_64/bios-tables-test       ERROR           6.59s   killed by signal 6 SIGABRT
-Steps to reproduce:
-1. ./configure --target-list=x86_64-softmmu --disable-xen --enable-sdl --enable-docs --disable-capstone
-2. make -j check V=1
-Additional information:
-Looks like DSDT construction code has been changed but hasn't updated bios-table-test binaries.
-
-See attached diff file.[make_check_failure_dsdt_asl.diff](/uploads/9ed82fbb081863d8991fb0ea72446365/make_check_failure_dsdt_asl.diff)
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/1115 b/gitlab/issues_text/target_i386/host_missing/accel_missing/1115
deleted file mode 100644
index 1d6a89e9f..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/1115
+++ /dev/null
@@ -1,14 +0,0 @@
-qemu 7.0.0 stuck at Windows boot logo with SeaBios and MBR disk
-Description of problem:
-When trying to boot an MBR Windows guest with SeaBios, it is stuck at the blue Windows boot logo, before the loading circle.
-Changing the vGPU doesn't help, 0% cpu load just frozen. Even if I boot a WinPE iso, the same happens.
-Even after 30 minutes, the same.
-Rebooted host multiple times.
-Since SeaBios is the default in qemu and virt-manager I imagine many VMs are installed as MBR and thus will be stuck.
-To boot the VM I have to:
-- switch to UEFI (TianoCore)
-- boot WinPE iso
-- use proprietary software to convert the Windows disk from MBR to GPT
-Then it boots just fine but I imagine not many users will be able to do this.
-Steps to reproduce:
-1. boot Windows image / WinPE iso with SeaBios
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/1131 b/gitlab/issues_text/target_i386/host_missing/accel_missing/1131
deleted file mode 100644
index 20c2a8d87..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/1131
+++ /dev/null
@@ -1,20 +0,0 @@
-Multiboot: could not move values from provided mmap to another address directly.
-Description of problem:
-When using `-kernel` to load a Multiboot file which requires a memory map(MULTIBOOT_MEMORY_INFO flag) and trying to move the values in the provided mmap entries to another address directly, QEMU reboots.
-```c
-xxx = mmap->addr;
-```
-
-When moving with volatile, everything works well:
-```c
-volatile unsigned long long addr = mmap->addr;
-xxx = addr;
-```
-Steps to reproduce:
-1. Source code here: [github/xtexChooser/toop/boot/multiboot/src/multiboot.c](https://github.com/xtexChooser/toop/blob/51153319d4f2320ae9a9277ffffad3f67a335fe9/boot/multiboot/src/multiboot.c#L32)
-2. Minimized reproduce: [gist.github.com/xtexChooser/22017d662c8144b7abcb0b18c2afb09c](https://gist.github.com/xtexChooser/22017d662c8144b7abcb0b18c2afb09c)
-3. I am sure that 0x00001210 is writable, it is empty in the memory map and QEMU works correctly when writing a zero value to here.
-4. The reproducer is available without any module, when it works, it should keep running without any output, if QEMU reboots, the screen should flash as it clears and prints the BIOS information again.
-5. If move with volatile(as the `multiboot_works.c` in reproducer), the reproducer works correctly.
-Additional information:
-#
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/1135 b/gitlab/issues_text/target_i386/host_missing/accel_missing/1135
deleted file mode 100644
index 0f5ea8bf3..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/1135
+++ /dev/null
@@ -1,12 +0,0 @@
-Multiboot: invalid multiboot information block
-Description of problem:
-Breakpoint at 0x85d4, this is the entrypoint of this Multiboot loader.
-According to the Multiboot specification, the EAX register should be a pointer to the Multiboot information block. When I am testing, it is 0x9500. However, when dumping the memory using `dump binary memory`, nearby memory areas are all zeros.
-
-When dumping some bigger memory aeras, I found that the module hasbeen loaded to the memory successfully, altough MBI was broken.
-Steps to reproduce:
-
-Additional information:
-multiboot: [multiboot](/uploads/55fdfcf30ada0af2d00badf11fcd308c/multiboot)
-
-toop: [toop](/uploads/de3b63ae021303c544105ba1498f3373/toop)
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/116 b/gitlab/issues_text/target_i386/host_missing/accel_missing/116
deleted file mode 100644
index a3b038817..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/116
+++ /dev/null
@@ -1 +0,0 @@
-qemu fails under NeXTStep 3.3 when accessing ROM in SCSI-Adapter am53c974
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/1164 b/gitlab/issues_text/target_i386/host_missing/accel_missing/1164
deleted file mode 100644
index d79ec6483..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/1164
+++ /dev/null
@@ -1,17 +0,0 @@
-q35: incorrect values for PCIEXBAR masks
-Description of problem:
-https://lore.kernel.org/all/1fded151ce5ecbf7010427871b908000b2aba9ee.1520867956.git.x1917x@gmail.com/
-
-In function [mch_update_pciexbar](https://gitlab.com/qemu-project/qemu/-/blob/master/hw/pci-host/q35.c#L295)
-
-There are two small issues in PCIEXBAR address mask handling:
-- wrong bit positions for address mask bits (see PCIEXBAR description
-  in Q35 datasheet)
-- incorrect usage of 64ADR_MASK
-
-Due to this, attempting to write a valid PCIEXBAR address may cause it to
-shift to another address, causing memory layout corruption where emulated
-MMIO regions may overlap real (passed through) MMIO ranges. Fix this
-by providing correct values.
-Additional information:
-Q35 datasheet: https://www.intel.com/Assets/PDF/datasheet/316966.pdf  ( 5.1.16 PCIEXBAR—PCI Express* Register Range Base Address )
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/1267 b/gitlab/issues_text/target_i386/host_missing/accel_missing/1267
deleted file mode 100644
index d41e9792b..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/1267
+++ /dev/null
@@ -1,93 +0,0 @@
-qemu-i386 missing VDSO
-Description of problem:
-Qemu crashes with a segmentation fault when running any binary using qemu-i386. Steps to reproduce are trivial, simply run `qemu-user ./test`. The file is here: [test](/uploads/fe0d498713e79d7e39f417e69ad64c2f/test). Basically any binary compiled with `GOARCH=386` using [TinyGo](https://tinygo.org/) should reproduce this issue.
-I also tried some trivial Go compiled binary and they also crash, but this time with an internal Go error that suggests something is terribly broken over there too: `fatal error: mallocgc called without a P or outside bootstrapping`
-
-Interestingly, qemu-x86_64 and qemu-arm appear to work just fine.
-
-Unfortunately I couldn't get a good backtrace on newer versions. It looks like this in the git version, which I doubt is correct:
-
-```
-~/src/qemu/build$ /bin/lldb ./qemu-i386
-(lldb) target create "./qemu-i386"
-Current executable set to '/home/ayke/src/qemu/build/qemu-i386' (aarch64).
-(lldb) run /home/ayke/src/tinygo/tinygo/test
-Process 97986 launched: '/home/ayke/src/qemu/build/qemu-i386' (aarch64)
-Process 97986 stopped
-* thread #1, name = 'qemu-i386', stop reason = unknown crash reason
-    frame #0: 0x0000fffff78fb9fc libc.so.6`__sigsuspend + 92
-libc.so.6`__sigsuspend:
-->  0xfffff78fb9fc <+92>:  svc    #0
-    0xfffff78fba00 <+96>:  cmn    x0, #0x1, lsl #12         ; =0x1000 
-    0xfffff78fba04 <+100>: b.hi   0xfffff78fba3c            ; <+156>
-    0xfffff78fba08 <+104>: mov    w19, w0
-(lldb) bt
-* thread #1, name = 'qemu-i386', stop reason = unknown crash reason
-  * frame #0: 0x0000fffff78fb9fc libc.so.6`__sigsuspend + 92
-    frame #1: 0x0000aaaaaabfcedc qemu-i386`dump_core_and_abort(target_sig=11) at signal.c:745:5
-    frame #2: 0x0000aaaaaabfc128 qemu-i386`handle_pending_signal(cpu_env=0x0000aaaaaae5d2e0, sig=11, k=0x0000aaaaaae68af8) at signal.c:1061:13
-    frame #3: 0x0000aaaaaabfbe48 qemu-i386`process_pending_signals(cpu_env=0x0000aaaaaae5d2e0) at signal.c:1141:13
-    frame #4: 0x0000aaaaaaae5a04 qemu-i386`cpu_loop(env=0x0000aaaaaae5d2e0) at cpu_loop.c:315:9
-    frame #5: 0x0000aaaaaabf5e7c qemu-i386`main(argc=2, argv=0x0000ffffffffecd8, envp=0x0000ffffffffecf0) at main.c:925:5
-    frame #6: 0x0000fffff78e7b80 libc.so.6`___lldb_unnamed_symbol2945 + 112
-    frame #7: 0x0000fffff78e7c60 libc.so.6`__libc_start_main + 160
-    frame #8: 0x0000aaaaaaae0430 qemu-i386`_start at start.S:81
-(lldb) ^D
-```
-
-I got a better (but still not great) backtrace in Qemu 7.0.0:
-
-```
-~/src/tinygo/tinygo$ /bin/lldb qemu-i386
-(lldb) target create "qemu-i386"
-Current executable set to 'qemu-i386' (aarch64).
-(lldb) run test
-Process 98106 launched: '/usr/bin/qemu-i386' (aarch64)
-Process 98106 stopped
-* thread #1, name = 'qemu-i386', stop reason = signal SIGSEGV: address access protected (fault address: 0x8000)
-    frame #0: 0x0000aaaaaac4b564 qemu-i386`cpu_ldub_code + 32
-qemu-i386`cpu_ldub_code:
-->  0xaaaaaac4b564 <+32>: ldrb   w0, [x0, w1, uxtw]
-    0xaaaaaac4b568 <+36>: str    xzr, [x2]
-    0xaaaaaac4b56c <+40>: ret    
-
-qemu-i386`cpu_lduw_code:
-    0xaaaaaac4b570 <+0>:  mrs    x2, TPIDR_EL0
-(lldb) bt
-* thread #1, name = 'qemu-i386', stop reason = signal SIGSEGV: address access protected (fault address: 0x8000)
-  * frame #0: 0x0000aaaaaac4b564 qemu-i386`cpu_ldub_code + 32
-    frame #1: 0x0000aaaaaac4a4a8 qemu-i386`translator_ldub_swap + 72
-    frame #2: 0x0000aaaaaabe6714 qemu-i386`___lldb_unnamed_symbol6310 + 144
-    frame #3: 0x0000aaaaaabed2e8 qemu-i386`___lldb_unnamed_symbol6311 + 24
-    frame #4: 0x0000aaaaaac4a040 qemu-i386`translator_loop + 400
-    frame #5: 0x0000aaaaaabed5a8 qemu-i386`gen_intermediate_code + 72
-    frame #6: 0x0000aaaaaac486ec qemu-i386`tb_gen_code + 364
-    frame #7: 0x0000aaaaaac43068 qemu-i386`cpu_exec + 1480
-    frame #8: 0x0000aaaaaabaa4b0 qemu-i386`cpu_loop + 208
-    frame #9: 0x0000aaaaaab8cb54 qemu-i386`main + 2020
-    frame #10: 0x0000fffff7687b80 libc.so.6`___lldb_unnamed_symbol2945 + 112
-    frame #11: 0x0000fffff7687c60 libc.so.6`__libc_start_main + 160
-    frame #12: 0x0000aaaaaab8d3b0 qemu-i386`_start + 48
-(lldb) ^D
-```
-
-And an even better backtrace for an even older version (5.2.0). Though I should note that this GDB also had an assertion failue, but the backtrace looks reasonable:
-
-```
-#0  0x0000aaaaaaba7804 in cpu_ldub_code (env=env@entry=0x0, ptr=0) at ../../accel/tcg/user-exec.c:1170
-#1  0x0000aaaaaab40d04 in translator_ldub_swap (do_swap=false, pc=<optimized out>, env=<optimized out>) at ./include/exec/translator.h:176
-#2  translator_ldub (pc=<optimized out>, env=<optimized out>) at ./include/exec/translator.h:176
-#3  x86_ldub_code (env=env@entry=0xaaaaaad809f0, s=s@entry=0xffffffffe990) at ../../target/i386/translate.c:1916
-#4  0x0000aaaaaab51670 in disas_insn (s=s@entry=0xffffffffe990, cpu=<optimized out>, cpu=<optimized out>) at ../../target/i386/translate.c:4506
-#5  0x0000aaaaaab5e1c8 in i386_tr_translate_insn (dcbase=0xffffffffe990, cpu=<optimized out>) at ../../target/i386/translate.c:8569
-#6  0x0000aaaaaabbc9f4 in translator_loop (ops=0xaaaaaacd62b0 <i386_tr_ops>, db=0xffffffffe990, cpu=0xaaaaaad786a0, tb=<optimized out>, max_insns=<optimized out>)
-    at ../../accel/tcg/translator.c:103
-#7  0x0000aaaaaab5e470 in gen_intermediate_code (cpu=cpu@entry=0xaaaaaad786a0, tb=tb@entry=0xffffe8007f00, max_insns=max_insns@entry=512)
-    at ../../target/i386/translate.c:8631
-#8  0x0000aaaaaabcd54c in tb_gen_code (cpu=cpu@entry=0xaaaaaad786a0, pc=pc@entry=0, cs_base=cs_base@entry=0, flags=flags@entry=4194483, cflags=-16777216, 
-    cflags@entry=0) at ../../accel/tcg/translate-all.c:1744
-#9  0x0000aaaaaabbe2a8 in tb_find (cf_mask=0, tb_exit=0, last_tb=0x0, cpu=0xaaaaaad786a0) at ../../accel/tcg/cpu-exec.c:414
-#10 cpu_exec (cpu=cpu@entry=0xaaaaaad786a0) at ../../accel/tcg/cpu-exec.c:770
-#11 0x0000aaaaaab3a438 in cpu_loop (env=env@entry=0xaaaaaad809f0) at ../../linux-user/i386/cpu_loop.c:207
-#12 0x0000aaaaaab1df00 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at ../../linux-user/main.c:882
-```
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/1279 b/gitlab/issues_text/target_i386/host_missing/accel_missing/1279
deleted file mode 100644
index b0e4ebba8..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/1279
+++ /dev/null
@@ -1,8 +0,0 @@
-please assist resolving windows networking issue
-Description of problem:
-After Installation of Windows, for Intel E1000 , Realtek and VirtIO, Windows shows "Error Code 56: Windows is Still Setting Up the Class Configuration For This Device" in device manager and Network won't work
-Steps to reproduce:
-Install Windows 10 VM on Proxmox 7.2 with virtual hardware Version 6.1
-You get the error code above.  When using virtio  nic , during installation of the kvm-qemu-virtio driver/agent package, the installer get's stuck and finally fails.
-
-If you downgrade to virtual hardware 5.1 , the problem goes away.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/1298 b/gitlab/issues_text/target_i386/host_missing/accel_missing/1298
deleted file mode 100644
index 05e2204b3..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/1298
+++ /dev/null
@@ -1,15 +0,0 @@
-virtio-pmem not working on microvm: virtio-pmem missing request data
-Description of problem:
-When using micorvm, qemu does not "connect" the memory backend mem1 with the pmem device. 
-
-When using the first command is executed, qemu shows the following starts message:
-```
-qemu-system-x86_64: virtio-pmem missing request data 
-```
-
-and the kernel outputs following messages:
-```
-[    0.043871] nd_pmem namespace0.0: could not reserve region [mem 0x00000000-0x001fffff]
-[    0.043923] IPI shorthand broadcast: enabled
-[    0.044022] nd_pmem: probe of namespace0.0 failed with error -16
-```
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/1323 b/gitlab/issues_text/target_i386/host_missing/accel_missing/1323
deleted file mode 100644
index 0c39c6193..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/1323
+++ /dev/null
@@ -1,17 +0,0 @@
-qemu-system-x86_64: keyboard not available in cd boot menu
-Description of problem:
-While CD boot menu is shown, no keys input affects the CD boot menu
-Steps to reproduce:
-1. Execute qemu-system-x86_64 -m 1536 -cdrom openSUSE-Leap-15.3-GNOME-Live-x86_64-Media.iso
-2. Wait for boot menu
-3. Try to choose entry
-Additional information:
-Also occurs with other ISOs
-
-   ```
-   qemu-system-x86_64 -m 1536 -cdrom debian-10.8.0-amd64-netinst.iso
-   ```
-
-Does not occur with provided edk2 firmware
-
-Does not occur with QEMU emulator version 7.1.0
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/1328 b/gitlab/issues_text/target_i386/host_missing/accel_missing/1328
deleted file mode 100644
index 5abaee710..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/1328
+++ /dev/null
@@ -1,9 +0,0 @@
-Cannot boot any UEFI systems after upgrade edk2-ovmf
-Description of problem:
-After upgrading edk2-ovmf from version 202208-1 to version 202208-3 none of my virtual machines on UEFI (windows and Arch linuw guest) have successfully started.
-
-I'm using Virtual Manager and virt-viewer with virsh.
-Steps to reproduce:
-1. Update edk2-ovmf to 202208-3
-2. Restart all running VM
-3. Vm with UEFI bios cannot boot
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/1348 b/gitlab/issues_text/target_i386/host_missing/accel_missing/1348
deleted file mode 100644
index 8d2666404..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/1348
+++ /dev/null
@@ -1 +0,0 @@
-WIN10 MBR/SeaBIOS/CSM machine hangs at boot (same as  #1115  https://gitlab.com/qemu-project/qemu/-/issues/1115 )
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/1368 b/gitlab/issues_text/target_i386/host_missing/accel_missing/1368
deleted file mode 100644
index 6cfb54ebe..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/1368
+++ /dev/null
@@ -1,38 +0,0 @@
-unexpect rax value
-Description of problem:
-- When I execute "mov -0x8(%rbp), %rax" and "movq 0xb8000, (%rax)", the value of rax should be 0x7fedf but it is 0x7fefe. It is 1 less.
-Steps to reproduce:
-- 1. Code currently executed
-<pre>
-(gdb) x/2i $pc
-=> 0x2202 <vga_init+12>:	mov    -0x8(%rbp),%rax
-   0x2206 <vga_init+16>:	movq   $0xb8000,(%rax)
-</pre>
-- 2. Value of memory address -0x8(%rbp)
-<pre>
-(gdb) x /xg $rbp-0x8
-0x7fec8:	0x000000000007fedf
-</pre>
-- 3. Value of rax before execution
-<pre>
-(gdb) p /x $rax
-$1 = 0xfffffffd
-</pre>
-- 4. Value of rax after execution
-<pre>
-(gdb) p /x $rax
-$1 = 0x7fedf
-</pre>
-It's all right so far.
-- 5. View the current execution code again
-<pre>
-(gdb) x/i $pc
-=> 0x2207 <vga_init+17>:	movl   $0xb8000,(%rax)
-</pre>
-the code address changed from 0x2206 to 0x2207 and the code changed from "movq xx, xx" to "movl xx, xx".<br>
-Now rax is 0x7fedf.
-- 6. After execution<br>
-After executing "movl   $0xb8000,(%rax)"<br>
-The rax change to 0x7fede
-Additional information:
-
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/1382 b/gitlab/issues_text/target_i386/host_missing/accel_missing/1382
deleted file mode 100644
index 3d939e68e..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/1382
+++ /dev/null
@@ -1,40 +0,0 @@
-x86-64 In long mode the Selector Error Code has an improperly encoded Selector Index when dealing with IDT descriptor indexes
-Description of problem:
-When in long mode an IDT descriptor is 16 bytes in size. When an exception is raised where an index to an IDT descriptor entry needs to be encoded in an error code's selector index field it appears that QEMU's software emulation improperly encodes the IDT descriptor index as if each entry is 8 bytes rather than 16. The effect is that the descriptor index is encoded with a value that is double what it should be.
-  
-As an example if I have a *Segment Not Present* (#NP) exception handler (which has a selector error code pushed on the stack) that is raised when I try to generate a software interrupt 0x97 that is marked not present in its IDT descriptor entry - I expect that QEMU would properly encode the value 0x97 in the Selector Index of the Selector Error Code pushed on the stack. Instead, the value stored is actually 0x12E. 0x12E is double the expected value 0x97.
-
-You can observe this errant value in the output of QEMU when using the `-d int` option. I have cut out the unnecessary state information as I'm focussed on the `v=` and `e=`.
-
-     0: v=97 e=0000 i=1 cpl=0 IP=0008:0000000000008a0a pc=0000000000008a0a SP=0010:0000000000007c00      
-     1: v=0b e=0972 i=0 cpl=0 IP=0008:0000000000008a0a pc=0000000000008a0a SP=0010:0000000000007c00 
-
-When I used `int 0x97` to generate the software interrupt it properly shows that `v=97` had occurred in the output above. Because 0x97 was marked not present exception 0x0b (Not Present) was raised as you can see in the second line. The problem is that `e=0972` is a Selector Error Code where *Bits 3..16* contain the value 0x12E instead of 0x97. **It isn't just the display value in QEMU's debug output that is wrong**, as the **Selector Error Code pushed on the interrupt stack is the same erroneous value**. 
-
-This issue doesn't occur if you run QEMU with the `-enable-kvm` option; in BOCHS; or on real hardware. The value in those environments contains a Selector Error Code of 0x4ba. *Bits 3..16* of 0x4ba contains the descriptor index 0x97 as expected. See additional information for more details.
-Steps to reproduce:
-1. Put processor in long mode. 64-bit mode will suffice.
-2. Load an IDT with:
-   - A valid Segment Not Present (#NP) 0x0B Exception Handler. Handler doesn't really need to do anything.
-   - At least one interrupt handler marked *Not Present* higher than 0x00. Interrupt 0x97 as an example.
-3. Raise the interrupt with something like `int 0x097` for this example.
-Additional information:
-In order to test this problem out in other environments like real hardware and virtual machines I wrote a test program on a floppy disk image that can be run on machines and virtual machines that support legacy boot from floppy media (or emulated floppy media). The test program code can be found [in my Github repository](https://github.com/mpetch/SelectorErrorCodeTest). A pre-built [disk image](https://github.com/mpetch/SelectorErrorCodeTest/blob/main/disk.img) is also available.
-
-When the disk image is executed with QEMU using `qemu-system-x86_64 -fda disk.img` the result (with incorrect encoding) can be seen here:
-
-![image](/uploads/02c99f4915956c02c387ba27df693a62/image.png)
-
-When QEMU is run with `qemu-system-x86_64 -fda disk.img -enable-kvm` the result (with correct encoding) can be seen here:
-
-![image](/uploads/9ce7c10fef355e71ac2fdf0e3cb5c80e/image.png)
-
-Correct results are also obtained in BOCHS and real hardware.
-
----
-The [Intel Software Development Manual Volume 3A](https://www.intel.ca/content/www/ca/en/architecture-and-technology/64-ia-32-architectures-software-developer-vol-3a-part-1-manual.html) documents the error code as:
-
-![image](/uploads/a469d4b3d649e1e20a4b1993d73df05c/image.png)
-
----
-#
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/1383 b/gitlab/issues_text/target_i386/host_missing/accel_missing/1383
deleted file mode 100644
index 878b39f93..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/1383
+++ /dev/null
@@ -1 +0,0 @@
-Pentium Pro cpuid capabilities are wrong, resulting in wrong definition of athlon and others
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/1396 b/gitlab/issues_text/target_i386/host_missing/accel_missing/1396
deleted file mode 100644
index 183da3fe2..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/1396
+++ /dev/null
@@ -1,3 +0,0 @@
-Is it possible to emulate QEMU 64 Bit on Windows?
-Description of problem:
-Is it possible to emulate 64 Bit OS on Windows QEMU version? I'm trying to emulate ESXi image but the ESXi says it can only start 32 bit VM's. When I try to start a 64 bit VM from the ESXi I get the error `Task failed on server: Module 'CPUID' power on failed. `.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/141 b/gitlab/issues_text/target_i386/host_missing/accel_missing/141
deleted file mode 100644
index eedc308ce..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/141
+++ /dev/null
@@ -1 +0,0 @@
-qemu-system-x86_64+gdb: unable to correctly disassemble "real mode" (i8086) instructions after attaching to QEMU started with "-S -s" options
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/1410 b/gitlab/issues_text/target_i386/host_missing/accel_missing/1410
deleted file mode 100644
index c6446b025..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/1410
+++ /dev/null
@@ -1,14 +0,0 @@
-system_powerdown only works once
-Description of problem:
-When the guest is configured to sleep on power button events, something in the ACPI states are not restored coming out of resume.  The first call to `system_powerdown` succeeds, but the second after waking the system is rejected in `acpi_pm1_evt_power_down()` since `ar->pm1.evt.en` is zero coming out of the resume path.
-
-There is probably something deeper (or perhaps in seabios?) since removing the test in that handler doesn't cause a second sleep either.
-Steps to reproduce:
-![image](/uploads/60876bde4027c42699f2edf936bd874d/image.png)
-1. Boot a guest configured to sleep when it receives a power button event
-2. `system_powerdown` from the monitor to tell it to sleep
-3. `info status` to verify that it is suspended
-4. Wake the guest, either with `system_wakeup` or moving the mouse or something
-5. `system_powerdown` has no effect
-Additional information:
-This is using qemu-7.2.0 built from source with a Windows 10 guest and IGD GPU+audio passthrough.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/1437 b/gitlab/issues_text/target_i386/host_missing/accel_missing/1437
deleted file mode 100644
index c0295927b..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/1437
+++ /dev/null
@@ -1,6 +0,0 @@
-Nitrux doesn't finish boot process
-Description of problem:
-Boot process doesn't finish
-![imagen](/uploads/787a61359bb79ba644a7d99bf021680e/imagen.png)
-Steps to reproduce:
-1.Load Nitrux ISO
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/1472 b/gitlab/issues_text/target_i386/host_missing/accel_missing/1472
deleted file mode 100644
index fe85c0130..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/1472
+++ /dev/null
@@ -1,5 +0,0 @@
-Parameter 'sgx-epc.0.node' is unexpected
-Description of problem:
-qemu-system-x86_64: Parameter 'sgx-epc.0.node' is unexpected
-Additional information:
-
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/1473 b/gitlab/issues_text/target_i386/host_missing/accel_missing/1473
deleted file mode 100644
index 709bf9c7d..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/1473
+++ /dev/null
@@ -1 +0,0 @@
-how to run qemu with sgx feature enabled
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/1476 b/gitlab/issues_text/target_i386/host_missing/accel_missing/1476
deleted file mode 100644
index dfcd07cab..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/1476
+++ /dev/null
@@ -1 +0,0 @@
-Support for additional CMOS memory banks
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/1492 b/gitlab/issues_text/target_i386/host_missing/accel_missing/1492
deleted file mode 100644
index af14064b4..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/1492
+++ /dev/null
@@ -1,292 +0,0 @@
-[coredump] [git master] qemu-x86_64 segfaults on ppc64le (4K page size) when trying to run android-studio inside chroot
-Description of problem:
-qemu-x86_64 segfaults when trying to run android-studio inside an Arch Linux x86_64 chroot from a Gentoo Linux ppc64le (4K page size) host. Hardware is a Raptor CS Talos 2 Power 9.
-```
-[niko@talos2 ~]$ android-studio 
-/usr/bin/android-studio: line 200: 117922 Segmentation fault      (core dumped) "$JAVA_BIN" -classpath "$CLASS_PATH" ${VM_OPTIONS} "-XX:ErrorFile=$HOME/java_error_in_studio_%p.log" "-XX:HeapDumpPath=$HOME/java_error_in_studio_.hprof" "-Djb.vmOptionsFile=${USER_VM_OPTIONS_FILE:-${VM_OPTIONS_FILE}}" ${IDE_PROPERTIES_PROPERTY} -Djava.system.class.loader=com.intellij.util.lang.PathClassLoader -Didea.strict.classpath=true -Didea.vendor.name=Google -Didea.paths.selector=AndroidStudio2022.1 -Didea.platform.prefix=AndroidStudio -Didea.jre.check=true -Dsplash=true com.intellij.idea.Main "$@"
-```
-Steps to reproduce:
-1. Create an Arch Linux chroot from a bootstrap tarball: https://wiki.archlinux.org/title/Install_Arch_Linux_from_existing_Linux#Method_A:_Using_the_bootstrap_tarball_(recommended)
-2. Chroot into it using the following script:
-```
-#!/bin/bash
-
-basedir="/home/niko/chroots/arch-x86_64"
-cp /etc/resolv.conf ${basedir}/etc/
-cp /usr/bin/qemu-x86_64 ${basedir}/usr/bin/
-sed -i 's!#Server = http://archlinux.mirror.garr.it/archlinux/$repo/os/$arch!Server = http://archlinux.mirror.garr.it/archlinux/$repo/os/$a>
-mount --make-slave --bind  ${basedir} ${basedir}
-mount -t proc none ${basedir}/proc
-mount -t sysfs none ${basedir}/sys/
-mount --make-rslave --rbind /dev ${basedir}/dev
-mount --make-rslave --rbind /run ${basedir}/run
-chroot ${basedir} /bin/bash
-sleep 3
-umount -R ${basedir}/run
-umount -R ${basedir}/dev
-umount ${basedir}/sys
-umount ${basedir}/proc
-umount ${basedir}
-mount | grep chroots | grep arch-x86_64 | grep -v snap
-```
-3. Initialize pacaman keyring and update system:
-```
-# pacman-key --init
-# pacman-key --populate
-# pacman -Syu
-```
-4. Install android-studio from the AUR (download `PKGBUILD` and run `makepkg -s`, finally install the package with `pacman -U <packagename>`): https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=android-studio
-5. Create an unpriviledged account and run `android-studio`
-6. Wait for the crash.
-Additional information:
-```
-Wed 2023-02-15 12:39:32 CET   117922 1000 1000 SIGSEGV present  /home/niko/chroots/arch-x86_64/usr/bin/qemu-x86_64                         >
-talos2 ~ # coredumpctl gdb 117922
-           PID: 117922 (java)
-           UID: 1000 (niko)
-           GID: 1000 (niko)
-        Signal: 11 (SEGV)
-     Timestamp: Wed 2023-02-15 12:39:25 CET (1min 47s ago)
-  Command Line: /usr/bin/qemu-x86_64 /opt/android-studio/jbr/bin/java -classpath /opt/android-studio/lib/util.jar:/opt/android-studio/lib/app.jar:/opt/android-studio/lib/3rd-party-rt.jar:/opt/android-studio/lib/jna.jar:/opt/android-studio/lib/platform-statistics-devkit.jar:/opt/android-studio/lib/jps-model.jar:/opt/android-studio/lib/rd-core.jar:/opt/android-studio/lib/rd-framework.jar:/opt/android-studio/lib/stats.jar:/opt/android-studio/lib/protobuf.jar:/opt/android-studio/lib/external-system-rt.jar:/opt/android-studio/lib/forms_rt.jar:/opt/android-studio/lib/intellij-test-discovery.jar:/opt/android-studio/lib/rd-swing.jar:/opt/android-studio/lib/annotations.jar:/opt/android-studio/lib/groovy.jar:/opt/android-studio/lib/annotations-java5.jar:/opt/android-studio/lib/byte-buddy-agent.jar:/opt/android-studio/lib/error-prone-annotations.jar:/opt/android-studio/lib/externalProcess-rt.jar:/opt/android-studio/lib/grpc-netty-shaded.jar:/opt/android-studio/lib/idea_rt.jar:/opt/android-studio/lib/intellij-coverage-agent-1.0.656.jar:/opt/android-studio/lib/junit.jar:/opt/android-studio/lib/junit4.jar:/opt/android-studio/lib/lz4-java.jar:/opt/android-studio/lib/platform-objectSerializer-annotations.jar:/opt/android-studio/lib/pty4j.jar:/opt/android-studio/lib/rd-text.jar:/opt/android-studio/lib/resources.jar:/opt/android-studio/lib/util_rt.jar:/opt/android-studio/lib/winp.jar:/opt/android-studio/lib/ant/lib/ant.jar:/opt/android-studio/lib/dbus-java-3.2.1.jar:/opt/android-studio/lib/java-utils-1.0.6.jar:/opt/android-studio/lib/jnr-unixsocket-0.23.jar:/opt/android-studio/lib/jnr-ffi-2.1.10.jar:/opt/android-studio/lib/jffi-1.2.19.jar:/opt/android-studio/lib/jffi-1.2.19-native.jar:/opt/android-studio/lib/asm-7.1.jar:/opt/android-studio/lib/asm-commons-7.1.jar:/opt/android-studio/lib/asm-analysis-7.1.jar:/opt/android-studio/lib/asm-tree-7.1.jar:/opt/android-studio/lib/asm-util-7.1.jar:/opt/android-studio/lib/jnr-a64asm-1.0.0.jar:/opt/android-studio/lib/jnr-x86asm-1.0.2.jar:/opt/android-studio/lib/jnr-constants-0.9.12.jar:/opt/android-studio/lib/jnr-enxio-0.21.jar:/opt/android-studio/lib/jnr-posix-3.0.50.jar -Xms256m -Xmx1280m -XX:ReservedCodeCacheSize=512m -XX:+IgnoreUnrecognizedVMOptions -XX:+UseG1GC -XX:SoftRefLRUPolicyMSPerMB=50 -XX:CICompilerCount=2 -XX:+HeapDumpOnOutOfMemoryError -XX:-OmitStackTraceInFastThrow -ea -Dsun.io.useCanonCaches=false $'-Djdk.http.auth.tunneling.disabledSchemes=""' -Djdk.attach.allowAttachSelf=true -Djdk.module.illegalAccess.silent=true -Djna.nosys=true -Djna.boot.library.path= -Didea.vendor.name=Google -Dkotlinx.coroutines.debug=off -Dsun.tools.attach.tmp.only=true -XX:ErrorFile=/home/niko/java_error_in_studio_%p.log -XX:HeapDumpPath=/home/niko/java_error_in_studio_.hprof -Djb.vmOptionsFile=/opt/android-studio/bin/studio64.vmoptions -Djava.system.class.loader=com.intellij.util.lang.PathClassLoader -Didea.strict.classpath=true -Didea.vendor.name=Google -Didea.paths.selector=AndroidStudio2022.1 -Didea.platform.prefix=AndroidStudio -Didea.jre.check=true -Dsplash=true com.intellij.idea.Main
-    Executable: /home/niko/chroots/arch-x86_64/usr/bin/qemu-x86_64
- Control Group: /user.slice/user-1000.slice/user@1000.service/session.slice/vte-spawn-a3a4897b-7df3-4b3e-a8fc-91898d4e7b51.scope
-          Unit: user@1000.service
-     User Unit: vte-spawn-a3a4897b-7df3-4b3e-a8fc-91898d4e7b51.scope
-         Slice: user-1000.slice
-     Owner UID: 1000 (niko)
-       Boot ID: 33cad872d21043ebbe3dd6581bdd28c6
-    Machine ID: b3e834569b8ff461391f5ac061feb773
-      Hostname: talos2
-       Storage: /var/lib/systemd/coredump/core.java.1000.33cad872d21043ebbe3dd6581bdd28c6.117922.1676461165000000.zst (present)
-  Size on Disk: 226.7M
-       Message: Process 117922 (java) of user 1000 dumped core.
-
-GNU gdb (Gentoo 12.1 vanilla) 12.1
-Copyright (C) 2022 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 "powerpc64le-unknown-linux-gnu".
-Type "show configuration" for configuration details.
-For bug reporting instructions, please see:
-<https://bugs.gentoo.org/>.
-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 /home/niko/chroots/arch-x86_64/usr/bin/qemu-x86_64...
-BFD: warning: /var/tmp/coredump-R9M5K3: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0000002
-BFD: warning: /var/tmp/coredump-R9M5K3: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0010001
-BFD: warning: /var/tmp/coredump-R9M5K3: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0010002
-
-warning: Can't open file /opt/android-studio/jbr/bin/java during file-backed mapping note processing
-
-warning: Can't open file /usr/lib/ld-linux-x86-64.so.2 during file-backed mapping note processing
-
-warning: Can't open file /usr/lib/libpthread.so.0 during file-backed mapping note processing
-
-warning: Can't open file /opt/android-studio/jbr/lib/jli/libjli.so during file-backed mapping note processing
-
-warning: Can't open file /usr/lib/libdl.so.2 during file-backed mapping note processing
-
-warning: Can't open file /usr/lib/libc.so.6 during file-backed mapping note processing
-
-warning: Can't open file /opt/android-studio/jbr/lib/server/libjvm.so during file-backed mapping note processing
-
-warning: Can't open file /usr/lib/libm.so.6 during file-backed mapping note processing
-
-warning: Can't open file /usr/lib/librt.so.1 during file-backed mapping note processing
-
-warning: Can't open file /opt/android-studio/jbr/lib/libverify.so during file-backed mapping note processing
-
-warning: Can't open file /opt/android-studio/jbr/lib/libjava.so during file-backed mapping note processing
-
-warning: Can't open file /opt/android-studio/jbr/lib/libjimage.so during file-backed mapping note processing
-
-warning: Can't open file /tmp/hsperfdata_niko/117922 during file-backed mapping note processing
-
-warning: Can't open file /opt/android-studio/jbr/lib/libzip.so during file-backed mapping note processing
-
-warning: Can't open file /opt/android-studio/jbr/lib/modules during file-backed mapping note processing
-
-warning: Can't open file /opt/android-studio/jbr/lib/libnio.so during file-backed mapping note processing
-
-warning: Can't open file /opt/android-studio/jbr/lib/libnet.so during file-backed mapping note processing
-
-warning: Can't open file /opt/android-studio/lib/util.jar during file-backed mapping note processing
-
-warning: Can't open file /opt/android-studio/lib/app.jar during file-backed mapping note processing
-
-warning: Can't open file /opt/android-studio/lib/3rd-party-rt.jar during file-backed mapping note processing
-
-warning: Can't open file /opt/android-studio/lib/jna.jar during file-backed mapping note processing
-
-warning: Can't open file /opt/android-studio/lib/platform-statistics-devkit.jar during file-backed mapping note processing
-
-warning: Can't open file /opt/android-studio/lib/jps-model.jar during file-backed mapping note processing
-
-warning: Can't open file /opt/android-studio/lib/rd-core.jar during file-backed mapping note processing
-
-warning: Can't open file /opt/android-studio/lib/rd-framework.jar during file-backed mapping note processing
-
-warning: Can't open file /opt/android-studio/lib/stats.jar during file-backed mapping note processing
-
-warning: Can't open file /opt/android-studio/lib/protobuf.jar during file-backed mapping note processing
-
-warning: Can't open file /opt/android-studio/lib/external-system-rt.jar during file-backed mapping note processing
-
-warning: Can't open file /opt/android-studio/lib/forms_rt.jar during file-backed mapping note processing
-
-warning: Can't open file /opt/android-studio/lib/intellij-test-discovery.jar during file-backed mapping note processing
-
-warning: Can't open file /opt/android-studio/lib/rd-swing.jar during file-backed mapping note processing
-
-warning: Can't open file /opt/android-studio/lib/annotations.jar during file-backed mapping note processing
-
-warning: Can't open file /opt/android-studio/lib/groovy.jar during file-backed mapping note processing
-
-warning: Can't open file /opt/android-studio/lib/annotations-java5.jar during file-backed mapping note processing
-
-warning: Can't open file /opt/android-studio/lib/byte-buddy-agent.jar during file-backed mapping note processing
-
-warning: Can't open file /opt/android-studio/lib/error-prone-annotations.jar during file-backed mapping note processing
-
-warning: Can't open file /opt/android-studio/lib/externalProcess-rt.jar during file-backed mapping note processing
-
-warning: Can't open file /opt/android-studio/lib/grpc-netty-shaded.jar during file-backed mapping note processing
-
-warning: Can't open file /opt/android-studio/lib/idea_rt.jar during file-backed mapping note processing
-
-warning: Can't open file /opt/android-studio/lib/intellij-coverage-agent-1.0.656.jar during file-backed mapping note processing
-
-warning: Can't open file /opt/android-studio/lib/junit.jar during file-backed mapping note processing
-
-warning: Can't open file /opt/android-studio/lib/junit4.jar during file-backed mapping note processing
-
-warning: Can't open file /opt/android-studio/lib/lz4-java.jar during file-backed mapping note processing
-
-warning: Can't open file /opt/android-studio/lib/platform-objectSerializer-annotations.jar during file-backed mapping note processing
-
-warning: Can't open file /opt/android-studio/lib/pty4j.jar during file-backed mapping note processing
-
-warning: Can't open file /opt/android-studio/lib/rd-text.jar during file-backed mapping note processing
-
-warning: Can't open file /opt/android-studio/lib/resources.jar during file-backed mapping note processing
-
-warning: Can't open file /opt/android-studio/lib/util_rt.jar during file-backed mapping note processing
-
-warning: core file may not match specified executable file.
-[New LWP 117925]
-[New LWP 117924]
-[New LWP 117930]
-[New LWP 117935]
-[New LWP 117933]
-[New LWP 117928]
-[New LWP 117936]
-[New LWP 117922]
-[New LWP 117927]
-[New LWP 117932]
-[New LWP 117929]
-[New LWP 117937]
-[New LWP 117926]
-[New LWP 117934]
-[New LWP 117931]
-[New LWP 117941]
-[New LWP 117939]
-[New LWP 117938]
-[Thread debugging using libthread_db enabled]
-Using host libthread_db library "/usr/lib64/libthread_db.so.1".
-Core was generated by `/usr/bin/qemu-x86_64 /opt/android-studio/jbr/bin/java -classpath /opt/android-s'.
-Program terminated with signal SIGSEGV, Segmentation fault.
-#0  0x00000000102e1c68 in sigsuspend ()
-[Current thread is 1 (Thread 0x3fffbab18360 (LWP 117925))]
-(gdb) info threads
-  Id   Target Id                          Frame 
-* 1    Thread 0x3fffbab18360 (LWP 117925) 0x00000000102e1c68 in sigsuspend ()
-  2    Thread 0x3fffbb3cf360 (LWP 117924) 0x000000001033afec in syscall ()
-  3    Thread 0x3fffba9d3360 (LWP 117930) 0x000000001037df88 in __futex_abstimed_wait_cancelable64 ()
-  4    Thread 0x3fffba951360 (LWP 117935) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
-  5    Thread 0x3fffba850360 (LWP 117933) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
-  6    Thread 0x3fffbaa55360 (LWP 117928) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
-  7    Thread 0x3fffba910360 (LWP 117936) 0x000000001037df88 in __futex_abstimed_wait_cancelable64 ()
-  8    Thread 0x409e2000 (LWP 117922)     safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
-  9    Thread 0x3fffbaa96360 (LWP 117927) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
-  10   Thread 0x3fffba891360 (LWP 117932) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
-  11   Thread 0x3fffbaa14360 (LWP 117929) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
-  12   Thread 0x3fffba60e360 (LWP 117937) 0x000000001037df88 in __futex_abstimed_wait_cancelable64 ()
-  13   Thread 0x3fffbaad7360 (LWP 117926) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
-  14   Thread 0x3fffba992360 (LWP 117934) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
-  15   Thread 0x3fffbabce360 (LWP 117931) 0x000000001037df88 in __futex_abstimed_wait_cancelable64 ()
-  16   Thread 0x3fffba7ce360 (LWP 117941) 0x000000001037df88 in __futex_abstimed_wait_cancelable64 ()
-  17   Thread 0x3fffba80f360 (LWP 117939) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
-  18   Thread 0x3fffba5cd360 (LWP 117938) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
-(gdb) thread 1
-[Switching to thread 1 (Thread 0x3fffbab18360 (LWP 117925))]
-#0  0x00000000102e1c68 in sigsuspend ()
-(gdb) thread 2
-[Switching to thread 2 (Thread 0x3fffbb3cf360 (LWP 117924))]
-#0  0x000000001033afec in syscall ()
-(gdb) thread 3
-[Switching to thread 3 (Thread 0x3fffba9d3360 (LWP 117930))]
-#0  0x000000001037df88 in __futex_abstimed_wait_cancelable64 ()
-(gdb) thread 4
-[Switching to thread 4 (Thread 0x3fffba951360 (LWP 117935))]
-#0  safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
-75	../common-user/host/ppc64/safe-syscall.inc.S: No such file or directory.
-(gdb) thread 5
-[Switching to thread 5 (Thread 0x3fffba850360 (LWP 117933))]
-#0  safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
-75	in ../common-user/host/ppc64/safe-syscall.inc.S
-(gdb) thread 6
-[Switching to thread 6 (Thread 0x3fffbaa55360 (LWP 117928))]
-#0  safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
-75	in ../common-user/host/ppc64/safe-syscall.inc.S
-(gdb) thread 7
-[Switching to thread 7 (Thread 0x3fffba910360 (LWP 117936))]
-#0  0x000000001037df88 in __futex_abstimed_wait_cancelable64 ()
-(gdb) thread 8
-[Switching to thread 8 (Thread 0x409e2000 (LWP 117922))]
-#0  safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
-75	in ../common-user/host/ppc64/safe-syscall.inc.S
-(gdb) thread 9
-[Switching to thread 9 (Thread 0x3fffbaa96360 (LWP 117927))]
-#0  safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
-75	in ../common-user/host/ppc64/safe-syscall.inc.S
-(gdb) thread 10
-[Switching to thread 10 (Thread 0x3fffba891360 (LWP 117932))]
-#0  safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
-75	in ../common-user/host/ppc64/safe-syscall.inc.S
-(gdb) thread 11
-[Switching to thread 11 (Thread 0x3fffbaa14360 (LWP 117929))]
-#0  safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
-75	in ../common-user/host/ppc64/safe-syscall.inc.S
-(gdb) thread 12
-[Switching to thread 12 (Thread 0x3fffba60e360 (LWP 117937))]
-#0  0x000000001037df88 in __futex_abstimed_wait_cancelable64 ()
-(gdb) thread 13
-[Switching to thread 13 (Thread 0x3fffbaad7360 (LWP 117926))]
-#0  safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
-75	in ../common-user/host/ppc64/safe-syscall.inc.S
-(gdb) thread 14
-[Switching to thread 14 (Thread 0x3fffba992360 (LWP 117934))]
-#0  safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
-75	in ../common-user/host/ppc64/safe-syscall.inc.S
-(gdb) thread 15
-[Switching to thread 15 (Thread 0x3fffbabce360 (LWP 117931))]
-#0  0x000000001037df88 in __futex_abstimed_wait_cancelable64 ()
-(gdb) thread 16
-[Switching to thread 16 (Thread 0x3fffba7ce360 (LWP 117941))]
-#0  0x000000001037df88 in __futex_abstimed_wait_cancelable64 ()
-(gdb) thread 17
-[Switching to thread 17 (Thread 0x3fffba80f360 (LWP 117939))]
-#0  safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
-75	in ../common-user/host/ppc64/safe-syscall.inc.S
-(gdb) thread 18
-[Switching to thread 18 (Thread 0x3fffba5cd360 (LWP 117938))]
-#0  safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
-75	in ../common-user/host/ppc64/safe-syscall.inc.S
-```
-
-Download full coredump: https://drive.google.com/file/d/1t0Tm6-O6THrOFPp8uO-pbHqv8tZ6XWUe/view?usp=share_link
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/1524 b/gitlab/issues_text/target_i386/host_missing/accel_missing/1524
deleted file mode 100644
index f5e11d9d5..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/1524
+++ /dev/null
@@ -1,37 +0,0 @@
-error while loading state for instance 0x0 of device 'kvm-tpr-opt',load of migration failed: Operation not permitted
-Description of problem:
-when i save and restore a guest,it report the error: "error while loading state for instance 0x0 of device 'kvm-tpr-opt',load of migration failed: Operation not permitted"
-Steps to reproduce:
-1.virsh save test ccc.img
-
-2.virsh restore ccc.im
-
-
-it report error:
-
-[root@TOS-9772 ~]# virsh save test ccc.img
-
-[root@TOS-9772 ~]# virsh restore ccc.img
-
-error: Failed to restore domain from ccc.img
-
-error: internal error: qemu unexpectedly closed the monitor: qmp_cmd_name: query-hotpluggable-cpus, arguments: {}
-
-qmp_cmd_name: query-cpus-fast, arguments: {}
-
-qmp_cmd_name: query-iothreads, arguments: {}
-
-qmp_cmd_name: expire_password, arguments: {"protocol": "spice", "time": "never"}
-
-qmp_cmd_name: balloon, arguments: {"value": 1073741824}
-
-qmp_cmd_name: migrate-incoming, arguments: {"uri": "fd:29"}
-
-{"timestamp": {"seconds": 1677661413, "microseconds": 275227}, "event": "MIGRATION", "data": {"status": "setup"}}
-
-{"timestamp": {"seconds": 1677661413, "microseconds": 275600}, "event": "MIGRATION", "data": {"status": "active"}}
-
-2023-03-01T09:03:33.316549Z qemu-system-x86_64: error while loading state for instance 0x0 of device 'kvm-tpr-opt'
-
-2023-03-01T09:03:33.317076Z qemu-system-x86_64: load of migration failed: Operation not permitted
-{"timestamp": {"seconds": 1677661413, "microseconds": 317297}, "event": "MIGRATION", "data": {"status": "failed"}}
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/1533 b/gitlab/issues_text/target_i386/host_missing/accel_missing/1533
deleted file mode 100644
index 5adbd6b39..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/1533
+++ /dev/null
@@ -1 +0,0 @@
-qemu-i386 should not enable feature LM with named CPU models.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/1534 b/gitlab/issues_text/target_i386/host_missing/accel_missing/1534
deleted file mode 100644
index 583990ada..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/1534
+++ /dev/null
@@ -1 +0,0 @@
-usermode emulation warns about features that are system-only (x2apic, tsc-deadline, pcid, invpcid)
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/1570 b/gitlab/issues_text/target_i386/host_missing/accel_missing/1570
deleted file mode 100644
index b020e4570..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/1570
+++ /dev/null
@@ -1,63 +0,0 @@
-Incorrect memory handling when booting redox
-Description of problem:
-During the boot of redox, I regularly get one of two errors when reading the HPET at base address `0xfed00000`:
-- Incorrect translation from virtual address `0xffff8000fed00108` to random physical addresses, e.g. `0xfec00108`
-- Invalid read at addr 0x0, size 8, region 'hpet', reason: invalid size (min:4 max:4)
-Steps to reproduce:
-1. Build the server version of the redox OS as per [the instructions](https://doc.redox-os.org/book/ch02-05-building-redox.html).
-2. Run the qemu command line with multiple CPUs. The more CPUs the easier it is to reproduce.
-3. The problem will manifest itself as a divide by zero error. See the corresponding [redox bug report](https://gitlab.redox-os.org/redox-os/kernel/-/issues/116).
-Additional information:
-The best evidence I have is a debug line I added to qemu before [the memory_region_dispatch_read line](https://gitlab.com/qemu-project/qemu/-/blob/master/accel/tcg/cputlb.c#L1375):
-
-```
-if ((mr_offset & 0x1ff) == 0x108)  fprintf(stderr, "cputlb io_readx cpu %d addr=%llx mr_offset=%llx mr=%p mr->addr=%llx\n", current_cpu->cpu_index, addr,  mr_offset, mr, mr->addr);
-r = memory_region_dispatch_read(mr, mr_offset, &val, op, full->attrs);
-```
-
-That logs:
-
-```
-cputlb io_readx cpu 0 addr=ffff8000fed00108 mr_offset=108 mr=0x7fefb60d5720 mr->addr=fec00000
-```
-
-The expected physical address is `0xfed00000` instead of `0xfec00000`.
-
-A more extensive log is this one:
-```
-55027@1680283224.671665:memory_region_ops_read cpu 5 mr 0x7f9950890130 addr 0xfed000f0 value 0x949707cc size 4 name 'hpet'      <- ok
-55027@1680283224.671681:memory_region_ops_read cpu 5 mr 0x7f9950890130 addr 0xfed000f4 value 0x0 size 4 name 'hpet'             <- ok
-tlb_set_page_full: vaddr=0000000000474000 paddr=0x000000000536f000 prot=5 idx=1
-...
-tlb_flush_by_mmuidx_async_work: mmu_idx:0xffff
-tlb_flush_by_mmuidx_async_work: mmu_idx:0xffff
-tlb_flush_by_mmuidx_async_work: mmu_idx:0xffff
-tlb_flush_by_mmuidx_async_work: mmu_idx:0xffff
-...
-55027@1680283224.671951:memory_region_ops_read cpu 5 mr 0x7f9950882930 addr 0xfec00108 value 0x0 size 4 name 'ioapic'           <- wrong
-55027@1680283224.671958:memory_region_ops_read cpu 5 mr 0x7f9950882930 addr 0xfec0010c value 0x0 size 4 name 'ioapic'
-55027@1680283224.671967:memory_region_ops_write cpu 2 mr 0x7f994d808d30 addr 0xcf8 value 0x8000fa80 size 4 name 'pci-conf-idx'
-55027@1680283224.671986:memory_region_ops_read cpu 2 mr 0x7f994d808e40 addr 0xcfc value 0x80a805 size 4 name 'pci-conf-data'
-55027@1680283224.672001:memory_region_ops_read cpu 5 mr 0x7f9950882930 addr 0xfec00000 value 0x0 size 4 name 'ioapic'           <- wrong
-55027@1680283224.672010:memory_region_ops_read cpu 5 mr 0x7f9950882930 addr 0xfec00004 value 0x0 size 4 name 'ioapic'
-```
-
-Some observations
-- ~I seem to be the only one having this issue. Perhaps because I am the only one developing on MacOS. Maybe it's because I'm running an older intel mac.~. I managed to reproduce this on a Asus vivobook running linux
-- The redox OS [reads the HPET](https://gitlab.redox-os.org/redox-os/kernel/-/blob/master/src/arch/x86_64/time.rs#L11) at addresses `0xf4`, `0x108`, `0x00` in that order. If I change the order to `0x00`, `0xf4`, `0x108`, the problem goes away.
-- Even if I work around the problem by changing the order of the reads, the OS still randomly crashes. This could be related, but I can only speculate on that right now.
-- Increasing qemu debug logging tends to push the problem to the 4vs8 size problem instead of the incorrect address one. The more logging, the more difficult it is to reproduce.
-- I tried to bisect the issue and found I could only reproduce it after qemu version 5.2. However, the mac build broke during this process so I could not find the causal commit. Between 5.1 and 5.2 the performance is greatly increased though and I suspect whatever changed there caused the issue.
-- I can't reproduce the problem with -smp 1
-- I have seen qemu segfault occasionally, but I didn't look further into it and I don't know if it's related to this issue.
-- I have attempted to rule out a bug in redox. I am fairly certain nothing strange is going on there, but I can't say for sure.
-- When I trigger the incorrect address bug, I mostly get  a base address of `0xfec00000` which is the IO APIC. However, I do occasionally see other addresses too
-- `info tlb` at the time of the fault shows
-   ```
-   ffff8000fd3e6000: 00000000fd3e6000 X--DA---W
-   ffff8000fd3e7000: 00000000fd3e7000 X--DA---W
-   ffff8000fed00000: 00000000fed00000 X--DAC--W
-   ffff8000fee00000: 00000000fee00000 X--DA---W
-   fffffd8000000000: 0000000001e32000 XG-DA---W
-   fffffd8000001000: 0000000001e36000 XG-DA---W
-   ```
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/1628 b/gitlab/issues_text/target_i386/host_missing/accel_missing/1628
deleted file mode 100644
index 6e1c1f6eb..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/1628
+++ /dev/null
@@ -1,130 +0,0 @@
-windows 10 display scale will cause an exception
-Description of problem:
-windows dispaly sacle 150% or higher,  windows system will exception
-Steps to reproduce:
-1.  windows dispaly sacle 150%
-Additional information:
-- code in: qemu/hw/display/qxl-render.c
-
-static void qxl_unpack_chunks(void *dest, size_t size, PCIQXLDevice *qxl,
-                              QXLDataChunk *chunk, uint32_t group_id)
-{
-    uint32_t max_chunks = 32;
-    size_t offset = 0;
-    size_t bytes;
-    for (;;) {
-        bytes = MIN(size - offset, chunk->data_size);
-        memcpy(dest + offset, chunk->data, bytes);
-        offset += bytes;
-        if (offset == size) {
-            return;
-        }
-        chunk = qxl_phys2virt(qxl, chunk->next_chunk, group_id,
-                              sizeof(QXLDataChunk) + chunk->data_size);
-         **// get next chunk, but the chunk size use current chunk's data size, not next chunk's data size!!!!**
-         **// if next chunk alloc size < current chunk's data size, there will be exception **
-         
-        if (!chunk) {
-            return;
-        }
-        max_chunks--;
-        if (max_chunks == 0) {
-            return;
-        }
-    }
-}
-
-
-
-- code in: qxl_wddm_dod/QXLDod.cpp exist next chunk alloc size < current chunk's data size 
-
-NTSTATUS  QxlDevice::SetPointerShape(_In_ CONST DXGKARG_SETPOINTERSHAPE* pSetPointerShape)
-{
-.....
-    res = (Resource *)AllocMem(MSPACE_TYPE_VRAM, CURSOR_ALLOC_SIZE, TRUE);  // here we all the first QXLDataChunk , and alloc_size = (CURSOR_ALLOC_SIZE - sizeof(Resource) - sizeof(InternalCursor)) = 8118
-
-.....
-     for (; src != src_end; src += pSetPointerShape->Pitch) {
-        if (!PutBytesAlign(&chunk, &now, &end, src, line_size, PAGE_SIZE - PAGE_SIZE % line_size, NULL)) { // in this function ,we will alloc next QXLDataChunk 
-            ..........
-            break;
-        }
-    }
-}
-
-BOOLEAN QxlDevice::PutBytesAlign(QXLDataChunk **chunk_ptr, UINT8 **now_ptr,
-                            UINT8 **end_ptr, UINT8 *src, int size,
-                            size_t alloc_size, PLIST_ENTRY pDelayed)
-{
-    .....
-    size_t maxAllocSize = BITS_BUF_MAX - BITS_BUF_MAX % size;
-    alloc_size = MIN(alloc_size, maxAllocSize);
-    void *ptr = AllocMem(MSPACE_TYPE_VRAM, alloc_size + sizeof(QXLDataChunk), bForced);  *** //here will  alloc  next  QXLDataChunk  and  alloc_size  = (PAGE_SIZE - PAGE_SIZE % line_size) = 3876 ****
-}
-
-
-eg:
-dispaly sacle 150% ，mouse size will bu change to  57* 55  ，rgba data size = 12540,   we  need three QXLDataChunk  
-
-QXLDataChunk* first;
-first->data_size = 8118;
-first->prev_chunk = 0;
-first->next_chunk=second;
-first->data = [alloc_size(8118), data_size(8118)]
-
-QXLDataChunk* second;
-second->data_size = 3876;
-second->prev_chunk = first;
-second->next_chunk=third;
-second->data = [alloc_size(3876), data_size(3876)]
-
-QXLDataChunk* third;
-third->data_size = 546;
-third->prev_chunk =second;
-third->next_chunk=0;
-third->data = [alloc_size(3876), data_size(546)]
-
-
-chunk = first;
-qxl_phys2virt(qxl, second, group_id, sizeof(QXLDataChunk) + 8118)
-
-
-this size [sizeof(QXLDataChunk) + 8118]  > second  QXLDataChunk's  alloc  size  , will  cause  qxl_get_check_slot_offset check fail
-
-
-for second QXLDataChunk, we actual alloc size  is (sizeof(QXLDataChunk) + 3876),  but we assign (8118 + sizeof(QXLDataChunk))  will cause an exception
-
-
-suggest code :
-
-static void qxl_unpack_chunks(void *dest, size_t size, PCIQXLDevice *qxl,
-                              QXLDataChunk *chunk, uint32_t group_id)
-{
-    uint32_t max_chunks = 32;
-    size_t offset = 0;
-    size_t bytes;
-    QXLPHYSICAL next_chunk_phys = 0; 
-    for (;;) {
-        bytes = MIN(size - offset, chunk->data_size);
-        memcpy(dest + offset, chunk->data, bytes);
-        offset += bytes;
-        if (offset == size) {
-            return;
-        }
-        next_chunk_phys = chunk->next_chunk;
-        chunk = qxl_phys2virt(qxl, next_chunk_phys, group_id,
-                              sizeof(QXLDataChunk));  // fist time, only get the next chunk's data size;
-        if (!chunk) {
-            return;
-        }
-        chunk = qxl_phys2virt(qxl, next_chunk_phys, group_id,
-                              sizeof(QXLDataChunk) + chunk->data_size); // second time, check data size and get data;
-        if (!chunk) {
-            return;
-        }
-        max_chunks--;
-        if (max_chunks == 0) {
-            return;
-        }
-    }
-}
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/1648 b/gitlab/issues_text/target_i386/host_missing/accel_missing/1648
deleted file mode 100644
index 653700577..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/1648
+++ /dev/null
@@ -1,58 +0,0 @@
-linux-user: incorrect alignment of sigframe::pretcode & rt_sigframe::pretcode cause crash
-Description of problem:
-Corrent Print Result:
-
-sp: cdd3b4e8
-
-SUCCEEDED!
-
-qemu-x86_64 Print Result:
-
-sp: 2804170
-
-qemu: uncaught target signal 11 (Segmentation fault) - core dumped
-
-Segmentation fault
-
-Reason of Bug:
-
-sigframe::pretcode & rt_sigframe::pretcode must align of 16n-sizeof(void*) instead of 16n, Because rsp align of 16n before instruction "call" in caller, After "call", push address of "call" in caller. sp of begin in callee is 16n-sizeof(void*)
-
-For example on x86_64:
-
-reference to "qemu/linux-user/i386/signal.c"
-
-```
-# define TARGET_FPSTATE_FXSAVE_OFFSET 0
-
-struct rt_sigframe {
-    abi_ulong pretcode;
-    struct target_ucontext uc;
-    struct target_siginfo info;
-    struct target_fpstate fpstate QEMU_ALIGNED(16);
-};
-#define TARGET_RT_SIGFRAME_FXSAVE_OFFSET (                                 \
-    offsetof(struct rt_sigframe, fpstate) + TARGET_FPSTATE_FXSAVE_OFFSET)
-```
-
-offsetof(struct rt_sigframe, fpstate) align of 16
-
-TARGET_FPSTATE_FXSAVE_OFFSET is 0
-
-TARGET_RT_SIGFRAME_FXSAVE_OFFSET is 16n, also alignment of fxsave is 64
-
-so address of rt_sigframe::pretcode is 16n instead of 16n - sizeof(void*), It is incorect!
-
-Fix the bug:
-
-```
-struct rt_sigframe {
-    abi_ulong pretcode;
-    struct target_ucontext uc;
-    struct target_siginfo info;
-    abi_ulong unused QEMU_ALIGNED(16);
-    struct target_fpstate fpstate;
-};
-```
-
-offsetof(struct rt_sigframe, fpstate) is 16n+8, so address of rt_sigframe::pretcode is 16n-8 on x86_64.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/1762 b/gitlab/issues_text/target_i386/host_missing/accel_missing/1762
deleted file mode 100644
index b51374e5a..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/1762
+++ /dev/null
@@ -1,83 +0,0 @@
-Linux RTC issues possibly with RTC_UIE_ON, RTC_UIE_OFF
-Description of problem:
-Running:
-
-```
-hwclock --hctosys
-```
-
-as root, under the running VM using a UEFI bios image, I get:
-
-```
-hwclock: select() to /dev/rtc0 to wait for clock tick timed out
-```
-
-When running the same command on the same disk image but without UEFI,
-that is, just using the SeaBIOS bios, everything works fine.
-
-Running
-
-```
-hwclock --hctosys --directisa
-```
-
-works fine, too.
-
-Running the (compiled) kernel test utility:
-
-
-```
-/usr/src/linux/tools/testing/selftests/rtc/rtctest.c
-
-```
-
-
-```
-TAP version 13
-1..8
-# Starting 8 tests from 2 test cases.
-#  RUN           rtc.date_read ...
-# rtctest.c:49:date_read:Current RTC date/time is 10/07/2023 14:02:11.
-#            OK  rtc.date_read
-ok 1 rtc.date_read
-#  RUN           rtc.date_read_loop ...
-# rtctest.c:88:date_read_loop:Continuously reading RTC time for 30s (with 11ms breaks after every read).
-# rtctest.c:115:date_read_loop:Performed 2752 RTC time reads.
-#            OK  rtc.date_read_loop
-ok 2 rtc.date_read_loop
-#  RUN           rtc.uie_read ...
-# uie_read: Test terminated by timeout
-#          FAIL  rtc.uie_read
-not ok 3 rtc.uie_read
-#  RUN           rtc.uie_select ...
-# rtctest.c:164:uie_select:Expected 0 (0) != rc (0)
-# uie_select: Test terminated by assertion
-#          FAIL  rtc.uie_select
-not ok 4 rtc.uie_select
-#  RUN           rtc.alarm_alm_set ...
-# rtctest.c:202:alarm_alm_set:Alarm time now set to 14:02:52.
-# rtctest.c:214:alarm_alm_set:Expected 0 (0) != rc (0)
-# alarm_alm_set: Test terminated by assertion
-#          FAIL  rtc.alarm_alm_set
-not ok 5 rtc.alarm_alm_set
-#  RUN           rtc.alarm_wkalm_set ...
-# rtctest.c:258:alarm_wkalm_set:Alarm time now set to 10/07/2023 14:02:57.
-# rtctest.c:268:alarm_wkalm_set:Expected 0 (0) != rc (0)
-# alarm_wkalm_set: Test terminated by assertion
-#          FAIL  rtc.alarm_wkalm_set
-not ok 6 rtc.alarm_wkalm_set
-#  RUN           rtc.alarm_alm_set_minute ...
-# rtctest.c:304:alarm_alm_set_minute:Alarm time now set to 14:03:00.
-# rtctest.c:316:alarm_alm_set_minute:Expected 0 (0) != rc (0)
-# alarm_alm_set_minute: Test terminated by assertion
-#          FAIL  rtc.alarm_alm_set_minute
-not ok 7 rtc.alarm_alm_set_minute
-#  RUN           rtc.alarm_wkalm_set_minute ...
-# rtctest.c:360:alarm_wkalm_set_minute:Alarm time now set to 10/07/2023 14:05:00.
-# rtctest.c:370:alarm_wkalm_set_minute:Expected 0 (0) != rc (0)
-# alarm_wkalm_set_minute: Test terminated by assertion
-#          FAIL  rtc.alarm_wkalm_set_minute
-not ok 8 rtc.alarm_wkalm_set_minute
-# FAILED: 2 / 8 tests passed.
-# Totals: pass:2 fail:6 xfail:0 xpass:0 skip:0 error:0
-#
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/189 b/gitlab/issues_text/target_i386/host_missing/accel_missing/189
deleted file mode 100644
index b6d2b0ffc..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/189
+++ /dev/null
@@ -1 +0,0 @@
-Intel GVT-g works in X11, segfaults in wayland
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/191 b/gitlab/issues_text/target_i386/host_missing/accel_missing/191
deleted file mode 100644
index 833d496c5..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/191
+++ /dev/null
@@ -1 +0,0 @@
-qemu64 CPU model is incorrect
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/1919 b/gitlab/issues_text/target_i386/host_missing/accel_missing/1919
deleted file mode 100644
index bd1d4a616..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/1919
+++ /dev/null
@@ -1,20 +0,0 @@
-UEFI SecureCode hangs on MacOs - 8.1.1 / MacOS Ventura
-Description of problem:
-Unable to load edk2 secure boot UEFI code. Non-secure edk2 bios works fine, but secure one hangs during load.
-Steps to reproduce:
-1. Run mentioned command - it should display OVMF logo - but it hangs
-Additional information:
-* edk2-x86_64-code.fd works fine, edk2-x86_64-secure-code.fd not
-* Tested with swtpm and without - doesn't matter
-* TPM access has been observed (when swtpm enabled) - sounds like secure-code validation partially works
-
-To enable TPM:
-```
-   -chardev socket,id=chrtpm,path=mytpm0/swtpm-sock \
-   -tpmdev emulator,id=tpm0,chardev=chrtpm \
-   -device tpm-tis,tpmdev=tpm0 \
-```
-and run swtpm
-```
-swtpm socket --tpm2 --tpmstate dir=mytpm0 --ctrl type=unixio,path=mytpm0/swtpm-sock
-```
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/192 b/gitlab/issues_text/target_i386/host_missing/accel_missing/192
deleted file mode 100644
index 0b8e43d1d..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/192
+++ /dev/null
@@ -1 +0,0 @@
-xv6 Bootloop
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/1932 b/gitlab/issues_text/target_i386/host_missing/accel_missing/1932
deleted file mode 100644
index ca2a573ed..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/1932
+++ /dev/null
@@ -1,12 +0,0 @@
-Broken grab on hover setting
-Description of problem:
-It seems that now qemu implements "static" grab on hover, i.e., it can only be disabled by
-
-1. setting `vmport=off` in `-M` (btw, `pc` or `q35`, doesn't matter)
-2. emulating a usb mouse *and* blacklist/unload the `psmouse` driver on the guest side
-
-while grab on hover setting in the gtk display backend (or frontend?) is seemingly bogus now either way.
-
-Can this be fixed (again?) so that the setting (which can be toggled in the menu "dynamically") can be used to tell this "vmport" thing whether or not it should grab on hover?
-Additional information:
-NIL
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/1947 b/gitlab/issues_text/target_i386/host_missing/accel_missing/1947
deleted file mode 100644
index f66af1b6c..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/1947
+++ /dev/null
@@ -1,20 +0,0 @@
-ACPI (Stop code 0x000000A5) BSOD During Windows XP Professional x64 Edition Setup
-Description of problem:
-When attempting to launch Windows XP Professional x64 Edition setup, the setup crashes with BSOD stop code 0x000000A5 and the following message:
-```
-A problem has been detected and Windows has been shut down to prevent damage to your computer.
-
-If this is the first time you've seen this Stop error screen, restart your computer. If this screen appears again, follow these steps:
-
-The BIOS in this system is not fully ACPI compliant. Please contact your system vendor for an updated BIOS. If you are unable to obtain an updated BIOS or the latest BIOS supplied by your vendor is not ACPI compliant, you can turn off ACPI mode during textmode setup. To do this, press the F7 key when you are prompted to install storage drivers. The system will not notify you that the F7 key was pressed - it will silently disable ACPI and allow you to continue your installation.
-
-Technical information:
-
-*** STOP: 0x000000A5 (0x0000000000000014, 0xFFFFFA80000CBFC6, 0x000000000000008A, 0xFFFFFADFC8E31A90)
-```
-Steps to reproduce:
-1. Obtain a copy of Windows XP Professional x64 Edition SP2.
-2. Run QEMU using the provided command line (with the name & location of your ISO in place of "Windows XP Professional x64 Edition.iso")
-Additional information:
-It appears the bug may be dependent on KVM, I've seen some conflicting results, but with the provided command line removing "accel=kvm" or replacing it with "accel=tcg" changes the BSOD to one about lack of disk space.
-Also, a similar bug occurs with Windows 2000 SP4, but the setup will hang instead of crash. (The hang can be avoided by pressing F5 and selecting "Standard PC" instead of either ACPI option during setup.)
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/1952 b/gitlab/issues_text/target_i386/host_missing/accel_missing/1952
deleted file mode 100644
index 03db29895..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/1952
+++ /dev/null
@@ -1,96 +0,0 @@
-elf-linux-user: segfault caused by invalid loaddr extracted by the ELF loader
-Description of problem:
-Emulating ELF binaries as emitted by Zig may lead to segfault in QEMU, which typically looks like this
-
-```
-$ qemu-x86_64 simple
-fish: Job 1, 'qemu-x86_64 simple' terminated by signal SIGSEGV (Address boundary error)
-```
-Steps to reproduce:
-1. Obtain latest Zig nightly
-2. Compile simple static C program using Zig's ELF linker:
-
-```
-$ echo "int main() { return 0 };" > simple.c
-$ zig build-exe simple.c -lc -target x86_64-linux-musl -fno-lld --image-base 0x1000000
-$ qemu-x86_64 simple
-fish: Job 1, 'qemu-x86_64 simple' terminated by signal SIGSEGV (Address boundary error)
-```
-Additional information:
-Note that running `simple` directly it's correctly mmaped and executed by the kernel:
-
-```
-$ ./simple
-$ echo $status
-0
-``` 
-
-The reason this happens is because of an assumption QEMU's ELF loader makes on the virtual addresses and offsets of `PT_LOAD` segments, namely:
-
-```
-vaddr2 - vaddr1 >= off2 - off1
-```
-
-Typically, to the best of my knowledge, this is conformed to by the linkers in the large, but it is not required at all. Here's a one-line tweak to QEMU's loader that fixes the segfault:
-
-```diff
-diff --git a/linux-user/elfload.c b/linux-user/elfload.c
-index f21e2e0c3d..eabb4fed03 100644
---- a/linux-user/elfload.c
-+++ b/linux-user/elfload.c
-@@ -3211,7 +3211,7 @@ static void load_elf_image(const char *image_name, int image_fd,
-     for (i = 0; i < ehdr->e_phnum; ++i) {
-         struct elf_phdr *eppnt = phdr + i;
-         if (eppnt->p_type == PT_LOAD) {
--            abi_ulong a = eppnt->p_vaddr - eppnt->p_offset;
-+            abi_ulong a = eppnt->p_vaddr & ~(eppnt->p_align - 1);
-             if (a < loaddr) {
-                 loaddr = a;
-             }
-```
-
-The reason why this breaks for ELF binaries emitted by Zig is that while virtual addresses are allocated sequentially or pre-allocated, file offsets are allocated on a best-effort basis wherever there is enough space in the file to fit a given section/segment so that we can move the contents in file while preserving the allocated virtual addresses on a whim. To provide a more concrete example, here's the load segment layout for `simple` as emitted by Zig:
-
-```
-$ readelf -l simple
-
-Elf file type is EXEC (Executable file)
-Entry point 0x1002000
-There are 7 program headers, starting at offset 64
-
-Program Headers:
-  Type           Offset             VirtAddr           PhysAddr
-                 FileSiz            MemSiz              Flags  Align
-  PHDR           0x0000000000000040 0x0000000001000040 0x0000000001000040
-                 0x0000000000000188 0x0000000000000188  R      0x8
-  LOAD           0x0000000000000000 0x0000000001000000 0x0000000001000000
-                 0x00000000000001c8 0x00000000000001c8  R      0x1000
-  LOAD           0x0000000000021000 0x0000000001001000 0x0000000001001000
-                 0x0000000000000078 0x0000000000000078  R      0x1000
-  LOAD           0x0000000000022000 0x0000000001002000 0x0000000001002000
-                 0x000000000000065a 0x000000000000065a  R E    0x1000
-  LOAD           0x0000000000023000 0x0000000001003000 0x0000000001003000
-                 0x0000000000000060 0x0000000000000278  RW     0x1000
-  GNU_EH_FRAME   0x0000000000021064 0x0000000001001064 0x0000000001001064
-                 0x0000000000000014 0x0000000000000014  R      0x4
-  GNU_STACK      0x0000000000000000 0x0000000000000000 0x0000000000000000
-                 0x0000000000000000 0x0000000000000000  RW     0x1
-
- Section to Segment mapping:
-  Segment Sections...
-   00
-   01
-   02     .rodata.str1.1 .rodata .eh_frame .eh_frame_hdr
-   03     .text .init .fini
-   04     .data .got .bss
-   05     .eh_frame_hdr
-   06
-```
-
-As you can see, initially `loaddr := 0x1000000 - 0x0 = 0x1000000`. However, upon iterating over the second load segment, we already get
-
-```
-a := 0x1001000 - 0x21000 = 0xfe000
-```
-
-and since `a < loaddr`, we incorrectly set `loaddr := 0xfe000`.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/1956 b/gitlab/issues_text/target_i386/host_missing/accel_missing/1956
deleted file mode 100644
index 4bea7ec68..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/1956
+++ /dev/null
@@ -1 +0,0 @@
-[x86,microvm] Update microvm documentation with ACPI option
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/1986 b/gitlab/issues_text/target_i386/host_missing/accel_missing/1986
deleted file mode 100644
index 71738b539..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/1986
+++ /dev/null
@@ -1,14 +0,0 @@
-windows install fails with error 0x80070001
-Description of problem:
-I have a windows vm executed via libvirt, I run it on a physical drive passing it into the guest. when I pass it via sata pt and try to install windows 11 on it, the install fails with error 0x80070001. I had an installation there which resulted with periodic bosd when sata pt was used.
-if I pass the /dev node, I don't get the errors but the performance is horrible due to high hdd usage
-I've tested the same setup with ubuntu, doing read and write to the device of multiple GB (200GB~), no issue at all.
-I've opened an issue at virtio-win and it was closed claiming it is a sata pt issue after trying latest virtio-win.
-Steps to reproduce:
-1. define a sata virtio controller
-2. pass a physical sata drive to the guest attached to the sata controller define in step 1
-3. define a windows iso as cdrom
-4. try to install windows on the device
-Additional information:
-[save.xml.txt](/uploads/0b7eb56d5fe00ff11341483d3d47ebed/save.xml.txt)
-[qemu.cmd.txt](/uploads/b948eee1a95321d11136b96352caace0/qemu.cmd.txt)
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/1998 b/gitlab/issues_text/target_i386/host_missing/accel_missing/1998
deleted file mode 100644
index a2cb4ce8c..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/1998
+++ /dev/null
@@ -1,27 +0,0 @@
-acpihp does not work with some common guest kernels
-Description of problem:
-for pc-q35 6.1, 7.2, any guest kernel with `ACPI: Core revision` < 20230331, can not hot plug the nvidia GPUs.
-So basically only guest kernel >= 6.5 can make it work so far.
-But majority of server kernels are still at 4.18, 5.x. I wonder if it possible to be fixed?
-I also don't know is this qemu bug? bios bug? or actually ACPIA's bug?
-
-journal -k report error like following:
-```
-Nov 11 17:53:00 VMTEST kernel: pci 0000:08:00.0: BAR 0: no space for [mem size 0x01000000]
-Nov 11 17:53:00 VMTEST kernel: pci 0000:08:00.0: BAR 0: failed to assign [mem size 0x01000000]
-Nov 11 17:53:00 VMTEST kernel: pci 0000:08:00.0: BAR 6: assigned [mem 0x81800000-0x8187ffff pref]
-Nov 11 17:53:00 VMTEST kernel: pci 0000:08:00.0: BAR 5: assigned [io  0xa000-0xa07f]
-Nov 11 17:53:00 VMTEST kernel: nvidia 0000:08:00.0: enabling device (0000 -> 0003)
-Nov 11 17:53:00 VMTEST kernel: NVRM: This PCI I/O region assigned to your NVIDIA device is invalid:
-                                                NVRM: BAR0 is 0M @ 0x0 (PCI:0000:08:00.0)
-Nov 11 17:53:00 VMTEST kernel: nvidia: probe of 0000:08:00.0 failed with error -1
-```
-Steps to reproduce:
-1. run the instance as I described above
-2. in qemu monitor: device_add vfio-pci,host=0000:06:00.0,id=gpu0,bus=pci.8
-3. login to the vm console then nvidia-smi to see the failure
-
-workaround:
-`ICH9-LPC.acpi-pci-hotplug-with-bridge-support=off` to disable the acpihp then pciehp can make it work.
-Additional information:
-
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2008 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2008
deleted file mode 100644
index c5f340b47..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/2008
+++ /dev/null
@@ -1,12 +0,0 @@
-querying smbios type=1 UUID in Windows not possible when using SMBIOS 64 bit entry
-Description of problem:
-Querying the UUID in Powershell with
-`get-wmiobject win32_computersystemproduct | Select-Object -expandProperty UUID`
-will return no value. When using `-machine 'pc-i440fx-8.1,smbios-entry-point-type=32'` or `-machine 'pc-i440fx-8.0'` the command works as expected. When using `-machine 'pc-i440fx-8.0,smbios-entry-point-type=64'` the issue is also present.
-
-Commit bf376f3020dfd7bcb2c4158b4ffa85c04d44f56d changed the default for machine version 8.1, so that explains that part.
-
-It's not clear to me if this is a bug in QEMU or a bug/limitation of the guest OS when 64 bit entry is used by SMBIOS.
-Additional information:
-Originally reported for Windows 10 in the Proxmox VE community forum (AFAIK the downstream build in Proxmox VE does not patch the relevant code paths):
-https://forum.proxmox.com/threads/136942/
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2020 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2020
deleted file mode 100644
index f2ae85544..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/2020
+++ /dev/null
@@ -1,11 +0,0 @@
-qemu-system-x86_64: ../../hw/rtc/mc146818rtc.c:203: periodic_timer_update: Assertion `lost_clock >= 0' failed.
-Description of problem:
-VM just crashed, likely because of a time / NTP change
-```
-qemu-system-x86_64: ../../hw/rtc/mc146818rtc.c:203: periodic_timer_update: Assertion `lost_clock >= 0' failed.
-2023-12-04 15:51:40.571+0000: shutting down, reason=crashed
-```
-Steps to reproduce:
-1. N/A
-
-/label ~"kind::Bug"
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2064 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2064
deleted file mode 100644
index d452e0679..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/2064
+++ /dev/null
@@ -1,12 +0,0 @@
-QEMU v8.2.0-rc4 and above will not take SMI
-Description of problem:
-Starting from v8.2.0-rc4, the x86 QEMU system will take SMI from an incorrect starting address. Without any firmware relocation, sending an SMI will move the RIP to 0x8000, instead of the traditional 0x38000. This caused the existing UEFI drivers not functional during SMI relocation step.
-
-After some investigation, the issue was caused by this commit: https://github.com/qemu/qemu/commit/b5e0d5d22fbffc3d8f7d3e86d7a2d05a1a974e27. There seems to be 2 issues with this change:
-
-1. This code section https://github.com/qemu/qemu/blob/7425b6277f12e82952cede1f531bfc689bf77fb1/target/i386/tcg/translate.c#L568C1-L572C6 was updated from calculating `cpu_eip` based on `s->pc` to `s->base.pc_next`. This will cause undetermined behavior.
-2. This code section https://github.com/qemu/qemu/blob/7425b6277f12e82952cede1f531bfc689bf77fb1/target/i386/tcg/translate.c#L2848C1-L2869C67 added the routine of updating `new_pc`, which is later used `tcg_gen_addi_tl`. This will cause the `new_pc` to be populated with undesirable value and thus cause faulting behaviors.
-Steps to reproduce:
-1. Launch once booting UEFI firmware, and the system will get stuck at the SMM base relocation logic.
-Additional information:
-I verified that after fixing the 2 issues mentioned above, the SMI can be correctly invoked at desired location.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2070 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2070
deleted file mode 100644
index c8b515883..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/2070
+++ /dev/null
@@ -1,9 +0,0 @@
-TCG acceleration + EDK2  + Secure Boot hangs on boot since qemu 8.2
-Description of problem:
-Since qemu 8.2, using TCG acceleration in combination with EDK2-OVMF UEFI Secure Boot firmware hangs on boot. qemu freezes and keeps a full CPU core busy at 100% while it hangs. The issue does not occur when using KVM acceleration. It also does not occur when not using EDK2-OVMF UEFI firmware. It also does not occur when using the non secure boot EDK2-OVMF UEFI firmware.
-Steps to reproduce:
-1. `git clone https://github.com/systemd/mkosi`
-2. `cd mkosi`
-3. `bin/mkosi --tools-tree=default --tools-tree-distribution=arch --qemu-kvm=no --qemu-firmware=uefi --debug -f qemu`
-Additional information:
-
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2079 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2079
deleted file mode 100644
index 26da6f1d0..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/2079
+++ /dev/null
@@ -1 +0,0 @@
-flaky test: tcg tests, cross-i686-tci runner, "run-memory" test
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2218 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2218
deleted file mode 100644
index f639aa31e..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/2218
+++ /dev/null
@@ -1,12 +0,0 @@
-MIDI playback issue on Windows 98 / 2000 / XP guest
-Description of problem:
-In Windows 98 / 2000 / XP guest, playback MIDI using Windows Media Player will cause audio slow.
-
-In Windows 98 / 2000 / XP guest, playback MP3 or WMA or WAV using Windows Media Player is works OK.
-Steps to reproduce:
-1. In Windows XP guest, open C:\WINDOWS\Media\Flourish.mid using Windows Media Player.
-2. In Windows XP guest, open C:\WINDOWS\System32\OOBE\images\title.wma using Windows Media Player.
-3. In Windows 98 guest, open C:\WINDOWS\Media\Passport.mid using Windows Media Player.
-4. In Windows 98 guest, open C:\WINDOWS\Application Data\Microsoft\WELCOME\WELCOM98.WAV using Windows Media Player.
-Additional information:
-
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/223 b/gitlab/issues_text/target_i386/host_missing/accel_missing/223
deleted file mode 100644
index a33379a99..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/223
+++ /dev/null
@@ -1 +0,0 @@
-guest migration 100% cpu freeze bug
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2244 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2244
deleted file mode 100644
index 810611096..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/2244
+++ /dev/null
@@ -1,46 +0,0 @@
-Regression in 8.2.90: cpu_physical_memory_snapshot_get_dirty: assertion failed
-Description of problem:
-On executing the image from QEMU advent calendar 2014, door 12 the following error is shown and QEMU exists.
-
-On Debian (built on git-repo)
-```
-$ qemu-system-i386 oberon/oberon.qcow2
-qemu-system-i386: ../system/physmem.c:948: cpu_physical_memory_snapshot_get_dirty: Zusicherung »start + length <= snap->end« nicht erfüllt.
-Abgebrochen
-```
-On Windows (built on qemu-9.0.0-rc0.tar.xz)
-```
-$ qemu-system-i386 oberon/oberon.qcow2
-ERROR:../qemu-9.0.0-rc0/system/physmem.c:946:cpu_physical_memory_snapshot_get_dirty: assertion failed: (start + length <= snap->end)
-Bail out! ERROR:../qemu-9.0.0-rc0/system/physmem.c:946:cpu_physical_memory_snapshot_get_dirty: assertion failed: (start + length <= snap->end)
-```
-Steps to reproduce:
-1. Retrieve oberon.tar.xz with `wget http://qemu-advent-calendar.org/2014/download/oberon.tar.xz`
-2. Extract with `tar -xf oberon.tar.xz`
-3. Execute with `qemu-system-i386 oberon/oberon.qcow2`
-Additional information:
-The same error is shown for QEMU advent calendar 2014, door 15 (Plan 9 from Bell Labs) soon after switch to graphical mode.
-
-git bisect result:
-```
-973a724eb006f674301a0c45f34b3c08dee0fe49 is the first bad commit
-commit 973a724eb006f674301a0c45f34b3c08dee0fe49
-Author: Paolo Bonzini <pbonzini@redhat.com>
-Date:   Mon Dec 29 14:48:14 2014 +0100
-
-    vga: implement horizontal pel panning in graphics modes
-    
-    This implements smooth scrolling, as used for example by Commander Keen
-    and Second Reality.
-    
-    Unfortunately, this is not enough to avoid tearing in Commander Keen,
-    because sometimes the wrong start address is used for a frame.
-    On real EGA, the panning register is sampled on every line, while
-    the display start is latched for the next frame at the start of the
-    vertical retrace.  On real VGA, the panning register is also latched,
-    but at the end of the vertical retrace.  It looks like Keen exploits
-    this by only waiting for horizontal retrace when setting the display
-    start, but implementing it breaks the 256-color Keen games...
-    
-    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
-```
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2263 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2263
deleted file mode 100644
index b0d538343..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/2263
+++ /dev/null
@@ -1,28 +0,0 @@
-guest panics when attempting to perform loadvm operation on x86_64 platform with kvm_intel ept=0
-Description of problem:
-The guest experiences a panic when attempting to perform the `loadvm` operation after it has been running for a while on the x86_64 platform with `kvm_intel ept=0`. I'm unsure if this operation is permitted or not, but it functions properly when using `kvm_intel ept=1`.
-Steps to reproduce:
-1. Load the `kvm-intel` module with the parameter `ept=0`.
-2. savevm  
-Boot the first guest using the previous command line and switch to the QEMU console to execute the `savevm` operation. After that, proceed to shutting down the guest.
-3. loadvm  
-Boot the second guest using the same command line and switch to the QEMU console to execute the `loadevm` operation. After that, the guest panics.
-Additional information:
-I have performed some debugging and it seems that the issue lies in the fact that the VMM modifies the guest memory without informing the KVM module. Upon further investigation, I noticed that the `loadvm` operation only restores the memory and does not execute any ioctl to modify the user memory region recorded in the KVM module.
-
-The KVM module calls `kvm_mmu_reset_context()` to unload the current EPT or SPT page table when guest system registers (CR0/CR3/CR4) are restored. However, for EPT, the EPT page table is released directly and can be reconstructed at a later stage. In contrast, for SPT, the KVM only decreases the reference count and retains the outdated SPT page table in the active list that is maintained by the KVM. As a result, this outdated SPT page table is reused later, leading to incorrect mapping.
-
-To address this, I attempted to call `kvm_arch_flush_shadow_all()` to zap all the page tables in `kvm_mmu_reset_context()`, which allowed the guest to function properly with SPT after the `loadvm` operation.
-
-Therefore, I believe that QEMU should notify the KVM to clear all the page tables if the KVM is using shadow paging. However, it appears that there is no appropriate ioctl available for the VMM to achieve this.
-
-guest panic output:
-![image](/uploads/f7f3ad03c9bc5633105788f784b0544a/image.png)
-
-Trace the `kvm_mmu_get_page()` event and observe that only one record indicates that the outdated page table is reused instead of being recreated.
-
-
-```shell
-perf record -a -e kvmmmu:kvm_mmu_get_page
-```
-![image](/uploads/1393aefb585ad80050f8cc5ba7939fc3/image.png)
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2266 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2266
deleted file mode 100644
index cca7971a2..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/2266
+++ /dev/null
@@ -1,69 +0,0 @@
-qemu-system-x86_64: stuck on watchpoint hit
-Description of problem:
-
-Steps to reproduce:
-1. `gcc -O0 -g watch-bug.c -o watch-bug`
-2. `gdb watch-bug`
-3. gdb commands:
-```
-b main
-r
-watch l1
-next  [ correct stop on the next line ]
-next  [ qemu is stuck as watchpoint should be hit ]
-```
-Additional information:
-* NOTE: it works correctly, if 'continue' command is used instead of 'next'
-
-
-`watch-bug.c`
-```c
-int i0;
-long l1;
-
-
-int main(int argc, char* argv[])
-{
-    i0 = argc;
-	l1 = i0 * 7;
-
-    return 0;
-}
-
-```
-
-Log:
-```c
-Log:
-root@qemux86-64:~# gdb watch-bug
-GNU gdb (GDB) 13.2
-Copyright (C) 2023 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-poky-linux".
-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 watch-bug...
-(gdb) b main
-Breakpoint 1 at 0x1134: file watch-bug.c, line 8.
-(gdb) r
-Starting program: /home/root/watch-bug 
-[Thread debugging using libthread_db enabled]
-Using host libthread_db library "/lib/libthread_db.so.1".
-
-Breakpoint 1, main (argc=1, argv=0x7fffffffecd8) at watch-bug.c:8
-8           i0 = argc;
-(gdb) watch l1
-Hardware watchpoint 2: l1
-(gdb) next
-9           l1 = i0 * 7;
-(gdb) next
-```
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2270 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2270
deleted file mode 100644
index de76911ed..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/2270
+++ /dev/null
@@ -1 +0,0 @@
-CPU topology recognition for Ryzen 9 7950X3D
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2320 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2320
deleted file mode 100644
index 701322524..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/2320
+++ /dev/null
@@ -1 +0,0 @@
--Wchar-subscripts warnings in target/i386/tcg/decode-new.c.inc
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2330 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2330
deleted file mode 100644
index af4d247f2..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/2330
+++ /dev/null
@@ -1,73 +0,0 @@
-acpi-erst: divide by zero in make_erst_storage_header()
-Description of problem:
-When we gives `0` to `record_size` for `acpi-erst` device, below code may triggers divide-by-zero.
-
-```c
-static void make_erst_storage_header(ERSTDeviceState *s)
-    ...
-    header->magic = cpu_to_le64(ERST_STORE_MAGIC);
-    header->record_size = cpu_to_le32(s->default_record_size);
-    header->version = cpu_to_le16(0x0100);
-    header->reserved = cpu_to_le16(0x0000);
-
-    /* Compute mapsize */
-    mapsz = s->storage_size / s->default_record_size; // devide-by-zero occurs
-```
-
-`acpi-erst` device refuses invalid value for `record_size` and does appropriate condition check in `check_erst_backend_storage()`, but this check is placed before the function triggering the error when `header->magic` is 0.
-
-```c
-static void check_erst_backend_storage(ERSTDeviceState *s, Error **errp)
-    ...
-    /*
-     * Check if header is uninitialized; HostMemoryBackend inits to 0
-     */
-    if (le64_to_cpu(header->magic) == 0UL) {
-        make_erst_storage_header(s);
-    }
-
-    /* Validity check record_size */
-    record_size = le32_to_cpu(header->record_size);
-    if (!(
-        (record_size) && /* non zero */
-        (record_size >= UEFI_CPER_RECORD_MIN_SIZE) &&
-        (((record_size - 1) & record_size) == 0) && /* is power of 2 */
-        (record_size >= 4096) /* PAGE_SIZE */
-        )) {
-        error_setg(errp, "ERST record_size %u is invalid", record_size);
-        return;
-    }
-```
-Steps to reproduce:
-1. make sure `acpi-erst.backing` doesn't exist in current folder.
-2. run qemu command.
-```bash
-./build/qemu-system-i386 -object memory-backend-file,id=erstnvram,mem-path=acpi-erst.backing,size=0x10000,share=on -device acpi-erst,memdev=erstnvram,record_size=0
-```
-Additional information:
-I built qemu from source code with `--enable-sanitizers`, and backtrace is as follows:
-```bash
-AddressSanitizer:DEADLYSIGNAL
-=================================================================
-==401519==ERROR: AddressSanitizer: FPE on unknown address 0x55bd0616fd53 (pc 0x55bd0616fd53 bp 0x61f000000e80 sp 0x7fffd16e5d90 T0)
-    #0 0x55bd0616fd53 in make_erst_storage_header /home/xxx/qemu/build/../hw/acpi/erst.c:401
-    #1 0x55bd0616fd53 in check_erst_backend_storage /home/xxx/qemu/build/../hw/acpi/erst.c:431
-    #2 0x55bd0616fd53 in erst_realizefn /home/xxx/qemu/build/../hw/acpi/erst.c:973
-    #3 0x55bd06268426 in pci_qdev_realize /home/xxx/qemu/build/../hw/pci/pci.c:2093
-    #4 0x55bd06557629 in device_set_realized /home/xxx/qemu/build/../hw/core/qdev.c:510
-    #5 0x55bd0655ecc8 in property_set_bool /home/xxx/qemu/build/../qom/object.c:2362
-    #6 0x55bd0655cec4 in object_property_set /home/xxx/qemu/build/../qom/object.c:1471
-    #7 0x55bd06560dec in object_property_set_qobject /home/xxx/qemu/build/../qom/qom-qobject.c:28
-    #8 0x55bd0655d30a in object_property_set_bool /home/xxx/qemu/build/../qom/object.c:1541
-    #9 0x55bd0632f8cf in qdev_device_add_from_qdict /home/xxx/qemu/build/../system/qdev-monitor.c:719
-    #10 0x55bd0632fc91 in qdev_device_add /home/xxx/qemu/build/../system/qdev-monitor.c:738
-    #11 0x55bd0633ae7e in device_init_func /home/xxx/qemu/build/../system/vl.c:1203
-    #12 0x55bd066e7a50 in qemu_opts_foreach /home/xxx/qemu/build/../util/qemu-option.c:1135
-    #13 0x55bd06335421 in qemu_create_cli_devices /home/xxx/qemu/build/../system/vl.c:2640
-    #14 0x55bd06335421 in qmp_x_exit_preconfig /home/xxx/qemu/build/../system/vl.c:2709
-    #15 0x55bd06338f42 in qemu_init /home/xxx/qemu/build/../system/vl.c:3742
-    #16 0x55bd06553e35 in main /home/xxx/qemu/build/../system/main.c:47
-    #17 0x7efcdb919d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
-    #18 0x7efcdb919e3f in __libc_start_main_impl ../csu/libc-start.c:392
-    #19 0x55bd060ecb24 in _start (/home/xxx/qemu/build/qemu-system-i386+0x32db24)
-```
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2334 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2334
deleted file mode 100644
index 324a18856..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/2334
+++ /dev/null
@@ -1,252 +0,0 @@
-[9.0.0] qemu breaks mac os vm
-Description of problem:
-Mac OS Monterey vm not able to boot after upgrading qemu to v. 9.0.0; no issue with qemu 8.2.2.
-This vm is booted with opencore latest version.
-The vm is not able to boot, apple logo is displayed on the screen for a bit, then the vm shutdowns, this is quite strange.
-I can't see anything useful in the logs.
-Changing machine type from q35-9.0 back to 8.2 doesn't solve the issue.
-The vm is booted via libvirt (latest version) and it's not a quite "base" vm, it has multiple passthroughs and other things.
-Before testing into details and starting to run base vms to see if it boots,maybe someone can see something wrong or maybe someone has the same issue.
-Reverting back to qemu 8.2.2 fixes all the issues and the vm is able to boot again.
-No issues with a windows 11 vm and with a kali vm.
-I can say that it's not a DSDT issue (a problem I was having in the past was related with DSTD), because injecting the DSDT of the vm started from v 8.2.2 doesn't boot it.
-
-This is the xml of the vm:
-
-```
-<domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'>
-  <name>Monterey</name>
-  <memory unit='KiB'>33554432</memory>
-  <currentMemory unit='KiB'>33554432</currentMemory>
-  <memoryBacking>
-    <nosharepages/>
-  </memoryBacking>
-  <vcpu placement='static' current='28'>32</vcpu>
-  <vcpus>
-    <vcpu id='0' enabled='yes' hotpluggable='no' order='1'/>
-    <vcpu id='1' enabled='yes' hotpluggable='yes' order='2'/>
-    <vcpu id='2' enabled='yes' hotpluggable='yes' order='3'/>
-    <vcpu id='3' enabled='yes' hotpluggable='yes' order='4'/>
-    <vcpu id='4' enabled='yes' hotpluggable='yes' order='5'/>
-    <vcpu id='5' enabled='yes' hotpluggable='yes' order='6'/>
-    <vcpu id='6' enabled='yes' hotpluggable='yes' order='7'/>
-    <vcpu id='7' enabled='yes' hotpluggable='yes' order='8'/>
-    <vcpu id='8' enabled='yes' hotpluggable='yes' order='9'/>
-    <vcpu id='9' enabled='yes' hotpluggable='yes' order='10'/>
-    <vcpu id='10' enabled='yes' hotpluggable='yes' order='11'/>
-    <vcpu id='11' enabled='yes' hotpluggable='yes' order='12'/>
-    <vcpu id='12' enabled='yes' hotpluggable='yes' order='13'/>
-    <vcpu id='13' enabled='yes' hotpluggable='yes' order='14'/>
-    <vcpu id='14' enabled='yes' hotpluggable='yes' order='15'/>
-    <vcpu id='15' enabled='yes' hotpluggable='yes' order='16'/>
-    <vcpu id='16' enabled='yes' hotpluggable='yes' order='17'/>
-    <vcpu id='17' enabled='yes' hotpluggable='yes' order='18'/>
-    <vcpu id='18' enabled='yes' hotpluggable='yes' order='19'/>
-    <vcpu id='19' enabled='yes' hotpluggable='yes' order='20'/>
-    <vcpu id='20' enabled='yes' hotpluggable='yes' order='21'/>
-    <vcpu id='21' enabled='yes' hotpluggable='yes' order='22'/>
-    <vcpu id='22' enabled='yes' hotpluggable='yes' order='23'/>
-    <vcpu id='23' enabled='yes' hotpluggable='yes' order='24'/>
-    <vcpu id='24' enabled='yes' hotpluggable='yes' order='25'/>
-    <vcpu id='25' enabled='yes' hotpluggable='yes' order='26'/>
-    <vcpu id='26' enabled='yes' hotpluggable='yes' order='27'/>
-    <vcpu id='27' enabled='yes' hotpluggable='yes' order='28'/>
-    <vcpu id='28' enabled='no' hotpluggable='yes'/>
-    <vcpu id='29' enabled='no' hotpluggable='yes'/>
-    <vcpu id='30' enabled='no' hotpluggable='yes'/>
-    <vcpu id='31' enabled='no' hotpluggable='yes'/>
-  </vcpus>
-  <iothreads>2</iothreads>
-  <iothreadids>
-    <iothread id='1'/>
-    <iothread id='2'/>
-  </iothreadids>
-  <cputune>
-    <vcpupin vcpu='0' cpuset='1'/>
-    <vcpupin vcpu='1' cpuset='2'/>
-    <vcpupin vcpu='2' cpuset='3'/>
-    <vcpupin vcpu='3' cpuset='4'/>
-    <vcpupin vcpu='4' cpuset='5'/>
-    <vcpupin vcpu='5' cpuset='6'/>
-    <vcpupin vcpu='6' cpuset='7'/>
-    <vcpupin vcpu='7' cpuset='9'/>
-    <vcpupin vcpu='8' cpuset='10'/>
-    <vcpupin vcpu='9' cpuset='11'/>
-    <vcpupin vcpu='10' cpuset='12'/>
-    <vcpupin vcpu='11' cpuset='13'/>
-    <vcpupin vcpu='12' cpuset='14'/>
-    <vcpupin vcpu='13' cpuset='15'/>
-    <vcpupin vcpu='14' cpuset='17'/>
-    <vcpupin vcpu='15' cpuset='18'/>
-    <vcpupin vcpu='16' cpuset='19'/>
-    <vcpupin vcpu='17' cpuset='20'/>
-    <vcpupin vcpu='18' cpuset='21'/>
-    <vcpupin vcpu='19' cpuset='22'/>
-    <vcpupin vcpu='20' cpuset='23'/>
-    <vcpupin vcpu='21' cpuset='25'/>
-    <vcpupin vcpu='22' cpuset='26'/>
-    <vcpupin vcpu='23' cpuset='27'/>
-    <vcpupin vcpu='24' cpuset='28'/>
-    <vcpupin vcpu='25' cpuset='29'/>
-    <vcpupin vcpu='26' cpuset='30'/>
-    <vcpupin vcpu='27' cpuset='31'/>
-    <emulatorpin cpuset='0,8,16,24'/>
-  </cputune>
-  <os>
-    <type arch='x86_64' machine='pc-q35-8.2'>hvm</type>
-    <loader readonly='yes' type='pflash'>/opt/macos/AUDK_CODE.fd</loader>
-    <nvram>/opt/macos/AUDK_VARS.fd</nvram>
-    <boot dev='hd'/>
-  </os>
-  <features>
-    <acpi/>
-    <apic/>
-  </features>
-  <cpu mode='host-passthrough' check='none' migratable='on'>
-    <topology sockets='2' dies='1' clusters='1' cores='8' threads='2'/>
-  </cpu>
-  <clock offset='utc'>
-    <timer name='rtc' tickpolicy='catchup'/>
-    <timer name='pit' tickpolicy='delay'/>
-    <timer name='hpet' present='no'/>
-  </clock>
-  <on_poweroff>destroy</on_poweroff>
-  <on_reboot>restart</on_reboot>
-  <on_crash>restart</on_crash>
-  <devices>
-    <emulator>/usr/bin/qemu-system-x86_64</emulator>
-    <controller type='pci' index='0' model='pcie-root'/>
-    <controller type='pci' index='1' model='pcie-root-port'>
-      <model name='pcie-root-port'/>
-      <target chassis='1' port='0x8' hotplug='off'/>
-      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0' multifunction='on'/>
-    </controller>
-    <controller type='pci' index='2' model='pcie-root-port'>
-      <model name='pcie-root-port'/>
-      <target chassis='2' port='0x9' hotplug='off'/>
-      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/>
-    </controller>
-    <controller type='pci' index='3' model='pcie-root-port'>
-      <model name='pcie-root-port'/>
-      <target chassis='3' port='0xc' hotplug='off'/>
-      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/>
-    </controller>
-    <controller type='pci' index='4' model='pcie-root-port'>
-      <model name='pcie-root-port'/>
-      <target chassis='4' port='0x13' hotplug='off'/>
-      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x3'/>
-    </controller>
-    <controller type='virtio-serial' index='0'>
-      <address type='pci' domain='0x0000' bus='0x02' slot='0x00' function='0x0'/>
-    </controller>
-    <controller type='usb' index='0' model='ich9-ehci1'>
-      <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x1'/>
-    </controller>
-    <controller type='usb' index='0' model='ich9-uhci1'>
-      <master startport='0'/>
-      <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0' multifunction='on'/>
-    </controller>
-    <controller type='sata' index='0'>
-      <address type='pci' domain='0x0000' bus='0x00' slot='0x1f' function='0x2'/>
-    </controller>
-    <interface type='bridge'>
-      <mac address='c8:2a:14:66:2c:a1'/>
-      <source bridge='br0'/>
-      <model type='virtio'/>
-      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
-    </interface>
-    <interface type='bridge'>
-      <mac address='c8:2a:14:31:32:e2'/>
-      <source bridge='br1'/>
-      <model type='virtio'/>
-      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
-    </interface>
-    <serial type='pty'>
-      <target type='isa-serial' port='0'>
-        <model name='isa-serial'/>
-      </target>
-    </serial>
-    <console type='pty'>
-      <target type='serial' port='0'/>
-    </console>
-    <channel type='unix'>
-      <target type='virtio' name='org.qemu.guest_agent.0'/>
-      <address type='virtio-serial' controller='0' bus='0' port='1'/>
-    </channel>
-    <input type='keyboard' bus='ps2'/>
-    <input type='mouse' bus='ps2'/>
-    <audio id='1' type='none'/>
-    <hostdev mode='subsystem' type='pci' managed='yes'>
-      <driver name='vfio'/>
-      <source>
-        <address domain='0x0000' bus='0x06' slot='0x00' function='0x0'/>
-      </source>
-      <rom file='/opt/gpu-bios/6900xt.rom'/>
-      <address type='pci' domain='0x0000' bus='0x03' slot='0x00' function='0x0' multifunction='on'/>
-    </hostdev>
-    <hostdev mode='subsystem' type='pci' managed='yes'>
-      <driver name='vfio'/>
-      <source>
-        <address domain='0x0000' bus='0x06' slot='0x00' function='0x1'/>
-      </source>
-      <address type='pci' domain='0x0000' bus='0x03' slot='0x00' function='0x1'/>
-    </hostdev>
-    <hostdev mode='subsystem' type='pci' managed='yes'>
-      <driver name='vfio'/>
-      <source>
-        <address domain='0x0000' bus='0x00' slot='0x1b' function='0x0'/>
-      </source>
-      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
-    </hostdev>
-    <hostdev mode='subsystem' type='pci' managed='yes'>
-      <driver name='vfio'/>
-      <source>
-        <address domain='0x0000' bus='0x0c' slot='0x00' function='0x0'/>
-      </source>
-      <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/>
-    </hostdev>
-    <hostdev mode='subsystem' type='pci' managed='yes'>
-      <driver name='vfio'/>
-      <source>
-        <address domain='0x0000' bus='0x84' slot='0x00' function='0x0'/>
-      </source>
-      <address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0'/>
-    </hostdev>
-    <hostdev mode='subsystem' type='usb' managed='no'>
-      <source>
-        <vendor id='0x046d'/>
-        <product id='0x0892'/>
-      </source>
-      <address type='usb' bus='0' port='2'/>
-    </hostdev>
-    <hostdev mode='subsystem' type='usb' managed='no'>
-      <source>
-        <vendor id='0x148f'/>
-        <product id='0x3070'/>
-      </source>
-      <address type='usb' bus='0' port='1'/>
-    </hostdev>
-    <watchdog model='itco' action='reset'/>
-    <memballoon model='none'/>
-  </devices>
-  <qemu:commandline>
-    <qemu:arg value='-smbios'/>
-    <qemu:arg value='type=2'/>
-    <qemu:arg value='-global'/>
-    <qemu:arg value='ICH9-LPC.acpi-pci-hotplug-with-bridge-support=off'/>
-    <qemu:arg value='-global'/>
-    <qemu:arg value='pcie-root-port.x-speed=8'/>
-    <qemu:arg value='-global'/>
-    <qemu:arg value='pcie-root-port.x-width=16'/>
-    <qemu:arg value='-cpu'/>
-    <qemu:arg value='host,+hypervisor,migratable=no,-erms,kvm=on,+invtsc,+topoext,+avx,+aes,+xsave,+xsaveopt,+ssse3,+sse4_2,+popcnt,+arat,+pclmuldq,+pdpe1gb,+rdtscp,+vme,+umip,check'/>
-  </qemu:commandline>
-</domain>
-```
-
-06:00.0/1 --> gpu
-00:1b.0 --> audio
-0c:00.0 --> sata controller
-84:00.0 --> usb controller
-0x046d 0x0892 --> usb webcam
-0x148f 0x3070 --> usb wifi
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/237 b/gitlab/issues_text/target_i386/host_missing/accel_missing/237
deleted file mode 100644
index 8051f1cae..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/237
+++ /dev/null
@@ -1 +0,0 @@
-[Feature request] x86: dump MSR features in human form
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2381 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2381
deleted file mode 100644
index cc1178bf0..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/2381
+++ /dev/null
@@ -1,3 +0,0 @@
-Modern x86 TSC features under TCG
-Additional information:
-I may be able to find a volunteer to implement this. If this feature does not appear to be a good first task, please let me know.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2383 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2383
deleted file mode 100644
index 7f9eb0284..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/2383
+++ /dev/null
@@ -1,3 +0,0 @@
-Support SMRR for x86 emulation
-Additional information:
-
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2393 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2393
deleted file mode 100644
index 4e53ee99b..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/2393
+++ /dev/null
@@ -1,20 +0,0 @@
-qemu: seabios hangs for 10~15 sec at boot with `-machine q35`
-Description of problem:
-Whenever i'm starting a virtual machine i'm having the issue that seabios (or at least that's what i see) hangs for about 10~15 seconds. In that time on of the cpu cores runs at 100%.
-This issue isn't new actually. I'm having this already for quite some time and a i think for at least the last 2 major versions. I haven't looked into it since it isn't a big issue, just annoying.
-Today i've looked into it and as far as i can see, this issue is always present with the flag `-machine q35`, which is the default for my vm's. If i set it to `-machine pc`, booting works as expected. However i also found a "workaround" where the vm's starting immediately (with `-machine q35` enabled), which is by simply adding a iso image to the command line (via -cdrom) - even though it's not used.
-
-This means:
-- 15 sec delay: qemu-system-x86_64 -machine q35
-- works immediately: qemu-system-x86_64 -machine q35 -cdrom /mnt/data/vm/isos/openSUSE-Tumbleweed-DVD-x86_64-Snapshot20230303-Media.iso
-
-Please note that most of my vm's usually start booting from a kernel image directly (-kernel /mnt/data/vm/kernel/gentoo-latest -initrd /mnt/data/vm/kernel/initrd-v5.cpio.gz) - but even in that case settings a cdrom (image) would fix the issue.
-Also, the image needs to be a valid one, if i set an empty file or /dev/null the issue would remain.
-Further more, i have the same issue on a second computer. This also runs on Gentoo Linux and is also a AMD Ryzen. (in case this is relevant)
-Steps to reproduce:
-1. qemu-system-x86_64 -machine q35
-2. wait about 10-15sec before boot continues
-Additional information:
-I was thinking to add an Screenshot of the hanging boot process, but the only text written there is:
-SeaBIOS (version 1.16.0-20220807_005459-localhost)
-with a blinking cursor below
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2420 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2420
deleted file mode 100644
index 0bf284e09..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/2420
+++ /dev/null
@@ -1,44 +0,0 @@
-Error: Deprecated CPU topology (considered invalid): Unsupported cluster parameter musn't be specified as 1
-Description of problem:
-warning: Deprecated CPU topology (considered invalid): Unsupported clusters parameter mustn't be specified as 1
-VM does not start
-
-What I've tried so far to fix:
-
-- Removed the offending `clusters="1"` parameter in the XML, both via virsh edit and virt-manager but the sucker comes back every time!
-
-- Creating a completely new VM from scratch, just keeping the qcow2 for Windows. What happens then is funny: The initial setup goes well. Machine type automatically gets set to q35 version 9.0. After setting up my cores (pinning) for the VM (7C/14T for the VM 1C/2T for host), there is no "clusters" parameter anymore. So the first start went well. After a RESTART of the whole host machine and subsequent launch of the VM guess what happened? The "clusters" thing is back in full swing.
-Steps to reproduce:
-1. Create Windows 11 VM with virt-manager
-2. Try to do core pinning and setting up the following in virt manager before
-- Copy CPU configuration from host (host-passthrough)
-- Manually set CPU structure via GUI to 1 Socket, 7 Cores, 2 Threads on an 8 Core (in my case 11900k)
-3. Observe result in XML being: 
- `<topology sockets="1" dies="1" clusters="1" cores="7" threads="2"/>`
-
-Again, the "clusters" entry leads to the VM not starting. Removing it doesn't work, it comes back straight away. I tried in virt-manager as well as with virsh edit.
-Additional information:
-My core pinning for reference:
-
-```
-<vcpu placement="static">14</vcpu>
-  <iothreads>1</iothreads>
-  <cputune>
-    <vcpupin vcpu="0" cpuset="0"/>
-    <vcpupin vcpu="1" cpuset="8"/>
-    <vcpupin vcpu="2" cpuset="1"/>
-    <vcpupin vcpu="3" cpuset="9"/>
-    <vcpupin vcpu="4" cpuset="2"/>
-    <vcpupin vcpu="5" cpuset="10"/>
-    <vcpupin vcpu="6" cpuset="3"/>
-    <vcpupin vcpu="7" cpuset="11"/>
-    <vcpupin vcpu="8" cpuset="4"/>
-    <vcpupin vcpu="9" cpuset="12"/>
-    <vcpupin vcpu="10" cpuset="5"/>
-    <vcpupin vcpu="11" cpuset="13"/>
-    <vcpupin vcpu="12" cpuset="6"/>
-    <vcpupin vcpu="13" cpuset="14"/>
-    <emulatorpin cpuset="7,15"/>
-    <iothreadpin iothread="1" cpuset="7,15"/>
-  </cputune>
-```
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2426 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2426
deleted file mode 100644
index 878f3517d..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/2426
+++ /dev/null
@@ -1 +0,0 @@
-How to determine which cpu microarchitecture is suitable for use on Windows 11?
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/243 b/gitlab/issues_text/target_i386/host_missing/accel_missing/243
deleted file mode 100644
index 9cf1fa689..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/243
+++ /dev/null
@@ -1 +0,0 @@
-Qemu refuses to multiboot Elf64 kernels
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2452 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2452
deleted file mode 100644
index 185f5d0ef..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/2452
+++ /dev/null
@@ -1 +0,0 @@
-memory allocation for AMDVIIOTLBEntry in amdvi_update_iotlb()
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2509 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2509
deleted file mode 100644
index 11eafe55e..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/2509
+++ /dev/null
@@ -1,26 +0,0 @@
-With qemu-system-i386 certain iso images cause looping crashes
-Description of problem:
-Soon after start seabios tries to boot, a crash followed by a loop occurs. Last line seen before crash and loop:
-   ```
-Booting from DVD/CD...
-   ```
-Steps to reproduce:
-1. Download https://www.qemu-advent-calendar.org/2018/download/day10.tar.xz
-2. Execute QEMU command line
-Additional information:
-Starting VM with qemu-system-x86_64 works
-   ```
-   qemu-system-x86_64 -cdrom gamebro.iso
-   ```
-Starting VM with qemu-system-i386 using KVM causes looping
-   ```
-   qemu-system-i386 -accel kvm -cdrom gamebro.iso
-   ```
-Starting VM with qemu-system-i386 on Windows using WHPX works
-   ```
-   qemu-system-i386.exe -accel whpx -cdrom gamebro.iso
-   ```
-Starting other iso images works, e.g. https://cdimage.debian.org/mirror/cdimage/archive/10.8.0/i386/iso-cd/debian-10.8.0-i386-netinst.iso
-   ```
-   qemu-system-i386 -cdrom debian-10.8.0-i386-netinst.iso
-   ```
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2520 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2520
deleted file mode 100644
index 6c81af7c5..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/2520
+++ /dev/null
@@ -1,11 +0,0 @@
-qemu-system-x86_64 : No Display when system wakeup from suspend
-Description of problem:
-Qemu display window is blank with message `Display output is not active.`
-Steps to reproduce:
-1. Use https://gitlab.com/berrange/tiny-vm-tools/-/blob/master/make-tiny-image.py to generate tiny-initrd.img
-2. Run qemu and drop into shell
-3. Put machine into S3 (echo mem > /sys/power/state)
-4. Use socat to connect to QEMU monitor and wake up the machine (system_wakeup)
-5. System resumes in shell, but no output in display
-Additional information:
-Same behavior, if I try standard ubuntu22.04.qcow2 image. Before suspend GUI is there and after wakeup from suspend  blank display with message `Display output is not active.`
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2530 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2530
deleted file mode 100644
index 6379633d9..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/2530
+++ /dev/null
@@ -1,17 +0,0 @@
-Duplicate ACPI _SUN
-Description of problem:
-ACPI _SUN is `the slot-unique ID number for a slot`, but qemu uses `PCI_SLOT()` which is definitely not unique
-https://gitlab.com/qemu-project/qemu/-/blob/407f9a4b121eb65166375c410e14d7b704bc1106/hw/i386/acpi-build.c#L524
-Steps to reproduce:
-1. Create a linux VM with 2 virtio NICs
-2. Look at the ACPI _SUN of the virtio-pci devices (firmware_node/sun)
-
-Both virtio-pci devices have _SUN == 0
-```
-#
-Additional information:
-In systemd we recently introduced code to use firmware_node/sun information for NIC naming
-https://github.com/systemd/systemd/commit/0a4ecc54cb9f2d3418b970c51bfadb69c34ae9eb
-
-but having duplicate _SUN is of course problematic
-https://github.com/systemd/systemd/issues/34082
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2555 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2555
deleted file mode 100644
index 078120202..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/2555
+++ /dev/null
@@ -1,20 +0,0 @@
-Can't start a guest with 2 IOAPICs
-Description of problem:
-For a host with multiple IOAPICs, I want to start a guest with 2 IOAPICs. I saw this commit about this function: **[x86: add support for second ioapic]**:
-     https://gitlab.com/qemu-project/qemu/-/commit/94c5a606379ddd04beecdb11fb34b51b4b28c7f2
-
-But after I started a guest in a host with multiple IOAPICs, there was still only one IOAPIC in guest. How should I enable this feature?
-Additional information:
-Host IOAPICs Info:
-   ```
-[    1.268280] IOAPIC[0]: apic_id 0, version 33, address 0xfec00000, GSI 0-23
-[    1.268286] IOAPIC[1]: apic_id 1, version 33, address 0xfec20000, GSI 24-55
-[    1.268291] IOAPIC[2]: apic_id 2, version 33, address 0xd9000000, GSI 56-87
-[    4.415313] ACPI: Using IOAPIC for interrupt routing
-   ```
-
-Guest IOAPIC Info:
-   ```
-[    0.000000] IOAPIC[0]: apic_id 0, version 17, address 0xfec00000, GSI 0-23
-[    0.255045] ACPI: Using IOAPIC for interrupt routing
-   ```
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2556 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2556
deleted file mode 100644
index 675938d43..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/2556
+++ /dev/null
@@ -1,12 +0,0 @@
-memory balloon massively slows Windows shutdown (almost feels like it crashed for minutes)
-Description of problem:
-When reducing the memory using ballooning, the shutdown takes very long. One may even assume it crashed, but it will eventually power off.
-Steps to reproduce:
-1. wait until Windows has booted
-2. reduce the balloon by multiple GB via monitor: `balloon 8192` _(8 GB balloon, memory size is 24 GB)_
-3. Shut down (or reboot) Windows
-
-The system shows the boot screen at shutdown for a long time.
-
-It's about 10 seconds extra time per reduced balloon size. So when resizing the balloon from 24 GB to 8 GB, that's 16 GB.  
-So the shutdown needs: 16 * 10 = 160 seconds = **about 3 minutes**
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2562 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2562
deleted file mode 100644
index 7e59dcbc4..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/2562
+++ /dev/null
@@ -1,52 +0,0 @@
-Booting EFI shell from GRUB using "chainloader" in Qemu with UEFI boot shows video artifacts if we have all_video, gfxterm
-Steps to reproduce:
-- Start Qemu in UEFI mode, i. e. `qemu-system-x86_64 -bios OVMF.fd ...`
-- Qemu should load GRUB from the disk as the first thing after firmware
-- GRUB should run commands `loadfont unicode; insmod all_video; terminal_output gfxterm` (note: this is perfectly ordinary sequence executed by Debian's default configuration)
-- Then GRUB should execute EFI shell using `chainloader` command
-
-If we do all this, then instead of EFI shell we will see broken image. I. e. video output will be completely broken/mangled/damaged. But EFI shell will still respond to commands. If we type "exit", then we will exit from EFI shell back to GRUB.
-
-I will repeat: my configuration is not special at all. `loadfont unicode; insmod all_video; terminal_output gfxterm` are absolutely ordinary commands executed by Debian's GRUB default setup. So, essentially this bug means this: if I add EFI shell to GRUB menu in Debian, then this new menu entry will not work properly if I try to boot in Qemu in UEFI mode.
-
-Okay, now let me give you more detailed steps to reproduce.
-
-- Execute the following script on Linux x86_64 host:
-```bash
-#!/bin/bash
-# This script was tested on Debian trixie (as on 2024-09-07) with the following packages installed:
-# dosfstools grub-efi-amd64-bin qemu-system-x86 ovmf efi-shell-x64
-set -e
-DIR="$(mktemp -d /tmp/qemu-bug-XXXXXX)"
-truncate --size=100M "$DIR/disk"
-echo ',+,' | sfdisk --label gpt "$DIR/disk"
-LOOP="$(losetup --find --show --partscan --nooverlap "$DIR/disk")"
-sleep 1
-mkfs.vfat "${LOOP}p1"
-mkdir "$DIR/root"
-mount "${LOOP}p1" "$DIR/root"
-losetup --detach "$LOOP"
-mkdir -p "$DIR/root/EFI/boot" "$DIR/root/boot/grub/fonts"
-grub-mkimage --format=x86_64-efi --output="$DIR/root/EFI/boot/bootx64.efi" --prefix=/boot/grub part_gpt fat
-cp -r /usr/lib/grub/x86_64-efi "$DIR/root/boot/grub"
-cp /usr/share/efi-shell-x64/shellx64.efi "$DIR/root/boot"
-cp /usr/share/grub/unicode.pf2 "$DIR/root/boot/grub/fonts"
-cat << "EOF" > "$DIR/root/boot/grub/grub.cfg"
-loadfont unicode
-insmod all_video
-terminal_output gfxterm
-menuentry "EFI shell" {
-  chainloader /boot/shellx64.efi
-}
-EOF
-umount "$DIR/root"
-qemu-system-x86_64 -m 2048 -bios OVMF.fd -drive file="$DIR/disk",format=raw
-```
-- When you see Qemu window, choose "EFI shell" menu entry in GRUB menu
-- You will immediately see damaged video output instead of proper EFI shell
-
-This bug doesn't reproduce on real hardware, i. e. without Qemu!!! I. e. this is Qemu bug. Qemu task is to duplicate real hardware behaviour. On real hardware there is no this bug, so Qemu should not have it, either.
-
-Note: if I remove `loadfont unicode; insmod all_video; terminal_output gfxterm`, then the bug disappears.
-
-Also note: if I replace `all_video` with `efi_gop`, then the bug disappears, too. So, workaround is to use `efi_gop` instead of `all_video` in UEFI mode. But I still believe the bug is in Qemu, because `all_video` doesn't cause any problems on real hardware, so Qemu should work, too.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2583 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2583
deleted file mode 100644
index 0cb5722fe..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/2583
+++ /dev/null
@@ -1,25 +0,0 @@
-libvfio-user.so.0 missing in /lib/x86_64-linux-gnu/  in fresh install of 9.1.50
-Description of problem:
-Library libvfio-user.so.0  is missing from /lib/x86_64-linux-gnu. qemu-system-x86_64 does not start due to missing library.
-
-````
-root@jpbdeb:~# ls -al /usr/local/bin/qemu-system-x86_64 
--rwxr-xr-x 1 root root 81734576 Sep 21 21:48 /usr/local/bin/qemu-system-x86_64
-root@jpbdeb:~# ldd /usr/local/bin/qemu-system-x86_64 
-	linux-vdso.so.1 (0x00007fff511de000)
-	libvfio-user.so.0 => not found
-	libslirp.so.0 => /lib/x86_64-linux-gnu/libslirp.so.0 (0x00007f73eba33000)
-	libxenctrl.so.4.17 => /lib/x86_64-linux-gnu/libxenctrl.so.4.17 (0x00007f73eba09000)
-	libxenstore.so.4 => /lib/x86_64-linux-gnu/libxenstore.so.4 (0x00007f73eb9fe000)
-	libxenforeignmemory.so.1 => /lib/x86_64-linux-gnu/libxenforeignmemory.so.1 (0x00007f73eb9f9000)
-        ...
-````
-Steps to reproduce:
-1. Fresh OS install, including all packages necessary to build from source.
-2. Download source from gitlab and proceed with documented build instructions.
-3. make install
-4. Attempt to run /usr/local/bin/qemu-system-x86_64  fails, due to missing library.
-Additional information:
-Adding the link to the library that exists in /usr/lib/x86_64-linux-gnu  resolves the issue:
-
-(as root) ln -s /usr/local/lib/x86_64-linux-gnu/libvfio-user.so.0  /lib/x86_64-linux-gnu/libvfio-user.so.0
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2586 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2586
deleted file mode 100644
index d6120a48c..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/2586
+++ /dev/null
@@ -1,3 +0,0 @@
-qemu-system-x86_64: IGD "legacy mode" support with Q35?
-Additional information:
-Detailed discussion on https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/12103
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2590 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2590
deleted file mode 100644
index 9e751ec7b..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/2590
+++ /dev/null
@@ -1,23 +0,0 @@
-qemu-x86_64: gdb doesn't read symbols from dynamically linked shared libraries.
-Description of problem:
-GDB fails to load dynamically linked shared libraries when connecting to qemu-x86_64, causing it to not recognize symbols from the shared libraries. As a result, breakpoints in shared library functions (e.g, `break printf`) do not work.
-Steps to reproduce:
-1. Start the debug server: `./qemu-x86_64 -g PORT ./x86_64-binary`
-2. Connect GDB to the debug server:
-```
-$ gdb-multiarch ./x86_64-binary
-(gdb) set verbose on
-(gdb) target remote :PORT
-```
-3. GDB displays a warning and fails to load shared libraries:
-```
-(gdb) target remote :PORT
-Remote debugging using :PORT
-warning: platform-specific solib_create_inferior_hook did not load initial shared libraries.
-(gdb) info sharedlibrary
-No shared libraries loaded at this time.
-```
-Additional information:
-This issue does not occur when using gdbserver on a native x86_64 machine and connecting to it from gdb-multiarch on an ARM64 machine, indicating the issue is likely related to QEMU rather than GDB. 
-
-GDB correctly recognizes symbols from the target binary (e.g., the `main` function), and breakpoints at these symbols function as expected.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2593 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2593
deleted file mode 100644
index 4f541842f..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/2593
+++ /dev/null
@@ -1,57 +0,0 @@
--netdev user,smb=/path doesn't work with old Windows versions anymore
-Description of problem:
-I'm running Windows 98 in qemu and wasn't able to access the share. After finding `/tmp/qemu-smb.*/` and increasing the log level (setting `log level = 10` in the temporary smb.conf) it became clear, that the smbd server didn't support any of the protocols offered by Win98:
-
-<details>
-
-```
-[2024/09/25 23:04:25.871072, 10, pid=40892, effective(1000, 1000), real(1000, 1000)] ../../lib/util/util.c:580(dump_data)
-  [0000] 02 50 43 20 4E 45 54 57   4F 52 4B 20 50 52 4F 47   .PC NETW ORK PROG
-  [0010] 52 41 4D 20 31 2E 30 00   02 4D 49 43 52 4F 53 4F   RAM 1.0. .MICROSO
-  [0020] 46 54 20 4E 45 54 57 4F   52 4B 53 20 33 2E 30 00   FT NETWO RKS 3.0.
-  [0030] 02 44 4F 53 20 4C 4D 31   2E 32 58 30 30 32 00 02   .DOS LM1 .2X002..
-  [0040] 44 4F 53 20 4C 41 4E 4D   41 4E 32 2E 31 00 02 57   DOS LANM AN2.1..W
-  [0050] 69 6E 64 6F 77 73 20 66   6F 72 20 57 6F 72 6B 67   indows f or Workg
-  [0060] 72 6F 75 70 73 20 33 2E   31 61 00 02 4E 54 20 4C   roups 3. 1a..NT L
-  [0070] 4D 20 30 2E 31 32 00                                M 0.12.
-[2024/09/25 23:04:25.871241,  3, pid=40892, effective(1000, 1000), real(1000, 1000), class=smb2] ../../source3/smbd/smb2_negprot.c:1154(smb2_multi_protocol_reply_negprot)
-  Requested protocol [PC NETWORK PROGRAM 1.0]
-[2024/09/25 23:04:25.871247,  3, pid=40892, effective(1000, 1000), real(1000, 1000), class=smb2] ../../source3/smbd/smb2_negprot.c:1154(smb2_multi_protocol_reply_negprot)
-  Requested protocol [MICROSOFT NETWORKS 3.0]
-[2024/09/25 23:04:25.871252,  3, pid=40892, effective(1000, 1000), real(1000, 1000), class=smb2] ../../source3/smbd/smb2_negprot.c:1154(smb2_multi_protocol_reply_negprot)
-  Requested protocol [DOS LM1.2X002]
-[2024/09/25 23:04:25.871256,  3, pid=40892, effective(1000, 1000), real(1000, 1000), class=smb2] ../../source3/smbd/smb2_negprot.c:1154(smb2_multi_protocol_reply_negprot)
-  Requested protocol [DOS LANMAN2.1]
-[2024/09/25 23:04:25.871260,  3, pid=40892, effective(1000, 1000), real(1000, 1000), class=smb2] ../../source3/smbd/smb2_negprot.c:1154(smb2_multi_protocol_reply_negprot)
-  Requested protocol [Windows for Workgroups 3.1a]
-[2024/09/25 23:04:25.871264,  3, pid=40892, effective(1000, 1000), real(1000, 1000), class=smb2] ../../source3/smbd/smb2_negprot.c:1154(smb2_multi_protocol_reply_negprot)
-  Requested protocol [NT LM 0.12]
-...
-[2024/09/25 23:04:25.871315,  6, pid=40892, effective(1000, 1000), real(1000, 1000)] ../../source3/param/loadparm.c:2442(lp_file_list_changed)
-  lp_file_list_changed()
-  file /tmp/qemu-smb.TU2YU2/smb.conf -> /tmp/qemu-smb.TU2YU2/smb.conf  last mod_time: 2024-09-25 23:04:20.374500597
-[2024/09/25 23:04:25.871325,  3, pid=40892, effective(1000, 1000), real(1000, 1000), class=smb2] ../../source3/smbd/smb2_negprot.c:1201(smb2_multi_protocol_reply_negprot)
-  smb2_multi_protocol_reply_negprot: No protocol supported !
-
-```
-
-</details>
-
-(`smb2_multi_protocol_reply_negprot: No protocol supported !`).
-
-Manually adding the line `server min protocol = LANMAN1` under `[global]` in the temporary `smb.conf` fixed the issue.
-I think qemu should add that line by default.
-
-The behavior was the same with smbd 4.15.13-Ubuntu from Ubuntu 22.04 and 4.21.0 from current Arch Linux.
-Steps to reproduce:
-1. Set up qemu VM with Win98 (or presumably any Windows version up to XP)
-   * at least on my machine I had to use `tcg`, with `kvm` Win98 is very unstable on Ryzen CPUs
-   * I roughly followed this tutorial: https://computernewb.com/wiki/QEMU/Guests/Windows_98 incl. using that Windows 98 QuickInstall ISO and the softgpu driver
-   * enable user-mode networking with smb share (`-netdev user,id=lan,smb=/path/to/share -device pcnet,netdev=lan`)
-2. Edit `C:\Windows\LMHOSTS` as described in the qemu documentation (add line `10.0.2.4 smbserver`)
-3. Probably reboot the Windows VM
-   * Actually, rebooting Win98 doesn't work for me, it then hangs while booting. Shutting down and starting the VM again works though.
-4. Open the Windows Explorer and enter `\\smbserver` in the address bar - it will fail with some unhelpful error.
-5. Edit `/tmp/qemu-smb.*/smb.conf` and add the line `server min protocol = LANMAN1` under `[global]`
-   - `server min protocol = NT1` also works for Win98, but with `LANMAN1` even older operating systems like Win3.11 should also work
-6. Retry step 4 - it should work now.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2594 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2594
deleted file mode 100644
index 5907a2518..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/2594
+++ /dev/null
@@ -1,35 +0,0 @@
-Migration fails with 'get_pci_config_device: Bad config data: i=0x9a read: 2 device: 3 cmask: ff wmask: 0 w1cmask:0' after hotplugging a CPU
-Description of problem:
-After hotplugging a CPU and finishing a migration from node 1 to node 2, the instance on node 2 crashes when virtio block devices are used:
-```
-qemu-system-x86_64: get_pci_config_device: Bad config data: i=0x9a read: 2 device: 3 cmask: ff wmask: 0 w1cmask:0
-qemu-system-x86_64: Failed to load PCIDevice:config
-qemu-system-x86_64: Failed to load virtio-blk:virtio
-qemu-system-x86_64: error while loading state for instance 0x0 of device '0000:00:04.0/virtio-blk'
-qemu-system-x86_64: load of migration failed: Invalid argument
-```
-
-I found the problem also exhibits when using `scsi-hd` in combination with `virtio-scsi`, but not when using IDE hard disks or SCSI disks with an LSI controller. VMs with network cards aren't affected either, as are VMs without virtio disks.
-
-
-Interestingly, the latest QEMU version shipped with Ubuntu 20.04 (4.2.1-Debian 1:4.2-3ubuntu6.29) is able to migrate this VM just fine.
-Steps to reproduce:
-1. Start a VM using the first command line
-2. Start another VM using the second command line
-3. Hotplug a CPU in QMP:
-   ```
-   {"execute":"device_add","arguments":{"node-id":0,"socket-id":0,"core-id":2,"thread-id":0,"id":{},"driver":"qemu64-x86_64-cpu"}}
-   ```
-4. Start a migration by executing the following QMP command (again substituting `<ip:port>` with the IP:port combination of node 2
-   ```
-   {"execute":"migrate","arguments":{"uri":"tcp:127.0.0.1:1234"}}
-   ```
-
-(For steps 3 and 4 I used this):
-```
-echo '{"execute":"qmp_capabilities"}
-{"execute":"device_add","arguments":{"node-id":0,"socket-id":0,"core-id":2,"thread-id":0,"id":{},"driver":"qemu64-x86_64-cpu"},"id":1}
-{"execute":"migrate","arguments":{"uri":"tcp:127.0.0.1:1234"},"id":2}' | nc -U /tmp/vm1.sock
-```
-Additional information:
-
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2597 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2597
deleted file mode 100644
index c7dcf7f01..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/2597
+++ /dev/null
@@ -1 +0,0 @@
-qemu-i386 crashes on ppc64el
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2616 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2616
deleted file mode 100644
index dc51a2611..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/2616
+++ /dev/null
@@ -1,11 +0,0 @@
-crashout on any storage operation on SCO OpenServer 6
-Description of problem:
-it's hard to exactly pinpoint what's wrong, but apparently it's a known issue. whenever i attempt to install or boot the OS, i get one of the two outcomes: with KVM it's a halt-and-catch-fire, getting stuck in an eternal loop of I/O errors and failed interrupts, with TCG at the very least the drivers get loaded and the installation disk is mounted, contrary to the emulated hard drive. connecting either drive to SCSI made HBA act like it's not there at all, and using the standard AHCI/IDE controllers leads to the result presented in the picture in one of the sections below, and, as mentioned earlier, this stage only happens with TCG. there's a 9:1 shot (on Q35, on PIIX3/PIIX4 it'll always either throw this exception or fail to initialise the CD-ROM) of it either screaming about a power failure right as it's ready to format the drive or it just installing.
-Steps to reproduce:
-1. download the old OpenServer 6 VM image/ISO from the SCO/Xinuos server.
-2. attach it in your config.
-3. go through initial setup stages (eg. entering a licence or deferring from such).
-4. wait for the disk initialisation to begin.
-Additional information:
-![example on the prebuilt image for VMware with a 1:1 compatible config](/uploads/995fab2ebccecba2e9d90f73519ac118/Screenshot_from_2024-10-10_21-34-39.png)
-![example of installing with PIIX3/PIIX4](/uploads/2b8685dcdb998acd0cfc2121f9951290/Screenshot_from_2024-10-11_18-26-05.png)
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2626 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2626
deleted file mode 100644
index b0dc6d97d..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/2626
+++ /dev/null
@@ -1,8 +0,0 @@
-QEMU crashes after host time moves backwards
-Description of problem:
-QEMU process crashes after time synchronized and moved backwards on the host.
-Steps to reproduce:
-As detailed in the [thread](https://bugzilla.redhat.com/show_bug.cgi?id=2228406)
-
-1. create a virtual machine and change tick period in the guest
-2. executing `while [ 1 ];do hwclock --systohc; hwclock --hctosys;done` on the host
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2631 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2631
deleted file mode 100644
index cce15ebc7..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/2631
+++ /dev/null
@@ -1,81 +0,0 @@
-qemu-system-i386: void msix_vector_use(PCIDevice *, unsigned int): Assertion `vector < dev->msix_entries_nr' failed.
-Description of problem:
-While fuzzing, we observed a assertion failures in several virtio devices supporting msi-x functionality.
-Steps to reproduce:
-Here is qtest reproducer:
-```bash
-cat << EOF | qemu-system-i386 -display none -machine accel=qtest, -m 512M -machine pc -nodefaults \
--device virtio-mouse-pci,vectors=19923041 -qtest stdio
-outl 0xcf8 0x80001020
-outl 0xcfc 0xe0800000
-outl 0xcf8 0x80001004
-outw 0xcfc 0x02
-write 0xe0800010 0x4 0x6100
-EOF
-```
-
-and execution log:
-```
-cat << EOF | qemu-system-i386 -display none -machine accel=qtest, -m 512M -machine pc -nodefaults \
--device virtio-mouse-pci,vectors=19923041 -qtest stdio
-outl 0xcf8 0x80001020
-outl 0xcfc 0xe0800000
-outl 0xcf8 0x80001004
-outw 0xcfc 0x02
-write 0xe0800010 0x4 0x6100
-EOF
-[I 0.000001] OPENED
-[R +0.067760] outl 0xcf8 0x80001020
-[S +0.067795] OK
-OK
-[R +0.067821] outl 0xcfc 0xe0800000
-[S +0.067959] OK
-OK
-[R +0.067993] outl 0xcf8 0x80001004
-[S +0.068005] OK
-OK
-[R +0.068020] outw 0xcfc 0x02
-[S +0.068520] OK
-OK
-[R +0.068554] write 0xe0800010 0x4 0x6100
-qemu-system-i386: ../hw/pci/msix.c:569: void msix_vector_use(PCIDevice *, unsigned int): Assertion `vector < dev->msix_entries_nr' failed.
-Aborted
-```
-
-If you need more information, let me know so I can discuss more about this issue.
-Additional information:
-```c
-int msix_init(PCIDevice *dev, unsigned short nentries,
-              MemoryRegion *table_bar, uint8_t table_bar_nr,
-              unsigned table_offset, MemoryRegion *pba_bar,
-              uint8_t pba_bar_nr, unsigned pba_offset, uint8_t cap_pos,
-              Error **errp);
-int msix_init_exclusive_bar(PCIDevice *dev, unsigned short nentries,
-                            uint8_t bar_nr, Error **errp);
-```
-
-`msix_init` accepts `nentries` as `unsigned short` type. 
-
-```c
-static void virtio_pci_device_plugged(DeviceState *d, Error **errp):
-
-    ...
-
-    if (proxy->nvectors) {
-        int err = msix_init_exclusive_bar(&proxy->pci_dev, proxy->nvectors,
-                                          proxy->msix_bar_idx, NULL);
-        if (err) {
-            /* Notice when a system that supports MSIx can't initialize it */
-            if (err != -ENOTSUP) {
-                warn_report("unable to init msix vectors to %" PRIu32,
-                            proxy->nvectors);
-            }
-            proxy->nvectors = 0;
-        }
-    }
-```
-
-When virtio-pci device is initialized, `proxy->nvectors` (`uint32_t` here) is casted into `unsigned short`.
-This causes inconsistency between `msix_entries_nr` and `nvectors` and triggers the above crash.
-
-While this is due to setting invalid value to `nvectors`, we need proper handling of the wrong value in the configuration.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2654 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2654
deleted file mode 100644
index c904c35ad..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/2654
+++ /dev/null
@@ -1,14 +0,0 @@
-qemu-system-i386 no longer boots NetBSD
-Description of problem:
-Since qemu commit b56617bbcb473c25815d1bf475e326f84563b1de, qemu-system-i386 can no longer boot NetBSD.
-Steps to reproduce:
-```
-wget https://cdn.netbsd.org/pub/NetBSD/NetBSD-10.0/images/NetBSD-10.0-i386.iso
-qemu-system-i386 -cdrom NetBSD-10.0-i386.iso
-```
-
-Expected behavior: Boots into the NetBSD installer
-
-Observed incorrect behavior: Boot hangs with a black screen
-Additional information:
-This regression is a critical issue to the NetBSD project as its automated testing infrastructure is heavily dependent on qemu-system-i386.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2657 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2657
deleted file mode 100644
index c95f9129b..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/2657
+++ /dev/null
@@ -1,11 +0,0 @@
-Kernel crashed when installing OpenServer 6 D2M2a
-Description of problem:
-The kernel crashed when finishing installation.
-Steps to reproduce:
-1. Download OpenServer6D2M2a-DVD.iso for free from Xinuos website(a free account is needed, but the registation is easy to be done)
-2. Create new virtual hard drive
-3. Boot the installation ISO
-4. Install with all default settings and all packages, evaluate license is okay.
-5. Boom!
-Additional information:
-![QQ20241106-110404](/uploads/b42d5d6fef34606b4a6c672e33f06b97/QQ20241106-110404.png)
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2666 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2666
deleted file mode 100644
index db1b9be07..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/2666
+++ /dev/null
@@ -1,22 +0,0 @@
-OPENSTEP 4.2 for Intel does not boot from SCSI cd connected to am53c974
-Description of problem:
-Get OPENSTEP 4.2 installation media from 
-https://fsck.technology/software/NeXT/OpenStep%20Installation%20Media/
-
-Boot qemu like command line above
-
-Follow on-screen instruction, do not forgot to "change floppy0 path_to_driver_disk.img" in qemu monitor
-Additional information:
-![os42-qemu-amd](/uploads/88eddae2f9ec6acd83274a98ab11f2e4/os42-qemu-amd.png)
-
-driver select screen
-
-![os42-qemu-amd-1](/uploads/37d96d04d7f40f6c80aa3f9f6e03f4ff/os42-qemu-amd-1.png)
-
-it boots ..
-
-![os42-qemu-amd-2](/uploads/d3640682a1af90218885ecee31f45ec6/os42-qemu-amd-2.png)
-
-find a bit too much LUNs and eventually give up after scanning them all
-
-Note there is 0-sized disk "detected" in there somewhere
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/267 b/gitlab/issues_text/target_i386/host_missing/accel_missing/267
deleted file mode 100644
index dbb71c14f..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/267
+++ /dev/null
@@ -1 +0,0 @@
-qemu-x86_64 segment prefixes error
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2739 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2739
deleted file mode 100644
index 49b88bcca..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/2739
+++ /dev/null
@@ -1,3 +0,0 @@
-Feature: Emulate GRUB2's initrd16 newc: feature for dynamic initrd generation
-Additional information:
-This feature is used in boot environments like WINPE, where GRUB2 leverages `initrd16` with `newc:` to load `wimboot` and then dynamically create an initrd containing necessary files for booting a Windows PE environment from a WIM image. Emulating this in QEMU would greatly improve the ability to test and debug such setups.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2769 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2769
deleted file mode 100644
index 6abccb2a8..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/2769
+++ /dev/null
@@ -1,3 +0,0 @@
-Ability to set smbios type 3 field "Type"
-Additional information:
-That's all :)
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2779 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2779
deleted file mode 100644
index d6367bed3..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/2779
+++ /dev/null
@@ -1,41 +0,0 @@
-Segmentation fault when introspecting machine properties
-Description of problem:
-QEMU currrently crashes when trying to list the properties of the q35 machine type while QEMU has been started with the i440fx machine type. Introspecting QOM objects for their properties should always be possible, but apparently there is currently something causing a crash in this case.
-Steps to reproduce:
-1. Start QEMU with: qemu-system-x86_64 -M pc -qmp stdio
-2. Enter these commands in the QMP monitor:
-
-```
- { "execute": "qmp_capabilities" }
- { "execute": "qom-list-properties","arguments": { "typename": "pc-q35-10.0-machine"}}
-```
-Additional information:
-Backtrace looks like this:
-```
-mc146818rtc_set_cmos_data (s=0x0, addr=95, val=-1) at ../../devel/qemu/hw/rtc/mc146818rtc.c:738
-738	        s->cmos_data[addr] = val;
---Type <RET> for more, q to quit, c to continue without paging--#0  mc146818rtc_set_cmos_data (s=0x0, addr=95, val=-1) at ../../devel/qemu/hw/rtc/mc146818rtc.c:738
-#1  0x0000555555bf15d2 in pc_machine_done (notifier=0x555557f40750, data=<optimized out>) at ../../devel/qemu/hw/i386/pc.c:632
-#2  0x0000555555d4f7a2 in object_init_with_type (obj=obj@entry=0x555557f40320, ti=ti@entry=0x5555579c3c60)
-    at ../../devel/qemu/qom/object.c:424
-#3  0x0000555555d49c7e in object_initialize_with_type (obj=0x555557f40320, size=<optimized out>, type=type@entry=0x5555579c3c60)
-    at ../../devel/qemu/qom/object.c:570
-#4  0x0000555555d4a660 in object_new_with_type (type=0x5555579c3c60) at ../../devel/qemu/qom/object.c:774
-#5  object_new (typename=typename@entry=0x555558672b30 "pc-q35-10.0-machine") at ../../devel/qemu/qom/object.c:789
-#6  0x0000555555e825c5 in qmp_qom_list_properties (typename=0x555558672b30 "pc-q35-10.0-machine", errp=errp@entry=0x7fffffffd988)
-    at ../../devel/qemu/qom/qom-qmp-cmds.c:205
-#7  0x0000555555ef0525 in qmp_marshal_qom_list_properties (args=<optimized out>, ret=0x7fffeda9af00, errp=0x7fffeda9af08)
-    at qapi/qapi-commands-qom.c:288
-#8  0x0000555555f1edc1 in do_qmp_dispatch_bh (opaque=0x7fffeda9aed0) at ../../devel/qemu/qapi/qmp-dispatch.c:128
-#9  0x0000555555f40e28 in aio_bh_poll (ctx=ctx@entry=0x5555579f2930) at ../../devel/qemu/util/async.c:219
-#10 0x0000555555f2886f in aio_dispatch (ctx=0x5555579f2930) at ../../devel/qemu/util/aio-posix.c:424
-#11 0x0000555555f41cbb in aio_ctx_dispatch (source=0x0, callback=0x5f, user_data=<optimized out>) at ../../devel/qemu/util/async.c:361
-#12 0x00007ffff6d98e8c in g_main_context_dispatch_unlocked.lto_priv () at /lib64/libglib-2.0.so.0
-#13 0x00007ffff6d99155 in g_main_context_dispatch () at /lib64/libglib-2.0.so.0
-#14 0x0000555555f42540 in glib_pollfds_poll () at ../../devel/qemu/util/main-loop.c:287
-#15 os_host_main_loop_wait (timeout=<optimized out>) at ../../devel/qemu/util/main-loop.c:310
-#16 main_loop_wait (nonblocking=nonblocking@entry=0) at ../../devel/qemu/util/main-loop.c:589
-#17 0x0000555555ae1207 in qemu_main_loop () at ../../devel/qemu/system/runstate.c:835
-#18 0x0000555555e85d57 in qemu_default_main (opaque=<optimized out>) at ../../devel/qemu/system/main.c:48
-#19 0x0000555555e85d2f in main (argc=<optimized out>, argv=<optimized out>) at ../../devel/qemu/system/main.c:76
-```
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2783 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2783
deleted file mode 100644
index b9bebd68b..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/2783
+++ /dev/null
@@ -1,17 +0,0 @@
-Cannot install a fresh Windows 7 32-bit guest with Q35 machine type (mouse and keyboard do not function, so cannot continue install)
-Description of problem:
-When trying to install Windows 7 32-bit via the official SP1 installation ISO, the machine boots the installer, but both keyboard and mouse do not function, so the installation cannot proceed.
-Steps to reproduce:
-1. Using virt-manager, create a new VM using the x86 version of the Windows 7 SP1 install ISO found here: https://archive.org/details/windows-7-professional-with-sp1-x64-dvd-iso
-2. Select `Microsoft Windows 7` as the Operating System type, which uses Q35 as the machine type
-3. Click Begin Installation
-4. See the Windows 7 installer screen show up
-5. Keyboard and mouse inputs don't work at all, mouse cursor also doesn't appear
-Additional information:
-I've tried using `Microsoft Windows XP` as the Operating System in virt-manager, which switches to i440FX as the machine type, and the issue doesn't appear: keyboard and mouse both work perfectly. But of course, it would be nice to use Q35 instead to get USB 3.0, PCI-E, etc.
-
-![image](/uploads/41f7e9b5f1293f6a153582cf066d114f/image.png)
-Notice the lack of cursor in the screenshot above on Q35.
-
-When using a i440FX machine, the white Windows cursor will appear:
-![image](/uploads/bbafdd23b06e60fe862f1cd6262483f2/image.png)
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2813 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2813
deleted file mode 100644
index c2a15045e..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/2813
+++ /dev/null
@@ -1,9 +0,0 @@
-Cannot emulate Windows 95 / 98
-Description of problem:
-If install Windows 95 / 98 on that configuration, Windows 95 / 98 crashed on "While initializing device NDIS: Windows protection error." message, or QEMU crashed. With this command line Windows 95 / 98 can worked on previous QEMU 7.<br>And please don't allow IME input on CJK (Chinese / Japanese / Korean) host system (that relied IME to input some text). Such input process is done by the IME in CJK operating system guest.
-Steps to reproduce:
-1.
-2.
-3.
-Additional information:
-
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2816 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2816
deleted file mode 100644
index 9edd84ed2..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/2816
+++ /dev/null
@@ -1,14 +0,0 @@
-qemu-9.2.1 windows can not load files if kernel is linux-6.13.x
-Description of problem:
-qemu-9.2 and 9.2.1 emulating windows-10 both gave this
-bug "externe exception 80000004." emulating windows-10
-when a program tries to load a file. 
-qemu emulating windows-10 runs without this bug when using
-kernel linux-6.12.14 and older.
-Steps to reproduce:
-1.start a prog, in my case sprint-layout-6.0, try to open/load a file.
-2.
-3.
-Additional information:
-Im not shure if the bug is with qemu or kernel.
-You can decide better what causes this bug.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2817 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2817
deleted file mode 100644
index 0f00a05f5..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/2817
+++ /dev/null
@@ -1,51 +0,0 @@
-Strange floating-point behaviour under Windows with some CPU models
-Description of problem:
-I'm encountering a very weird bug with some floating-point maths code, but only under very specific configurations. First I thought it was a Clang bug, but then further digging eventually showed it to only occur under Windows VMs with specific QEMU CPU options, I'm not certain whether it is a QEMU/KVM bug or a Windows bug, but thought starting here would be easiest.
-
-When compiled under MSVC Clang with modern CPU instructions disabled (e.g. `-march=pentium3` or `-march=pentium-mmx`), the `floorf()` call in the following program always returns 0.0, while the truncation works correctly:
-
-```
-#include <math.h>
-#include <stdio.h>
-#include <stdlib.h>
-
-int main(int argc, char **argv)
-{
-	float n = atof(argv[1]);
-	printf("n = %f\n", n);
-	
-	float f = floorf(n);
-	printf("f = %f\n", f);
-	
-	float c = (int)(n);
-	printf("c = %f\n", c);
-	
-	return 0;
-}
-```
-
-Example output on an affected VM:
-
-```
-C:\Users\Administrator> floorf-p3.exe 10
-n = 10.000000
-f = 0.000000
-c = 10.000000
-
-C:\Users\Administrator> floorf-p4.exe 10
-n = 10.000000
-f = 10.000000
-c = 10.000000
-```
-
-(`floorf-p3.exe` was compiled with `-march=pentium3` and `floorf-p4.exe` with `-march=pentium4` above)
-
-I've tried a few QEMU CPU models on a variety of Intel/AMD VM hosts and two different Windows versions (10 and Server 2022), and observed the following:
-
-* `host-passthrough` - works (on AMD and Intel hosts)
-* `qemu64` - broken
-* `EPYC-Milan` - works
-* `Westmere` - works
-* `Penryn` - broken
-
-(I also reported this via the mailing list, but I think it might've swallowed my post)
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2832 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2832
deleted file mode 100644
index dcb183858..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/2832
+++ /dev/null
@@ -1,99 +0,0 @@
-Random kernel panic (2/3) in github macOS runner: IO-APIC + timer doesn't work!
-Description of problem:
-Random kernel panic (2/3 runs average) with this traceback:
-
-```
-[    0.020000] Kernel panic - not syncing: IO-APIC + timer doesn't work!  Boot with apic=debug and send a report.  Then try booting with the 'noapic' option.
-[    0.020000] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.11.0-14-generic #15-Ubuntu
-[    0.020000] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS edk2-stable202408-prebuilt.qemu.org 08/13/2024
-[    0.020000] Call Trace:
-[    0.020000]  <TASK>
-[    0.020000]  show_stack+0x49/0x60
-[    0.020000]  dump_stack_lvl+0x5f/0x90
-[    0.020000]  dump_stack+0x10/0x18
-[    0.020000]  panic+0x16a/0x328
-[    0.020000]  check_timer+0x4d1/0x570
-[    0.020000]  setup_IO_APIC+0x1e5/0x210
-[    0.020000]  apic_intr_mode_init+0xd0/0xf0
-[    0.020000]  x86_late_time_init+0x24/0x40
-[    0.020000]  start_kernel+0x3f9/0x4a0
-[    0.020000]  x86_64_start_reservations+0x24/0x30
-[    0.020000]  x86_64_start_kernel+0xf2/0x100
-[    0.020000]  common_startup_64+0x13e/0x141
-[    0.020000]  </TASK>
-[    0.020000] ---[ end Kernel panic - not syncing: IO-APIC + timer doesn't work!  Boot with apic=debug and send a report.  Then try booting with the 'noapic' option. ]---
-```
-Steps to reproduce:
-1. Start qemu in macos-13 github runner
-Additional information:
-Example failed build:
-https://github.com/nirs/vmnet-helper/actions/runs/13477646025/job/37658748139
-
-serial.log:
-```
-3h3hBdsDxe: failed to load Boot0001 "UEFI QEMU QEMU CD-ROM " from PciRoot(0x0)/Pci(0x1,0x0)/Scsi(0x0,0x0): Not Found
-BdsDxe: loading Boot0002 "UEFI Misc Device" from PciRoot(0x0)/Pci(0x3,0x0)
-BdsDxe: starting Boot0002 "UEFI Misc Device" from PciRoot(0x0)/Pci(0x3,0x0)
-EFI stub: Loaded initrd from LINUX_EFI_INITRD_MEDIA_GUID device path
-[    0.000000] Linux version 6.11.0-14-generic (buildd@lcy02-amd64-032) (x86_64-linux-gnu-gcc-14 (Ubuntu 14.2.0-4ubuntu2) 14.2.0, GNU ld (GNU Binutils for Ubuntu) 2.43.1) #15-Ubuntu SMP PREEMPT_DYNAMIC Fri Jan 10 23:48:25 UTC 2025 (Ubuntu 6.11.0-14.15-generic 6.11.0)
-[    0.000000] Command line: BOOT_IMAGE=/vmlinuz-6.11.0-14-generic root=LABEL=cloudimg-rootfs ro console=tty1 console=ttyS0
-[    0.000000] KERNEL supported cpus:
-[    0.000000]   Intel GenuineIntel
-[    0.000000]   AMD AuthenticAMD
-[    0.000000]   Hygon HygonGenuine
-[    0.000000]   Centaur CentaurHauls
-[    0.000000]   zhaoxin   Shanghai  
-[    0.000000] BIOS-provided physical RAM map:
-[    0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009ffff] usable
-[    0.000000] BIOS-e820: [mem 0x0000000000100000-0x00000000007fffff] usable
-[    0.000000] BIOS-e820: [mem 0x0000000000800000-0x0000000000807fff] ACPI NVS
-[    0.000000] BIOS-e820: [mem 0x0000000000808000-0x000000000080afff] usable
-[    0.000000] BIOS-e820: [mem 0x000000000080b000-0x000000000080bfff] ACPI NVS
-[    0.000000] BIOS-e820: [mem 0x000000000080c000-0x0000000000810fff] usable
-[    0.000000] BIOS-e820: [mem 0x0000000000811000-0x00000000008fffff] ACPI NVS
-[    0.000000] BIOS-e820: [mem 0x0000000000900000-0x000000003ee41fff] usable
-[    0.000000] BIOS-e820: [mem 0x000000003ee42000-0x000000003ef02fff] reserved
-[    0.000000] BIOS-e820: [mem 0x000000003ef03000-0x000000003f8ecfff] usable
-[    0.000000] RCU Tasks: Setting shift to 0 and lim to 1 rcu_task_cb_adjust=1.
-[    0.000000] RCU Tasks Rude: Setting shift to 0 and lim to 1 rcu_task_cb_adjust=1.
-[    0.000000] RCU Tasks Trace: Setting shift to 0 and lim to 1 rcu_task_cb_adjust=1.
-[    0.000000] NR_IRQS: 524544, nr_irqs: 256, preallocated irqs: 16
-[    0.000000] rcu: srcu_init: Setting srcu_struct sizes based on contention.
-[    0.000000] Console: colour dummy device 80x25
-[    0.000000] printk: legacy console [tty1] enabled
-[    0.000000] printk: legacy console [ttyS0] enabled
-[    0.000000] ACPI: Core revision 20240322
-[    0.000000] clocksource: hpet: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604467 ns
-[    0.001000] APIC: Switch to symmetric I/O mode setup
-[    0.003000] x2apic: IRQ remapping doesn't support X2APIC mode
-[    0.011000] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
-[    0.013000] ..MP-BIOS bug: 8254 timer not connected to IO-APIC
-[    0.013000] ...trying to set up timer (IRQ0) through the 8259A ...
-[    0.013000] ..... (found apic 0 pin 2) ...
-[    0.014000] ....... failed.
-[    0.014000] ...trying to set up timer as Virtual Wire IRQ...
-[    0.018000] ..... failed.
-[    0.018000] ...trying to set up timer as ExtINT IRQ...
-[    0.020000] ..... failed :(.
-[    0.020000] Kernel panic - not syncing: IO-APIC + timer doesn't work!  Boot with apic=debug and send a report.  Then try booting with the 'noapic' option.
-[    0.020000] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.11.0-14-generic #15-Ubuntu
-[    0.020000] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS edk2-stable202408-prebuilt.qemu.org 08/13/2024
-[    0.020000] Call Trace:
-[    0.020000]  <TASK>
-[    0.020000]  show_stack+0x49/0x60
-[    0.020000]  dump_stack_lvl+0x5f/0x90
-[    0.020000]  dump_stack+0x10/0x18
-[    0.020000]  panic+0x16a/0x328
-[    0.020000]  check_timer+0x4d1/0x570
-[    0.020000]  setup_IO_APIC+0x1e5/0x210
-[    0.020000]  apic_intr_mode_init+0xd0/0xf0
-[    0.020000]  x86_late_time_init+0x24/0x40
-[    0.020000]  start_kernel+0x3f9/0x4a0
-[    0.020000]  x86_64_start_reservations+0x24/0x30
-[    0.020000]  x86_64_start_kernel+0xf2/0x100
-[    0.020000]  common_startup_64+0x13e/0x141
-[    0.020000]  </TASK>
-[    0.020000] ---[ end Kernel panic - not syncing: IO-APIC + timer doesn't work!  Boot with apic=debug and send a report.  Then try booting with the 'noapic' option. ]---
-```
-
-Same Ubuntu image never fail with vfkit vm on the same macos-13 github runners.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2833 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2833
deleted file mode 100644
index 8767f8b29..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/2833
+++ /dev/null
@@ -1,19 +0,0 @@
-Inconsistent `Tn_INT_ROUTE_CAP` and `Tn_INT_ROUTE_CNF` in HPET
-Description of problem:
-In the [HPET specification](http://www.intel.com/content/dam/www/public/us/en/documents/technical-specifications/software-developers-hpet-spec-1-0a.pdf) it says:
->  Timer n Interrupt Routing Capability: (where n is the timer number: 00 to 31) This 32-bit read-only field indicates to which interrupts in the I/O (x) APIC this timer’s interrupt can be routed. This is used in conjunction with the Tn_INT_ROUTE_CNF field.
-> 
-> Each bit in this field corresponds to a particular interrupt. For example, if this timer’s interrupt can be mapped to interrupts 16, 18, 20, 22, or 24, then bits 16, 18, 20, 22, and 24 in this field will be set to 1. All other bits will be 0.
-
-
-> Timer n Interrupt Route: (where n is the timer number: 00 to 31). This 5-bit read/write field indicates the routing for the interrupt to the I/O APIC. A maximum value of 32 interrupts are supported. Default is 00h Software writes to this field to select which interrupt in the I/O (x) will be used for this timer’s interrupt. If the value is not supported by this prarticular timer, then the value read back will not match what is written. The software must only write valid values.
-
-In QEMU, the HPET timers indicate that the only I/O APIC IRQ they support is IRQ 2 (based only bit 2 being 1). But actually the HPET interrupt works even if I set it to IRQ 20, which is inconsistent with the `Tn_INT_ROUTE_CAP` that the timer shows.
-
-The HPET should show that it works with more than just IRQ 2.
-Steps to reproduce:
-1. Git checkout https://github.com/ChocolateLoverRaj/code-runner/tree/fd368f53c1c99885a3b149a59f2959f383f42859
-2. `nix develop`
-3. `cargo r -- -s -serial mon:stdio --no-reboot -nographic -d int`
-Additional information:
-
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2834 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2834
deleted file mode 100644
index 18e2f8b54..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/2834
+++ /dev/null
@@ -1,19 +0,0 @@
-qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.07H:EBX.intel-pt [bit 25]
-Description of problem:
-when run `./qemu-system-x86_64  -cpu host,intel_pt  -m 8192M -smp 4 -hda  ubuntu.qcow2  --enable-kvm --nographic` warning `qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.07H:EBX.intel-pt [bit 25]`.
-Tried adding level/min-level=0x14, but still received a warning.
-Steps to reproduce:
-run command 
-```
-./qemu-system-x86_64  -cpu host,intel_pt  -m 8192M -smp 4 -hda  ubuntu.qcow2  --enable-kvm --nographic
-```
-Additional information:
-- CPU i5-13600kf
-```
-~$ sudo rdmsr 0x485 -f 14:14 # MSR_IA32_VMX_MISC_INTEL_PT
-1
-~$ sudo rdmsr 0x48B -f 56:56 # SECONDARY_EXEC_PT_USE_GPA
-1
-~$ sudo rdmsr 0x484 -f 50:50 # VM_ENTRY_LOAD_IA32_RTIT_CTL
-1
-```
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2848 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2848
deleted file mode 100644
index 3168b8646..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/2848
+++ /dev/null
@@ -1,13 +0,0 @@
-i386 max_cpus off by one
-Description of problem:
-X86 VMs are currently limited to 255 vCPUs (`mc->max_cpus = 255;` in `pc.c`).
-The first occurrence i can find of this limit is in d3e9db933f416c9f1c04df4834d36e2315952e42 from 2005 where both `MAX_APICS` and `MAX_CPUS` was set to 255. This is becoming relevant for some people as servers with 256 cores become more available. 
-
-**Can we increase the limit to 256 vCPUs?** 
-I think so. 
-
-Today, the APIC id limit (see `apic_id_limit` in `x86-common.c`) is based on the CPU id limit. 
-According to the a comment for `typdef uint32_t apic_id_t;` (see `topology.h`), we can have 256 APICs, but more APICs require x2APIC support. 
-APIC seems to be no hindrance to increase max_cpus to 256. 
-
-**Can we increase the limit to 512?** Maybe not? We need x2APIC support of which i have no clue. Also there is always a performance risk of exceeding the size at which current data structures work efficiently.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2868 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2868
deleted file mode 100644
index 0936a6585..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/2868
+++ /dev/null
@@ -1,3 +0,0 @@
-amd iommu pte is only 32bits not 64bits.
-Additional information:
-
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2869 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2869
deleted file mode 100644
index 9235c4bd3..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/2869
+++ /dev/null
@@ -1,3 +0,0 @@
-enable guest mode at amd iommu
-Additional information:
-
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2874 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2874
deleted file mode 100644
index 6071c3848..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/2874
+++ /dev/null
@@ -1,9 +0,0 @@
-AMD Ryzen 9950x with -smp option yields "warning: This family of AMD CPU doesn't support hyperthreading"
-Description of problem:
-When using the above -smp option (`-smp 32,sockets=1,dies=1,clusters=1,cores=16,threads=2`), which should be valid for the Ryzen 9950X 16 cores / 32 threads CPU, QEMU prints:
-```
-qemu-system-x86_64: warning: This family of AMD CPU doesn't support hyperthreading(2). Please configure -smp options properly or try enabling topoext feature.
-```
-This is unexpected.  This CPU should support hyperthreading out of the box, it seems.
-Steps to reproduce:
-1. Run command above on Ryzen 9950X or similar CPU.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2882 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2882
deleted file mode 100644
index ee5f22885..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/2882
+++ /dev/null
@@ -1,90 +0,0 @@
-Reading ACPI info via fw_cfg in SVSM causes Linux to panic
-Description of problem:
-We could use some help from a Qemu expert with an Qemu/ACPI/Linux related problem,
-working on Coconut SVSM.
-
-**See https://github.com/coconut-svsm/svsm/issues/646**
-
-Coconut has code to read ACPI information via fw_cfg, and extract the number of guest CPUs from that.
-That code has been used in the past, but since igvm became the default launch method for SVSM, it
-was only used in corner-cases, while the information were obtained in some other way (igmv parameter).
-Now a commit switches back to the fw_cfg+ACPI method. The information returned by it is correct, but
-strangely Linux (guest) is spitting out ACPI related errors and crashes in some cases before reaching user-space. We do not have any clue how this can be related other than through Qemu behavior. 
-There is no direct way how SVSM can influence the ACPI related behavior of the Linux
-guest kernel.
-
-The problem seems to be caused by simply reading the ACPI data.
-
-Reverting the bad commit and simply calling the original fw_cfg acpi function causes problems for Linux.
-Steps to reproduce:
-Boot SVSM bases CVM. SVSM and OVMF boot OK, then Linux prints these errors in some scenarios panics:
-```
-[...]
-[    1.857709] ACPI: Added _OSI(Processor Aggregator Device)
-[    1.859436] ACPI: 1 ACPI AML tables successfully acquired and loaded
-[    1.860867] ACPI Error: AE_BAD_ADDRESS, Unable to initialize fixed events (20240827/evevent-53)
-[    1.862709] ACPI: Unable to start the ACPI Interpreter
-[    1.863708] ACPI Error: Could not remove SCI handler (20240827/evmisc-251)
-[    1.864942] ACPI Error: AE_BAD_PARAMETER, Thread 2176690624 could not acquire Mutex [ACPI_MT
-X_Namespace] (0x1) (20240827/utmutex-252)
-[    1.866715] ACPI Error: AE_BAD_PARAMETER, Thread 2176690624 could not acquire Mutex [ACPI_MTX_Tables] (0x2) (20240827/utmutex-252)
-[    1.869722] ACPI Error: Mutex [ACPI_MTX_Tables] (0x2) is not acquired, cannot release (20240
-827/utmutex-289)
-[    1.870826] iommu: Default domain type: Translated
-[    1.871710] iommu: DMA domain TLB invalidation policy: lazy mod
-[...]
-[    2.672635] io scheduler bfq registered
-[    2.675679] atomic64_test: passed for x86-64 platform with CX8 and with SSE
-[    2.677596] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4
-[    2.679264] ------------[ cut here ]------------
-[    2.680284] refcount_t: addition on 0; use-after-free.
-[    2.681477] WARNING: CPU: 3 PID: 1 at lib/refcount.c:25 refcount_warn_saturate+0xe5/0x110
-[    2.683261] Modules linked in:
-[    2.683929] CPU: 3 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.13.6-200.fc41.x86_64 #1
-[    2.685608] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS edk2-stable202502-39-gb
-483f751 02/02/2022
-[    2.687729] RIP: 0010:refcount_warn_saturate+0xe5/0x110
-[    2.688853] Code: e3 7f ff 0f 0b e9 fb 0a 8a 00 80 3d 15 9f 23 02 00 0f 85 5e ff ff ff 48 c7 c7 30 7b e7 8c c6 05 01 9f 23 02 01 e8 fb e2 7f ff <0f> 0b e9 d4 0a 8a 00 48 c7 c7 88 7b e7 8c
- c6 05 e5 9e 23 02 01 e8
-[    2.692768] RSP: 0018:ffffb2ed0001fd90 EFLAGS: 00010282
-[    2.693894] RAX: 0000000000000000 RBX: ffff975b81060a80 RCX: ffffffff8d967448
-[    2.695410] RDX: 0000000000000000 RSI: 0000000000000003 RDI: 0000000000000001
-[    2.696923] RBP: ffffb2ed0001fe38 R08: 0000000000000000 R09: 0720072007200720
-[    2.698439] R10: 0720072007200720 R11: 0720072007200720 R12: ffff975b81060a80
-[    2.699955] R13: ffffb2ed0001fe78 R14: 00000000000000dc R15: 00000000000001df
-[    2.701461] FS:  0000000000000000(0000) GS:ffff975cf7d80000(0000) knlGS:0000000000000000
-[    2.703179] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
-[    2.704400] CR2: 00007f1c1658a3c8 CR3: 000800006082c000 CR4: 00000000003506f0
-[    2.705910] Call Trace:
-[    2.706451]  <TASK>
-[    2.706922]  ? srso_return_thunk+0x5/0x5f
-[    2.707820]  ? show_trace_log_lvl+0x255/0x2f0
-[    2.708783]  ? show_trace_log_lvl+0x255/0x2f0
-[    2.709712]  ? kobject_get+0x68/0x70
-[    2.710492]  ? refcount_warn_saturate+0xe5/0x110
-[    2.711480]  ? __warn.cold+0x93/0xfa
-[    2.712268]  ? refcount_warn_saturate+0xe5/0x110
-[    2.713262]  ? report_bug+0xff/0x140
-[    2.714036]  ? handle_bug+0x58/0x90
-[    2.714779]  ? exc_invalid_op+0x17/0x70
-[    2.715617]  ? asm_exc_invalid_op+0x1a/0x20
-[    2.716526]  ? refcount_warn_saturate+0xe5/0x110
-[    2.717507]  kobject_get+0x68/0x70
-[    2.718266]  kobject_add_internal+0x32/0x250
-[    2.719196]  kobject_add+0x96/0xc0
-[    2.719923]  kobject_create_and_add+0xa3/0xc0
-[    2.720851]  bgrt_init+0x77/0xc0
-[    2.721578]  ? __pfx_bgrt_init+0x10/0x10
-[    2.722418]  do_one_initcall+0x5b/0x310
-[    2.723272]  do_initcalls+0x147/0x170
-[    2.724086]  ? __pfx_kernel_init+0x10/0x10
-[    2.725174]  kernel_init_freeable+0xfb/0x130
-[    2.726114]  kernel_init+0x1a/0x140
-[    2.726883]  ret_from_fork+0x34/0x50
-[    2.727679]  ? __pfx_kernel_init+0x10/0x10
-[    2.728580]  ret_from_fork_asm+0x1a/0x30
-[    2.729429]  </TASK>
-[    2.729926] ---[ end trace 0000000000000000 ]---
-```
-Additional information:
-
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2892 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2892
deleted file mode 100644
index 464f7b779..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/2892
+++ /dev/null
@@ -1 +0,0 @@
-Outdated documentation about MicroVMs
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2894 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2894
deleted file mode 100644
index 7c87f4751..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/2894
+++ /dev/null
@@ -1,25 +0,0 @@
-There is a bug in versions 2025-02-10 and later that causes virtual machines to be created with incorrect SMP settings with warnings about TCG features when setting more than 2 cores with the smp option in the default TCG acceleration (see main text).
-Description of problem:
-When using qemu-system-x86_64 in versions 9.2.50 and later, if you create a virtual machine with 2 or more cores using the smp option,
-
-```
-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]
-```
-The log will be displayed as many as the number of cores you have enabled, and the created virtual machine will be displayed as having a 1-core CPU with the number of cores you have enabled.
-* I have not tested whether the same symptom occurs on versions 9.2.50 and later for other environments (Linux and the WoA version released on March 26th).
-Steps to reproduce:
-1. Create a virtual machine with more than two cores using TCG acceleration, which is the default acceleration, by using options such as 'qemu-system-x86_64 -smp 2' or 'qemu-system-x86_64 -smp sockets=1,cores=2,threads=1'.
-2. 'qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:EDX.ht [bit 28]' and
-'qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.80000001H:ECX.cmp-legacy [bit 1]'
-The log is generated as many as the number of cores set and the virtual machine is created.
-3. When checking the CPU information of the booted virtual machine, it does not show that there is one CPU with the specified number of cores, but rather that there is a single core CPU with the specified number of cores.
-Additional information:
-```
->qemu-system-x86_64 -M q35 -smp 2 -m 4g -display sdl -usb -device usb-tablet -drive file=MasterOS.vdi,id=disk,if=none -drive file="C:\Program Files\qemu\share\edk2-x86_64-code.fd",id=efi,readonly=on,format=raw,if=pflash -device ahci,id=ahci -device ide-hd,drive=disk,bus=ahci.1 -rtc base=localtime
-```
-![스크린샷_2025-03-31_164120](/uploads/4ddc95e8f90532e9c22d4f7c5c181c1a/스크린샷_2025-03-31_164120.png)
-```
->qemu-system-x86_64 -M q35 -smp 4 -m 4g -display sdl -usb -device usb-tablet -drive file=MasterOS.vdi,id=disk,if=none -drive file="C:\Program Files\qemu\share\edk2-x86_64-code.fd",id=efi,readonly=on,format=raw,if=pflash -device ahci,id=ahci -device ide-hd,drive=disk,bus=ahci.1 -rtc base=localtime
-```
-![스크린샷_2025-03-31_164917](/uploads/978d86c5f1b1d81230a0e96cd1bd10b9/스크린샷_2025-03-31_164917.png)
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2897 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2897
deleted file mode 100644
index 141333761..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/2897
+++ /dev/null
@@ -1,14 +0,0 @@
-Can't boot SeaBIOS based VM when using -display gtk, works fine with vnc or sdl
-Description of problem:
-When using -display gtk, SeaBIOS hangs nondeterministicly. Changing to -display sdl or -display vnc lets it boot.
-Steps to reproduce:
-1. Run `qemu-system-x86_64 -display gtk` and the VM will not complete BIOS POST.
-2. Run `qemu-system-x86_64 -display sdl` and the VM will complete BIOS POST.
-Additional information:
-This ONLY happens with SeaBIOS. Using a UEFI BIOS to boot the VM does not cause this issue. 
-
-I realise this is a crazy bug. I suspect that the only way it could have slipped through testing is because it *requires* human interaction.
-
-There is no difference with using --accel kvm or not, but I have provided the smallest possible command line to duplicate the issue, which is literally just `qemu-system-x86_64 -display gtk`
-
-#
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2922 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2922
deleted file mode 100644
index 213030e4a..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/2922
+++ /dev/null
@@ -1,7 +0,0 @@
-x86 reverse-debugging test is unreliable
-Description of problem:
-The reverse-debugging test for the x86 target is not working reliably. If the host system is under load, the test simply hangs and finally times out.
-Steps to reproduce:
-1. ``make check-venv``
-2. Run something in the background that keeps all CPUs busy
-3. ``for ((x=0;x<10;x++)); do QEMU_TEST_FLAKY_TESTS=1 pyvenv/bin/avocado run tests/avocado/reverse_debugging.py:ReverseDebugging_X86_64.test_x86_64_pc  ; done``
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2954 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2954
deleted file mode 100644
index 832398647..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/2954
+++ /dev/null
@@ -1,19 +0,0 @@
-SD card is not visible by UEFI
-Description of problem:
-SD card is not visible by OVMF UEFI, so it's not possible to boot from it:
-```
-UEFI Interactive Shell v2.2
-EDK II
-UEFI v2.70 (EDK II, 0x00010000)
-Mapping table
-     BLK0: Alias(s):
-          PciRoot(0x0)/Pci(0x1,0x1)/Ata(0x0)
-Press ESC in 1 seconds to skip startup.nsh or any other key to continue.
-Shell>
-```
-It is visible by SeaBIOS though, if we remove the OVMF part from the commandline:
-```
-qemu-system-x86_64 -device sdhci-pci -drive if=none,file=Fedora-IoT-ostree-41-20241027.0.x86_64.iso,format=raw,id=MMC1 -device sd-card,drive=MMC1
-```
-
-@philmd
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2961 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2961
deleted file mode 100644
index 254966cb6..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/2961
+++ /dev/null
@@ -1,31 +0,0 @@
-isapc: RTC refactor caused regression in qemu>=8.2 (broke Xenix, maybe others)
-Description of problem:
-I've been playing a bit with retro UNIXes and wanted to try a Xenix install.
-
-There are several webpages giving hints for installing Xenix under old versions of QEMU.  The good news: most of the workarounds and tweaks they mention seem to be no longer needed.  Starting with a Homebrew-supplied qemu 10.0.0 on my laptop I was able to do a basic install _without_ having to tweak the floppy geometry or anything like that.
-
-The bad news: once the install was complete and I tried to reboot from the harddrive it hangs at the...
-```
-Boot
-:
-```
-...prompt.  It doesn't respond to any keystrokes at this point.  This prompt is printed by the second-stage loader (called `/boot` on the Xenix filesystem) which is a real-mode 8086 binary.
-
-To debug this further I moved to a more familiar Linux developer environment and found that the qemu that is stock with Debian 12.10 (7.2.15) did *not* exhibit the same problem!
-
-I manually bisected through the released versions and found that it definitely broke some time in the 8.2 release cycle: 8.1.5 worked, 8.2.0rc0 did not.  I then did a git checkout and started building qemu, using `git bisect` to find the guilty commit.
-
-Soon I came across 56b1f50e3c101bfe5f52bac73de0e88438de11bd from @shentey -- a change which moved connecting the RTC's ISA interrupt from `pc_basic_device_init()` down into `*_realize()` when a Southbridge is configured.  I was able to confirm that before this commit I could boot, but after it I could not.
-
-I verified using gdb that `pc_basic_device_init()` is being called but the functions that the initialization had moved to were not (or at least weren't called *yet*). So after this change this RTC irq wasn't being wired up, which apparently broke the second-stage Xenix loader.
-
-I then went back to git tip and found that reverting the 56b1f50e3c1 commit was enough to fix the problem there as well.
-
-I don't know enough about the qemu internals to judge whether the original change made sense.  Therefore, I won't claim that reverting it is the correct approach to fix the bug.  However, it did work for me.
-
-The Southbridge code has been reorged a little since 8.2 but the functional revert is still pretty straightfoward.  Here is the diff I used:
-[revert-56b1f50e3c1.patch](/uploads/573754b8af3d7ddb97d5f973cb0003db/revert-56b1f50e3c1.patch)
-Steps to reproduce:
-1. Install Xenix 2.3.4 from https://archive.org/details/sco-xenix-386-and-extras
-2. After some enjoyable floppy juggling, be amazed at how smoothly the install went
-3. Try to boot from the harddrive afterwards and weep
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2987 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2987
deleted file mode 100644
index 9efe925fb..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/2987
+++ /dev/null
@@ -1,7 +0,0 @@
-QEMU TCG failed to boot Windows 98 Second Edition
-Description of problem:
-QEMU TCG failed at booting Windows 98 Second Edition 4.10.2222B.
-
-Bisected to commit e54ef98c8a80d16158bab4341d9a898701270528
-Additional information:
-![Screenshot_2025-05-29_at_5.15.14_PM](/uploads/1cf0cf2435c1227df895f37496239c66/Screenshot_2025-05-29_at_5.15.14_PM.png)
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/320 b/gitlab/issues_text/target_i386/host_missing/accel_missing/320
deleted file mode 100644
index f20b75a59..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/320
+++ /dev/null
@@ -1 +0,0 @@
-Corsair iCUE Install Fails, qemu VM Reboots
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/331 b/gitlab/issues_text/target_i386/host_missing/accel_missing/331
deleted file mode 100644
index a5c9389ca..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/331
+++ /dev/null
@@ -1 +0,0 @@
-Incorrect feature negotiation for vhost-vdpa netdevice
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/368 b/gitlab/issues_text/target_i386/host_missing/accel_missing/368
deleted file mode 100644
index edc13885a..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/368
+++ /dev/null
@@ -1 +0,0 @@
-virtiofsd: doesn't garant write access at users allowed by group permission
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/375 b/gitlab/issues_text/target_i386/host_missing/accel_missing/375
deleted file mode 100644
index 825658283..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/375
+++ /dev/null
@@ -1 +0,0 @@
-MacOS 11.4 (x86_64) Host - USB passthrough appears to be broken
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/387 b/gitlab/issues_text/target_i386/host_missing/accel_missing/387
deleted file mode 100644
index 7cdf7e5c6..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/387
+++ /dev/null
@@ -1 +0,0 @@
-SD-Card not working anymore on x86 targets
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/389 b/gitlab/issues_text/target_i386/host_missing/accel_missing/389
deleted file mode 100644
index 450a47ca9..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/389
+++ /dev/null
@@ -1 +0,0 @@
-Add multiboot2 support
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/475 b/gitlab/issues_text/target_i386/host_missing/accel_missing/475
deleted file mode 100644
index abc0972da..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/475
+++ /dev/null
@@ -1 +0,0 @@
-4.2 regression: ReactOS crashes on boot
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/508 b/gitlab/issues_text/target_i386/host_missing/accel_missing/508
deleted file mode 100644
index e8456c5fb..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/508
+++ /dev/null
@@ -1 +0,0 @@
-x86_64 cmpxchg behavior in qemu tcg does not match the real CPU
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/510 b/gitlab/issues_text/target_i386/host_missing/accel_missing/510
deleted file mode 100644
index 593bdae2f..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/510
+++ /dev/null
@@ -1 +0,0 @@
-QEMU registers support on x64
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/512 b/gitlab/issues_text/target_i386/host_missing/accel_missing/512
deleted file mode 100644
index 4edb0505c..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/512
+++ /dev/null
@@ -1 +0,0 @@
-6.1.0-rc1 New regression (not in 6.1.0-rc0): Freezes using UEFI firmware without acceleration
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/525 b/gitlab/issues_text/target_i386/host_missing/accel_missing/525
deleted file mode 100644
index 83948de30..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/525
+++ /dev/null
@@ -1,14 +0,0 @@
-missing features with CPU `qemu64`
-Description of problem:
-The live migration complains about a missing feature when using the CPU qemu64, which is _guaranteed to work_.
-Steps to reproduce:
-1. start the VM with qemu64 on the CPU: Intel(R) Xeon(R) CPU E5-2620 v4 
-2. live-migrate the VM to a CPU: Intel(R) Xeon(R) CPU E5-2670 0
-Additional information:
-The migration fails:
-```
-root@covid21:~# virsh migrate --verbose --live --persistent --undefinesource myvm.local qemu+ssh://covid24/system
-error: operation failed: guest CPU doesn't match specification: missing features: abm
-```
-
-This should not happen on a generic CPU, which should always work. Note, that the migration succeeds when using `-cpu qemu64,abm=off …`
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/536 b/gitlab/issues_text/target_i386/host_missing/accel_missing/536
deleted file mode 100644
index 098024c19..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/536
+++ /dev/null
@@ -1 +0,0 @@
-Null-ptr dereference in ich9_apm_ctrl_changed
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/538 b/gitlab/issues_text/target_i386/host_missing/accel_missing/538
deleted file mode 100644
index f3daca2dc..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/538
+++ /dev/null
@@ -1 +0,0 @@
-Memory Leak in hpet_timer results in unusable machine
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/554 b/gitlab/issues_text/target_i386/host_missing/accel_missing/554
deleted file mode 100644
index 9c04a08d5..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/554
+++ /dev/null
@@ -1 +0,0 @@
-q35 machine type cdrom device not discovered by freedos
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/561 b/gitlab/issues_text/target_i386/host_missing/accel_missing/561
deleted file mode 100644
index a11709d0f..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/561
+++ /dev/null
@@ -1 +0,0 @@
-Q35 - ACPI PCI hot-plug issue with Windows guest
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/627 b/gitlab/issues_text/target_i386/host_missing/accel_missing/627
deleted file mode 100644
index ead59b0cf..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/627
+++ /dev/null
@@ -1,7 +0,0 @@
-VI.EXE crashes on start under QEMU; works under BOCHS
-Description of problem:
-vi.exe hangs on startup; can be verified to work in bochs
-Steps to reproduce:
-1. Run vi.exe from DOS prompt; hang is evident immediately as ~ ~ ~ ~ doesn't show up
-Additional information:
-Actual [vi.exe](/uploads/d77076b8187489253c6ad8f1ab3ec247/vi.exe) attached; it's ridiculously old; the kind of thing that belongs on archive.org; I think I actually own this copy program by inheritance; but if the copyright holder objects we'll have to take it down again. :(
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/629 b/gitlab/issues_text/target_i386/host_missing/accel_missing/629
deleted file mode 100644
index 041d5c0dd..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/629
+++ /dev/null
@@ -1,10 +0,0 @@
-Trying to use EGA or VGA functions from QBASIC doesn't work
-Description of problem:
-QBASIC can't start any graphics mode beyond CGA
-
-Some other programs that default to EGA crash trying to start graphics; none that I've tried can start EGA at all; believe to be the same bug; will file separately if it turns out to not be
-Steps to reproduce:
-1. Boot
-2. Start QBASIC
-3. Run a program consisting of only "SCREEN 12" for VGA or "SCREEN 9" for EGA
-4. Get error message "Illegal Function Call"
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/641 b/gitlab/issues_text/target_i386/host_missing/accel_missing/641
deleted file mode 100644
index ac1b81546..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/641
+++ /dev/null
@@ -1 +0,0 @@
-6.1.0 introduces regression in q35, unable to add more than 15 pcie-root-ports
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/673 b/gitlab/issues_text/target_i386/host_missing/accel_missing/673
deleted file mode 100644
index a217a2797..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/673
+++ /dev/null
@@ -1,10 +0,0 @@
-I can no longer boot with -kernel and -initrd
-Description of problem:
-The kernel refuses to mount the initramfs and proceeds to kernel panic. i didnt have this problem until qemu updated
-Steps to reproduce:
-I have put it all in the git repo of my project
-1. git clone https://github.com/oknowaen/ltl-initramfs.git
-2. cd ltl-initramfs
-3. make (will start automatically)!
-Additional information:
-[Screenshot_20211016_182355](/uploads/c04094f5bcccadc3f8473f2ea6fc864d/Screenshot_20211016_182355.png)
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/705 b/gitlab/issues_text/target_i386/host_missing/accel_missing/705
deleted file mode 100644
index fb2d0f254..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/705
+++ /dev/null
@@ -1,27 +0,0 @@
-Failed to acpi hotplug on pcie root ports in case of q35+ovmf+machine type 6.1
-Description of problem:
-Hotplug on multifunction bridges use ACPI hotplug instead of Native since machine type 6.1
-In this case, Hotplug works well on q35 with bios fireware, But doesn't work on q35 with ovmf firmware.
-E.g:
-/usr/bin/qemu-system-x86_64 \
--machine pc-q35-6.1,accel=kvm,pflash0=...... \
--device pcie-root-port,port=0x10,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x1 \
--device pcie-root-port,port=0x11,chassis=2,id=pci.2,bus=pcie.0,addr=0x1.0x1 \
--device pcie-root-port,port=0x12,chassis=3,id=pci.3,bus=pcie.0,addr=0x1.0x2 \
-......
-
-(qemu) netdev_add bridge,br=br0,id=hostnet1
-(qemu) device_add virtio-net-pci,netdev=hostnet1,id=net1,bus=pci.3
-
-Error message in guest kernel:
-kernel: pci 0000:03:00.0: [1af4:1041] type 00 class 0x020000
-kernel: pci 0000:03:00.0: reg 0x14: [mem 0x00000000-0x00000fff]
-kernel: pci 0000:03:00.0: reg 0x20: [mem 0x00000000-0x00003fff 64bit pref]
-kernel: pci 0000:03:00.0: reg 0x30: [mem 0x00000000-0x0003ffff pref]
-kernel: pci 0000:03:00.0: BAR 6: no space for [mem size 0x00040000 pref]
-kernel: pci 0000:03:00.0: BAR 6: failed to assign [mem size 0x00040000 pref]
-kernel: pci 0000:03:00.0: BAR 4: no space for [mem size 0x00004000 64bit pref]
-kernel: pci 0000:03:00.0: BAR 4: failed to assign [mem size 0x00004000 64bit pref]
-kernel: pci 0000:03:00.0: BAR 1: no space for [mem size 0x00001000]
-kernel: pci 0000:03:00.0: BAR 1: failed to assign [mem size 0x00001000]
-kernel: virtio-pci 0000:03:00.0: virtio_pci: leaving for legacy driver
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/745 b/gitlab/issues_text/target_i386/host_missing/accel_missing/745
deleted file mode 100644
index 1a76fb511..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/745
+++ /dev/null
@@ -1,36 +0,0 @@
-NVRAM is not persistent across coldboots without attached r/w FAT32 hard drive
-Description of problem:
-NVRAM variables are not persistent across coldboots without an attached readable / writable FAT32 hard drive.
-Steps to reproduce:
-Without hard drive:
-1. Start VM as above ("without hard drive attached"), and enter EFI shell.
-2. Dump the contents of a NVRAM variable, e.g. Lang. Note the contents.
-3. Edit the contents of that variable.
-4. Shutdown and restart the VM (cold reboot), and enter the EFI shell.
-5. Dump the contents of the same NVRAM variable. The contents have reverted to what they were in Step 2.
-
-With hard drive:
-1. Start VM as above ("with hard drive attached"), and enter EFI shell.
-2. Navigate to the hard drive filesystem, e.g. FS0.
-3. List the files in the filesystem. If NvVars exists, note the modification time.
-4. Edit the contents of a NVRAM variable, e.g. Lang.
-5. List the files of the filesystem. The NvVars file either now exists, or has notably been modified since Step 3.
-Additional information:
-OVMF blobs used: Those found in the Debian Sid package "ovmf_2021.11_rc1-1_all.deb" (https://packages.debian.org/sid/ovmf)
-
-Note that, without a hard drive attached, edited NVRAM variables persist across warm reboots, e.g. via the EFI shell command `reset`.
-
-I have not tested filesystem formats other than FAT32 with the attached hard drive, though I assume that would be futile due to the UEFI specification stating that EFI only supports FAT-based filesystems by default.
-
-Without HDD attached, before cold reboot:
-![no_hdd_pre-coldboot](/uploads/cb1da3e72a852ff1e7fd1b47afc9ba6e/no_hdd_pre-coldboot.png)
-
-Without HDD attached, after cold reboot:
-![no_hdd_post-coldboot](/uploads/d9622d4571ad8c046f51a00b26e8354e/no_hdd_post-coldboot.png)
-
-With HDD attached (note modification date / time of NvVars):
-![hdd_attached](/uploads/30135dd688f8c7e7ec2feccd69007258/hdd_attached.png)
-
-This issue leads to modern macOS's installation process failing, as it relies on being able to modify NVRAM variables to know how far along in the installation process it is. Without these variables, the installation process will loop indefinitely, as it can't know when to move on to the next part of the overall process.
-
-Let me know if more information is needed, or if this is an issue better suited for the OVMF bug tracker (which I do not know the location of).
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/752 b/gitlab/issues_text/target_i386/host_missing/accel_missing/752
deleted file mode 100644
index a9b99b34d..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/752
+++ /dev/null
@@ -1,13 +0,0 @@
-vmmouse device gets attached twice, one without i8042 associated
-Description of problem:
-I'm developing [a driver for the VMware mouse device](https://github.com/NattyNarwhal/vmwmouse). I know this works properly on VMware, but I'm trying it in QEMU too.
-
-[My full notes](https://github.com/NattyNarwhal/vmwmouse/issues/1), but most relevant is:
-
-* a vmmouse instance gets initialized twice (confirmed in qtree), one with i8042 the first time, one without the second time
-* the second vmmouse instance is the one receiving the events, passing them to the i8042 device's fake event handler
-* obviously, a crash because ISAKBDDevice should never be null
-Steps to reproduce:
-1. Load VMware mouse driver
-2. Move cursor (I recommend waiting until Windows loads before doing so, it is very easy to corrupt the guest filesystem if you do it while Windows is loading)
-3. Crash
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/77 b/gitlab/issues_text/target_i386/host_missing/accel_missing/77
deleted file mode 100644
index f341e297e..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/77
+++ /dev/null
@@ -1 +0,0 @@
-msmouse not recognized in guest
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/770 b/gitlab/issues_text/target_i386/host_missing/accel_missing/770
deleted file mode 100644
index 37ff5d192..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/770
+++ /dev/null
@@ -1 +0,0 @@
-READ memory access in /hw/acpi/pcihp.c
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/771 b/gitlab/issues_text/target_i386/host_missing/accel_missing/771
deleted file mode 100644
index 9a8fb2117..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/771
+++ /dev/null
@@ -1,14 +0,0 @@
-No interrupts are delivered to the guest after rebooting Windows 98
-Description of problem:
-After Windows 98 is rebooted in QEMU, the guest freezes: the system is unresponsive to key presses and the boot splash animation halts.  The guest performs fine before the reboot.
-
-Closer examination reveals that no hardware interrupts are delivered to the guest.  BIOS Data Area variables like the keyboard buffer and the system clock are not updated.  Even non-maskable interrupts fail to be delivered, as witnessed by installing an option ROM that hooks interrupt vector 2 and issuing the `nmi` command in the monitor.
-
-The only remedy seems to be to exit the QEMU process entirely and launch it again.
-Steps to reproduce:
-0. Install Windows 98 into the guest.  (Since the normal installation process already involves a couple of reboots, it is possible to hit the issue already at step zero.)
-1. Boot it; it may be into Safe Mode, but the protected-mode graphical environment must at least attempt to load.  (I managed sometimes to reproduce the bug without the system having loaded fully.)
-2. Reboot. This may be a clean reboot, or it may be a hard reboot (`system_reset` or equivalent)
-3. Observe the system freeze.
-Additional information:
-None
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/78 b/gitlab/issues_text/target_i386/host_missing/accel_missing/78
deleted file mode 100644
index 8b624dcea..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/78
+++ /dev/null
@@ -1 +0,0 @@
-msmouse serial mouse emulation broken? No id byte sent on reset
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/780 b/gitlab/issues_text/target_i386/host_missing/accel_missing/780
deleted file mode 100644
index dfbcc9a66..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/780
+++ /dev/null
@@ -1,54 +0,0 @@
-qemu-system-x86_64: qemu dead-lock when mirror job exit and vm stop in a race
-Description of problem:
-machine under continuous pressure, at the end of the migration phase.
-Libvirtd construction exception at the same time.
-In mirror_run, mirror_write_complete set s->ret to negative value and exit mirror_run; Job_co_entry throws the bh of job_exit into the main thread;
-
-While the live_migration thread gets the qemu_global_mutex, and set to main thread by blk_set_aio_context; when it just polles the bh of job_exit, and run to bdrv_flush. So there need the main thread to process bdrv_flush_co_entry, then we can exit bdrv_flush.
-If the main thread is waiting the qemu_mutex_lock_iothread_impl, bdrv_flush_co_entry cannot be executed, and the Live_migration thread cannot exit to release qemu_global_mutex, resulting in deadlock
-Steps to reproduce:
-1.migrate the machine and let machine under continuous pressure;
-2.gdb to qemu and make break point to virtio_blk_data_plane_stop;
-3.when hit virtio_blk_data_plane_stop, kill libvirtd;
-4.let live_migration thread to poll job_exit
-Additional information:
-```
-#0  0x00007f8f662d12f2 in aio_bh_poll (ctx=ctx@entry=0x5580c53a5c60) at /usr/src/qemu/util/async.c:112
-#1  0x00007f8f662d58ae in aio_poll (ctx=0x5580c53a5c60, blocking=blocking@entry=true) at /usr/src/qemu/util/aio-posix.c:736
-#2  0x00007f8f6530bcca in bdrv_flush (bs=bs@entry=0x5580c5857b30) at /usr/src/qemu/block/io.c:2778
-#3  0x00007f8f65345143 in bdrv_close (bs=bs@entry=0x5580c5857b30) at /usr/src/qemu/block.c:4073
-#4  0x00007f8f65345373 in bdrv_delete (bs=0x5580c5857b30) at /usr/src/qemu/block.c:4335
-#5  0x00007f8f65345405 in bdrv_unref (bs=<optimized out>) at /usr/src/qemu/block.c:5676
-#6  0x00007f8f65344d95 in bdrv_root_unref_child (child=<optimized out>) at /usr/src/qemu/block.c:2516
-#7  0x00007f8f65353f56 in block_job_remove_all_bdrv (job=job@entry=0x5580c6d55cc0) at /usr/src/qemu/blockjob.c:203
-#8  0x00007f8f65317b87 in mirror_exit_common (job=0x5580c6d55cc0) at /usr/src/qemu/block/mirror.c:776
-#9  0x00007f8f65317cc8 in mirror_abort (job=<optimized out>) at /usr/src/qemu/block/mirror.c:804
-#10 0x00007f8f6632737b in job_finalize_single (job=job@entry=0x5580c6d55cc0) at /usr/src/qemu/job.c:680
-#11 0x00007f8f66327d70 in job_completed_txn_abort (job=<optimized out>) at /usr/src/qemu/job.c:758
-#12 0x00007f8f66328018 in job_exit (opaque=0x5580c6d55cc0) at /usr/src/qemu/job.c:873
-#13 0x00007f8f662d130f in aio_bh_poll (ctx=ctx@entry=0x5580c53a5c60) at /usr/src/qemu/util/async.c:118
-#14 0x00007f8f662d5716 in aio_poll (ctx=ctx@entry=0x5580c53a5c60, blocking=blocking@entry=true) at /usr/src/qemu/util/aio-posix.c:736
-#15 0x00007f8f662e6b4d in aio_wait_bh_oneshot (ctx=0x5580c53a5c60, cb=<optimized out>, opaque=<optimized out>) at /usr/src/qemu/util/aio-wait.c:71
-#16 0x00007f8f65340978 in bdrv_attach_aio_context (bs=bs@entry=0x5580c5a07ef0, new_context=new_context@entry=0x5580c53a5c60) at /usr/src/qemu/block.c:5985
-#17 0x00007f8f65345fd5 in bdrv_set_aio_context_ignore (bs=0x5580c5a07ef0, new_context=new_context@entry=0x5580c53a5c60, ignore=ignore@entry=0x7f8eb8ff8c20) at /usr/src/qemu/block.c:6050
-#18 0x00007f8f6534609e in bdrv_set_aio_context_ignore (bs=0x5580c5857b30, new_context=new_context@entry=0x5580c53a5c60, ignore=ignore@entry=0x7f8eb8ff8c20) at /usr/src/qemu/block.c:6032
-#19 0x00007f8f65353bd4 in child_job_set_aio_ctx (c=<optimized out>, ctx=0x5580c53a5c60, ignore=0x7f8eb8ff8c20) at /usr/src/qemu/blockjob.c:172
-#20 0x00007f8f6534604b in bdrv_set_aio_context_ignore (bs=0x5580c53c46c0, new_context=new_context@entry=0x5580c53a5c60, ignore=ignore@entry=0x7f8eb8ff8c20) at /usr/src/qemu/block.c:6040
-#21 0x00007f8f6534609e in bdrv_set_aio_context_ignore (bs=bs@entry=0x5580c5978290, new_context=new_context@entry=0x5580c53a5c60, ignore=ignore@entry=0x7f8eb8ff8c20) at /usr/src/qemu/block.c:6032
-#22 0x00007f8f653462b8 in bdrv_child_try_set_aio_context (bs=bs@entry=0x5580c5978290, ctx=ctx@entry=0x5580c53a5c60, ignore_child=<optimized out>, errp=errp@entry=0x0) at /usr/src/qemu/block.c:6145
-#23 0x00007f8f653029aa in blk_do_set_aio_context (blk=0x5580c53c42b0, new_context=0x5580c53a5c60, update_root_node=update_root_node@entry=true, errp=errp@entry=0x0) at /usr/src/qemu/block/block-backend.c:1948
-#24 0x00007f8f65304b0d in blk_set_aio_context (blk=<optimized out>, new_context=<optimized out>, errp=errp@entry=0x0) at /usr/src/qemu/block/block-backend.c:1980
-#25 0x00007f8f64f07976 in virtio_blk_data_plane_stop (vdev=0x5580c6d8a510) at /usr/src/qemu/hw/block/dataplane/virtio-blk.c:305
-#26 0x00007f8f64f7be83 in virtio_bus_stop_ioeventfd (bus=0x5580c6d8a498) at /usr/src/qemu/hw/virtio/virtio-bus.c:247
-#27 0x00007f8f64f77e8b in virtio_vmstate_change (opaque=0x5580c6d8a510, running=0, state=RUN_STATE_FINISH_MIGRATE) at /usr/src/qemu/hw/virtio/virtio.c:2423
-#28 0x00007f8f663563f5 in vm_state_notify (running=running@entry=0, state=state@entry=RUN_STATE_FINISH_MIGRATE) at /usr/src/qemu/huawei/microvm/microvm-platform.c:196
-#29 0x00007f8f66335af9 in do_vm_stop (state=RUN_STATE_FINISH_MIGRATE, send_stop=send_stop@entry=true) at /usr/src/qemu/cpus.c:1130
-#30 0x00007f8f66335dd1 in vm_stop (state=<optimized out>) at /usr/src/qemu/cpus.c:2207
-#31 0x00007f8f66335f7e in vm_stop_force_state (state=state@entry=RUN_STATE_FINISH_MIGRATE) at /usr/src/qemu/cpus.c:2267
-#32 0x00007f8f65197cfc in migration_try_vm_stop_and_save_concurrent (s=s@entry=0x5580c609a010) at /usr/src/qemu/migration/migration.c:2976
-#33 0x00007f8f6519c627 in migration_completion (s=s@entry=0x5580c609a010) at /usr/src/qemu/migration/migration.c:3039
-#34 0x00007f8f6519cc8b in migration_iteration_run (s=s@entry=0x5580c609a010) at /usr/src/qemu/migration/migration.c:3571
-#35 0x00007f8f6519d190 in migration_thread (opaque=0x5580c609a010) at /usr/src/qemu/migration/migration.c:3801
-#36 0x00007f8f662d82e0 in qemu_thread_start (args=0x5580c57d0300) at /usr/src/qemu/util/qemu-thread-posix.c:519
-#37 0x00007f8f6648bf3b in start_thread (arg=0x7f8eb8ff9700) at pthread_create.c:486
-```
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/786 b/gitlab/issues_text/target_i386/host_missing/accel_missing/786
deleted file mode 100644
index f20ed6fd0..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/786
+++ /dev/null
@@ -1,17 +0,0 @@
-assert in qemu-6.2.0/hw/acpi/aml-build.c:61:build_append_padded_str: assertion failed: (len <= maxlen)
-Description of problem:
-assert and crash when -acpitable argument is used. Specifically, the argument was "-acpitable file=my_file.bin" which causes the assert and crash. 
-
-The other arguments, I hope, are not critical. In brief, I'm using secure boot (with ovmf_code.secboot.fd), and a sw tpm as well. But hopefully these are not relevant.
-
-The assert with -acpitable is a regression since it worked with version 6.1.0
-
-The actual error message in qemu 6.2.0 is
-
-qemu-6.2.0/hw/acpi/aml-build.c:61:build_append_padded_str: assertion failed: (len <= maxlen)
-Steps to reproduce:
-1.
-2.
-3.
-Additional information:
-
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/791 b/gitlab/issues_text/target_i386/host_missing/accel_missing/791
deleted file mode 100644
index 8630f010c..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/791
+++ /dev/null
@@ -1 +0,0 @@
-unable to execute QEMU command - SGX VM using libvirtd
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/810 b/gitlab/issues_text/target_i386/host_missing/accel_missing/810
deleted file mode 100644
index 12bb57b34..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/810
+++ /dev/null
@@ -1,71 +0,0 @@
-i386/sev: Crash in pc_system_parse_ovmf_flash caused by bad firmware file
-Description of problem:
-A specially-crafted flash file can cause the `memcpy()` call in
-`pc_system_parse_ovmf_flash` (`hw/i386/pc_sysfw_ovmf.c`) to READ out-of-bounds
-memory, because there's no check on the `tot_len` field which is read
-from the flash file.  In such case, `ptr - tot_len` will point to a
-memory location *below* `flash_ptr` (hence the out-of-bounds read).
-
-This path is only taken when SEV is enabled (which requires 
-KVM and x86_64).
-Steps to reproduce:
-1. Create `bad_ovmf.fd` using the following python script:
-   ```
-   from uuid import UUID
-   OVMF_TABLE_FOOTER_GUID = "96b582de-1fb2-45f7-baea-a366c55a082d"
-   b = bytearray(4096)
-   b[4046:4048] = b'\xff\xff'   # tot_len field
-   b[4048:4064] = UUID("{" + OVMF_TABLE_FOOTER_GUID + "}").bytes_le
-   with open("bad_ovmf.fd", "wb") as f:
-       f.write(b)
-   ```
-2. Build QEMU with `--enable-sanitizers`
-3. Start QEMU with SEV and the bad flash file:
-   ```
-   qemu-system-x86_64 -enable-kvm -cpu host -machine q35 \
-                      -drive if=pflash,format=raw,unit=0,file=bad_ovmf.fd,readonly=on \
-                      -machine confidential-guest-support=sev0 \
-                      -object sev-guest,id=sev0,cbitpos=47,reduced-phys-bits=1,policy=0x0
-   ```
-4. QEMU crashes with: `SUMMARY: AddressSanitizer: stack-buffer-underflow`
-Additional information:
-Crash example:
-
-```
-$ sudo build/qemu-system-x86_64 -enable-kvm -cpu host -machine q35 \
-                                -drive if=pflash,format=raw,unit=0,file=bad_ovmf.fd,readonly=on \
-                                -machine confidential-guest-support=sev0 \
-                                -object sev-guest,id=sev0,cbitpos=47,reduced-phys-bits=1,policy=0x0
-==523314==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
-=================================================================
-==523314==ERROR: AddressSanitizer: stack-buffer-underflow on address 0x7f05305fb180 at pc 0x7f0548d89480 bp 0x7ffed44a1980 sp 0x7ffed44a1128
-READ of size 65517 at 0x7f05305fb180 thread T0
-    #0 0x7f0548d8947f  (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x9b47f)
-    #1 0x556127c3331e in memcpy /usr/include/x86_64-linux-gnu/bits/string_fortified.h:34
-    #2 0x556127c3331e in pc_system_parse_ovmf_flash ../hw/i386/pc_sysfw_ovmf.c:82
-    #3 0x556127c21a0c in pc_system_flash_map ../hw/i386/pc_sysfw.c:203
-    #4 0x556127c21a0c in pc_system_firmware_init ../hw/i386/pc_sysfw.c:258
-    #5 0x556127c1ddd9 in pc_memory_init ../hw/i386/pc.c:902
-    #6 0x556127bdc387 in pc_q35_init ../hw/i386/pc_q35.c:207
-    #7 0x5561273bfdd6 in machine_run_board_init ../hw/core/machine.c:1181
-    #8 0x556127f77de1 in qemu_init_board ../softmmu/vl.c:2652
-    #9 0x556127f77de1 in qmp_x_exit_preconfig ../softmmu/vl.c:2740
-    #10 0x556127f7f24d in qemu_init ../softmmu/vl.c:3775
-    #11 0x556126f947ac in main ../softmmu/main.c:49
-    #12 0x7f05470e80b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
-    #13 0x556126fa639d in _start (/home/dmurik/git/qemu/build/qemu-system-x86_64+0x2a5739d)
-
-Address 0x7f05305fb180 is located in stack of thread T3 at offset 0 in frame
-    #0 0x556128a96f1f in qemu_sem_timedwait ../util/qemu-thread-posix.c:293
-
-
-  This frame has 1 object(s):
-    [32, 48) 'ts' (line 295) <== Memory access at offset 0 partially underflows this variable
-HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork
-      (longjmp and C++ exceptions *are* supported)
-Thread T3 created by T0 here:
-    #0 0x7f0548d28805 in pthread_create (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x3a805)
-    #1 0x556128a97ecf in qemu_thread_create ../util/qemu-thread-posix.c:596
-
-SUMMARY: AddressSanitizer: stack-buffer-underflow (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x9b47f)
-```
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/837 b/gitlab/issues_text/target_i386/host_missing/accel_missing/837
deleted file mode 100644
index b24126957..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/837
+++ /dev/null
@@ -1,30 +0,0 @@
-x86 user: icebp/int1 raises wrong signal
-Description of problem:
-This is a relatively minor inaccuracy. When `icebp` (`F1`) is executed, it raises `SIGILL` in QEMU, where the behavior on baremetal Linux (on an old Intel Core i5-430m) is to raise `SIGTRAP`.
-
-Specifically, on the architectural level, `icebp` raises `#DB` without affecting `dr6`.
-
-This also happens on an AArch64 host.
-```
-$ ./icebp
-Trace/breakpoint trap
-$ qemu-x86_64 ./icebp
-qemu: uncaught target signal 4 (Illegal instruction) - core dumped
-Illegal instruction
-```
-Steps to reproduce:
-1. Compile this file using `gcc -nostdlib -static icebp.S -o icebp`, optionally with `-m32` to test i386
-```
-    .globl _start
-_start:
-    .byte  0xF1 // gas doesn't assemble this instruction opcode but it disassembles it
-#ifdef __x86_64__
-    mov    $60, %eax
-    syscall
-#else
-    mov    $1, %eax
-    int    $0x80
-#endif 
-```
-2. Run on baremetal. Notice how it raises `SIGTRAP` according to the shell job control message
-3. Run on qemu-user. Notice how it raises `SIGILL`.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/855 b/gitlab/issues_text/target_i386/host_missing/accel_missing/855
deleted file mode 100644
index 27b5bbfd4..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/855
+++ /dev/null
@@ -1,17 +0,0 @@
-Prebuilt seabios vgabios-stdvga binary causes onboot kernel panics for freebsd 10.0
-Description of problem:
-FreeBSD 10.0 panics on boot since commit: `0221d73ce6a8e075adaa0a35a6ef853d2652b855`, see my attached screenshot of the panic. 
-I digged a bit into what specifically causes the issue, it seems to be caused by the precompiled `vgabios-stdvga.bin`. 
-I don't see this issue come up when I compile the binary myself via the `roms/` folder with different versions of gcc via gcc docker containers. 
-But once I compile the `vgabios-stdvga` from the `roms/` folder with a more modern Ubuntu version (21.10) using gcc 11.2, I also get panics on my `vgabios-stdvga`. 
-At first I thought it was caused by a different gcc version, but since the buster gcc docker container images create correctly functioning `vgabios-stdvga.bin` binaries, I think this is caused by a newer version of the linker coming from the `binutils` package.
-
-My local Ubuntu version has version 2.37 of the binutils package, the `gcc:11.2` container which compiles a correct `vgabios-stdvga.bin` has version `2.35.2` of the binutils package.
-
-![Screenshot_from_2022-02-03_17-35-59](/uploads/5bafeca625ebe8b38acd5a0d6c358392/Screenshot_from_2022-02-03_17-35-59.png)
-Steps to reproduce:
-1. Compile any version after the mentioned commit using the precompiled seabios binaries
-2. Try to boot freebsd 10.0-RELEASE
-3. Kernel panic because of a page vault during the vesa module load.
-Additional information:
-https://mfsbsd.vx.sk/files/iso/10/amd64/mfsbsd-10.0-RELEASE-amd64.iso
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/871 b/gitlab/issues_text/target_i386/host_missing/accel_missing/871
deleted file mode 100644
index 1b81a90ee..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/871
+++ /dev/null
@@ -1,14 +0,0 @@
-qemu-x86_64 don't support unshare(CLONE_NEWUSER)
-Description of problem:
-Why qemu-x86_64 call unshare(CLONE_NEWUSER) fail?
-```
-    fuzzing@ubuntu:~/Desktop/afl/AFLplusplus$ qemu-x86_64 /bin/unshare --user /bin/bash
-    unshare: unshare failed: Invalid argument
-    fuzzing@ubuntu:~/Desktop/afl/AFLplusplus$ /bin/unshare --user /bin/bash
-    nobody@ubuntu:~/Desktop/afl/AFLplusplus$
-```
-Steps to reproduce:
-1.execute `qemu-x86_64 /bin/unshare --user /bin/bash` ,it will fail <br/>
-2.execute `/bin/unshare --user /bin/bash` ,it will ok
-
-How i fix that?
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/877 b/gitlab/issues_text/target_i386/host_missing/accel_missing/877
deleted file mode 100644
index 9699197df..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/877
+++ /dev/null
@@ -1,106 +0,0 @@
-qemu-system-x86_64: Linux kernel warning when CONFIG_NUMA_EMU is enabled
-Description of problem:
-When Linux kernel is run on qemu 6.2, it prints a warning when `NUMA_EMU` is used. When the same kernel is run on qemu 6.1.1 (`54e1f5be86dd11744e45da8be6afad01d01d59e7`) or earlier, no such warning is printed.
-
-```
-[    0.341924] smpboot: CPU0: Intel QEMU Virtual CPU version 2.5+ (family: 0xf, model: 0x6b, stepping: 0x1)
-[    0.342371] Performance Events: unsupported Netburst CPU model 107 no PMU driver, software events only.
-[    0.343302] rcu: Hierarchical SRCU implementation.
-[    0.344470] smp: Bringing up secondary CPUs ...
-[    0.345349] x86: Booting SMP configuration:
-[    0.345945] .... node  #1, CPUs:      #1
-[    0.014099] ------------[ cut here ]------------
-[    0.014099] sched: CPU #1's llc-sibling CPU #0 is not on the same node! [node: 1 != 0]. Ignoring dependency.
-[    0.014099] WARNING: CPU: 1 PID: 0 at arch/x86/kernel/smpboot.c:423 topology_sane.isra.0+0x62/0x70
-[    0.014099] Modules linked in:
-[    0.014099] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.16.9 #6
-[    0.014099] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014
-[    0.014099] RIP: 0010:topology_sane.isra.0+0x62/0x70
-[    0.014099] Code: 80 3d e1 72 a1 01 00 75 f6 48 83 ec 08 4c 89 da 44 89 d6 48 c7 c7 c0 cd f4 8b 88 44 24 07 c6 05 c3 72 a1 01 01 e8 3c 16 b7 00 <0f> 0b 0f b6 44 24 07 48 83 c4 08 c3 66 90 48 8b 0d 21 95 a3 01 0f
-[    0.014099] RSP: 0000:ffffa8c3006a3ed8 EFLAGS: 00010086
-[    0.014099] RAX: 0000000000000000 RBX: ffffa335fdc15480 RCX: 0000000000000000
-[    0.014099] RDX: 0000000000000002 RSI: 00000000ffffffea RDI: 00000000ffffffff
-[    0.014099] RBP: ffffa3353dc15480 R08: ffffffff8c335ac8 R09: 00000000ffffdfff
-[    0.014099] R10: ffffffff8c255ae0 R11: ffffffff8c255ae0 R12: 0000000000000001
-[    0.014099] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000001
-[    0.014099] FS:  0000000000000000(0000) GS:ffffa335fdc00000(0000) knlGS:0000000000000000
-[    0.014099] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
-[    0.014099] CR2: 0000000000000000 CR3: 0000000112a0c000 CR4: 00000000000006e0
-[    0.014099] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
-[    0.014099] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
-[    0.014099] Call Trace:
-[    0.014099]  <TASK>
-[    0.014099]  set_cpu_sibling_map+0x16a/0x560
-[    0.014099]  start_secondary+0x42/0xf0
-[    0.014099]  secondary_startup_64_no_verify+0xc2/0xcb
-[    0.014099]  </TASK>
-[    0.014099] Kernel panic - not syncing: panic_on_warn set ...
-[    0.014099] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.16.9 #6
-[    0.014099] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014
-[    0.014099] Call Trace:
-[    0.014099]  <TASK>
-[    0.014099]  dump_stack_lvl+0x34/0x44
-[    0.014099]  panic+0xef/0x2a6
-[    0.014099]  ? topology_sane.isra.0+0x62/0x70
-[    0.014099]  __warn.cold+0x26/0x30
-[    0.014099]  ? topology_sane.isra.0+0x62/0x70
-[    0.014099]  report_bug+0x9a/0xc0
-[    0.014099]  handle_bug+0x3c/0x60
-[    0.014099]  exc_invalid_op+0x14/0x70
-[    0.014099]  asm_exc_invalid_op+0x12/0x20
-[    0.014099] RIP: 0010:topology_sane.isra.0+0x62/0x70
-[    0.014099] Code: 80 3d e1 72 a1 01 00 75 f6 48 83 ec 08 4c 89 da 44 89 d6 48 c7 c7 c0 cd f4 8b 88 44 24 07 c6 05 c3 72 a1 01 01 e8 3c 16 b7 00 <0f> 0b 0f b6 44 24 07 48 83 c4 08 c3 66 90 48 8b 0d 21 95 a3 01 0f
-[    0.014099] RSP: 0000:ffffa8c3006a3ed8 EFLAGS: 00010086
-[    0.014099] RAX: 0000000000000000 RBX: ffffa335fdc15480 RCX: 0000000000000000
-[    0.014099] RDX: 0000000000000002 RSI: 00000000ffffffea RDI: 00000000ffffffff
-[    0.014099] RBP: ffffa3353dc15480 R08: ffffffff8c335ac8 R09: 00000000ffffdfff
-[    0.014099] R10: ffffffff8c255ae0 R11: ffffffff8c255ae0 R12: 0000000000000001
-[    0.014099] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000001
-[    0.014099]  ? topology_sane.isra.0+0x62/0x70
-[    0.014099]  set_cpu_sibling_map+0x16a/0x560
-[    0.014099]  start_secondary+0x42/0xf0
-[    0.014099]  secondary_startup_64_no_verify+0xc2/0xcb
-[    0.014099]  </TASK>
-[    0.014099] ---[ end Kernel panic - not syncing: panic_on_warn set ... ]---
-```
-Steps to reproduce:
-1. Check out the Linux kernel:
-```
-git clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
-cd linux-stable
-git checkout v5.16.9
-```
-2. Generate the configuration file:
-```
-make defconfig
-./scripts/config -e NUMA_EMU -e CMDLINE_BOOL --set-str CMDLINE "numa=fake=2 panic_on_warn=1" -d CONFIG_CMDLINE_OVERRIDE
-```
-3. Build the kernel
-```
-make -j32
-```
-4. Run qemu and wait for a couple of seconds:
-```
-./qemu-system-x86_64 -m 4G -smp 2 -kernel ~/linux-stable/arch/x86/boot/bzImage -append "console=ttyS0 root=/dev/sda earlyprintk=serial" -enable-kvm -nographic -snapshot
-```
-Additional information:
-With explicit NUMA configuration, it boots fine:
-```
-./qemu-system-x86_64 -m 4G -smp 2 -object memory-backend-ram,size=8G,id=m0 -numa node,cpus=0-1,nodeid=0,memdev=m0 -kernel ~/linux-stable/arch/x86/boot/bzImage -append "console=ttyS0 root=/dev/sda earlyprintk=serial" -enable-kvm -nographic -snapshot
-```
-
-On the host machine:
-```
-$ numactl -H
-available: 2 nodes (0-1)
-node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53
-node 0 size: 95259 MB
-node 0 free: 1767 MB
-node 1 cpus: 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71
-node 1 size: 96757 MB
-node 1 free: 2407 MB
-node distances:
-node   0   1 
-  0:  10  21 
-  1:  21  10 
-```
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/91 b/gitlab/issues_text/target_i386/host_missing/accel_missing/91
deleted file mode 100644
index 5ed4aefed..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/91
+++ /dev/null
@@ -1 +0,0 @@
-RFE: Implement support for SMBIOS Type 41 structures
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/921 b/gitlab/issues_text/target_i386/host_missing/accel_missing/921
deleted file mode 100644
index 60636e047..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/921
+++ /dev/null
@@ -1,623 +0,0 @@
-qemu 7.0-rc0 warning: cannot get sys attribute capabilities 0
-Description of problem:
-The guest fp not working properly
-Steps to reproduce:
-1. Start the docker
-```
-docker run -it --name qemu --rm \
-    --privileged \
-    --ipc=host \
-    -v /dev/log:/dev/log \
-    -v /dev/vhost-net:/dev/vhost-net \
-    -v /sys/kernel/debug:/sys/kernel/debug \
-    -v $ROOT:$ROOT \
-    -p 2222:22 \
-    -p 1234:1234 \
-    -p 1235:1235 \
-    -e ROOT=$ROOT \
-    -e XDG_RUNTIME_DIR=/tmp \
-    -e WAYLAND_DISPLAY=$WAYLAND_DISPLAY \
-    -v $XDG_RUNTIME_DIR/$WAYLAND_DISPLAY:/tmp/$WAYLAND_DISPLAY \
-    qemu
-```
-2.This is in the docker
-```
-+ build/docker/qemu-system-x86_64 -enable-kvm -M q35 -smp 1 -m 4G -cpu host -net nic,model=virtio -net user,hostfwd=tcp::22-:22,hostfwd=tcp::1234-:1234 -hda /data/xemu-opengl/image/ubuntu.qcow2 -initrd /data/xemu-opengl/image/rootfs.cpio.gz -kernel /data/xemu-opengl/kernel/arch/x86_64/boot/bzImage -append 'root=/dev/sda3 nokaslr' -usb -device usb-tablet -object memory-backend-memfd,id=mem1,size=4G -machine memory-backend=mem1 -device virtio-vga-gl,context_init=true,blob=true,hostmem=1G -vga none -display sdl,gl=on,show-cursor=on -d guest_errors
-qemu-system-x86_64: warning: cannot get sys attribute capabilities 0
-qemu-system-x86_64: warning: cannot get sys attribute capabilities 0
-qemu-system-x86_64: warning: cannot get sys attribute capabilities 0
-qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.0DH:EAX [bit 1]
-qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.0DH:EAX [bit 2]
-qemu-system-x86_64: warning: cannot get sys attribute capabilities 0
-```
-
-3. In geust
-```
-dmesg
-[    0.000000] Linux version 5.16.14 (root@5bc45822eca9) (gcc (Ubuntu 11.2.0-7ubuntu2) 11.2.0, GNU ld (GNU Binutils for Ubuntu) 2.37) #3 SMP PREEMPT Sun Mar 13 23:24:16 UTC 2022
-[    0.000000] Command line: root=/dev/sda3 nokaslr
-[    0.000000] x86/fpu: FP/SSE not present amongst the CPU's xstate features: 0x1.
-[    0.000000] signal: max sigframe size: 1440
-[    0.000000] BIOS-provided physical RAM map:
-[    0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009fbff] usable
-[    0.000000] BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff] reserved
-[    0.000000] BIOS-e820: [mem 0x00000000000f0000-0x00000000000fffff] reserved
-[    0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000007ffddfff] usable
-[    0.000000] BIOS-e820: [mem 0x000000007ffde000-0x000000007fffffff] reserved
-[    0.000000] BIOS-e820: [mem 0x00000000b0000000-0x00000000bfffffff] reserved
-[    0.000000] BIOS-e820: [mem 0x00000000fed1c000-0x00000000fed1ffff] reserved
-[    0.000000] BIOS-e820: [mem 0x00000000feffc000-0x00000000feffffff] reserved
-[    0.000000] BIOS-e820: [mem 0x00000000fffc0000-0x00000000ffffffff] reserved
-[    0.000000] BIOS-e820: [mem 0x0000000100000000-0x000000017fffffff] usable
-[    0.000000] NX (Execute Disable) protection: active
-[    0.000000] SMBIOS 2.8 present.
-[    0.000000] DMI: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
-[    0.000000] e820: update [mem 0x00000000-0x00000fff] usable ==> reserved
-[    0.000000] e820: remove [mem 0x000a0000-0x000fffff] usable
-[    0.000000] last_pfn = 0x180000 max_arch_pfn = 0x400000000
-[    0.000000] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WP  UC- WT  
-[    0.000000] last_pfn = 0x7ffde max_arch_pfn = 0x400000000
-[    0.000000] found SMP MP-table at [mem 0x000f5b70-0x000f5b7f]
-[    0.000000] Using GB pages for direct mapping
-[    0.000000] RAMDISK: [mem 0x7ffcf000-0x7ffcffff]
-[    0.000000] ACPI: Early table checksum verification disabled
-[    0.000000] ACPI: RSDP 0x00000000000F5980 000014 (v00 BOCHS )
-[    0.000000] ACPI: RSDT 0x000000007FFE22CB 000038 (v01 BOCHS  BXPC     00000001 BXPC 00000001)
-[    0.000000] ACPI: FACP 0x000000007FFE20C3 0000F4 (v03 BOCHS  BXPC     00000001 BXPC 00000001)
-[    0.000000] ACPI: DSDT 0x000000007FFE0040 002083 (v01 BOCHS  BXPC     00000001 BXPC 00000001)
-[    0.000000] ACPI: FACS 0x000000007FFE0000 000040
-[    0.000000] ACPI: APIC 0x000000007FFE21B7 000078 (v01 BOCHS  BXPC     00000001 BXPC 00000001)
-[    0.000000] ACPI: HPET 0x000000007FFE222F 000038 (v01 BOCHS  BXPC     00000001 BXPC 00000001)
-[    0.000000] ACPI: MCFG 0x000000007FFE2267 00003C (v01 BOCHS  BXPC     00000001 BXPC 00000001)
-[    0.000000] ACPI: WAET 0x000000007FFE22A3 000028 (v01 BOCHS  BXPC     00000001 BXPC 00000001)
-[    0.000000] ACPI: Reserving FACP table memory at [mem 0x7ffe20c3-0x7ffe21b6]
-[    0.000000] ACPI: Reserving DSDT table memory at [mem 0x7ffe0040-0x7ffe20c2]
-[    0.000000] ACPI: Reserving FACS table memory at [mem 0x7ffe0000-0x7ffe003f]
-[    0.000000] ACPI: Reserving APIC table memory at [mem 0x7ffe21b7-0x7ffe222e]
-[    0.000000] ACPI: Reserving HPET table memory at [mem 0x7ffe222f-0x7ffe2266]
-[    0.000000] ACPI: Reserving MCFG table memory at [mem 0x7ffe2267-0x7ffe22a2]
-[    0.000000] ACPI: Reserving WAET table memory at [mem 0x7ffe22a3-0x7ffe22ca]
-[    0.000000] No NUMA configuration found
-[    0.000000] Faking a node at [mem 0x0000000000000000-0x000000017fffffff]
-[    0.000000] NODE_DATA(0) allocated [mem 0x17fffa000-0x17fffdfff]
-[    0.000000] Zone ranges:
-[    0.000000]   DMA      [mem 0x0000000000001000-0x0000000000ffffff]
-[    0.000000]   DMA32    [mem 0x0000000001000000-0x00000000ffffffff]
-[    0.000000]   Normal   [mem 0x0000000100000000-0x000000017fffffff]
-[    0.000000] Movable zone start for each node
-[    0.000000] Early memory node ranges
-[    0.000000]   node   0: [mem 0x0000000000001000-0x000000000009efff]
-[    0.000000]   node   0: [mem 0x0000000000100000-0x000000007ffddfff]
-[    0.000000]   node   0: [mem 0x0000000100000000-0x000000017fffffff]
-[    0.000000] Initmem setup node 0 [mem 0x0000000000001000-0x000000017fffffff]
-[    0.000000] On node 0, zone DMA: 1 pages in unavailable ranges
-[    0.000000] On node 0, zone DMA: 97 pages in unavailable ranges
-[    0.000000] On node 0, zone Normal: 34 pages in unavailable ranges
-[    0.000000] ACPI: PM-Timer IO Port: 0x608
-[    0.000000] ACPI: LAPIC_NMI (acpi_id[0xff] dfl dfl lint[0x1])
-[    0.000000] IOAPIC[0]: apic_id 0, version 17, address 0xfec00000, GSI 0-23
-[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
-[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 5 global_irq 5 high level)
-[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
-[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 10 global_irq 10 high level)
-[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 11 global_irq 11 high level)
-[    0.000000] ACPI: Using ACPI (MADT) for SMP configuration information
-[    0.000000] ACPI: HPET id: 0x8086a201 base: 0xfed00000
-[    0.000000] TSC deadline timer available
-[    0.000000] smpboot: Allowing 1 CPUs, 0 hotplug CPUs
-[    0.000000] PM: hibernation: Registered nosave memory: [mem 0x00000000-0x00000fff]
-[    0.000000] PM: hibernation: Registered nosave memory: [mem 0x0009f000-0x0009ffff]
-[    0.000000] PM: hibernation: Registered nosave memory: [mem 0x000a0000-0x000effff]
-[    0.000000] PM: hibernation: Registered nosave memory: [mem 0x000f0000-0x000fffff]
-[    0.000000] PM: hibernation: Registered nosave memory: [mem 0x7ffde000-0x7fffffff]
-[    0.000000] PM: hibernation: Registered nosave memory: [mem 0x80000000-0xafffffff]
-[    0.000000] PM: hibernation: Registered nosave memory: [mem 0xb0000000-0xbfffffff]
-[    0.000000] PM: hibernation: Registered nosave memory: [mem 0xc0000000-0xfed1bfff]
-[    0.000000] PM: hibernation: Registered nosave memory: [mem 0xfed1c000-0xfed1ffff]
-[    0.000000] PM: hibernation: Registered nosave memory: [mem 0xfed20000-0xfeffbfff]
-[    0.000000] PM: hibernation: Registered nosave memory: [mem 0xfeffc000-0xfeffffff]
-[    0.000000] PM: hibernation: Registered nosave memory: [mem 0xff000000-0xfffbffff]
-[    0.000000] PM: hibernation: Registered nosave memory: [mem 0xfffc0000-0xffffffff]
-[    0.000000] [mem 0xc0000000-0xfed1bfff] available for PCI devices
-[    0.000000] clocksource: refined-jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1910969940391419 ns
-[    0.000000] setup_percpu: NR_CPUS:64 nr_cpumask_bits:64 nr_cpu_ids:1 nr_node_ids:1
-[    0.000000] percpu: Embedded 52 pages/cpu s174744 r8192 d30056 u2097152
-[    0.000000] pcpu-alloc: s174744 r8192 d30056 u2097152 alloc=1*2097152
-[    0.000000] pcpu-alloc: [0] 0 
-[    0.000000] Fallback order for Node 0: 0 
-[    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 1031902
-[    0.000000] Policy zone: Normal
-[    0.000000] Kernel command line: root=/dev/sda3 nokaslr
-[    0.000000] Unknown kernel command line parameters "nokaslr", will be passed to user space.
-[    0.000000] Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes, linear)
-[    0.000000] Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes, linear)
-[    0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off
-[    0.000000] Memory: 4019736K/4193776K available (16398K kernel code, 2621K rwdata, 5052K rodata, 1252K init, 1332K bss, 173784K reserved, 0K cma-reserved)
-[    0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
-[    0.000000] Dynamic Preempt: full
-[    0.000000] rcu: Preemptible hierarchical RCU implementation.
-[    0.000000] rcu:     RCU event tracing is enabled.
-[    0.000000] rcu:     RCU restricting CPUs from NR_CPUS=64 to nr_cpu_ids=1.
-[    0.000000]  Trampoline variant of Tasks RCU enabled.
-[    0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 100 jiffies.
-[    0.000000] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=1
-[    0.000000] NR_IRQS: 4352, nr_irqs: 256, preallocated irqs: 16
-[    0.000000] random: get_random_bytes called from start_kernel+0x492/0x65f with crng_init=0
-[    0.000000] Console: colour VGA+ 80x25
-[    0.000000] printk: console [tty0] enabled
-[    0.000000] ACPI: Core revision 20210930
-[    0.000000] clocksource: hpet: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604467 ns
-[    0.001000] APIC: Switch to symmetric I/O mode setup
-[    0.002000] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
-[    0.010000] tsc: Unable to calibrate against PIT
-[    0.011000] tsc: using HPET reference calibration
-[    0.012000] tsc: Detected 3699.687 MHz processor
-[    0.000260] clocksource: tsc-early: mask: 0xffffffffffffffff max_cycles: 0x6aa85c29371, max_idle_ns: 881590506582 ns
-[    0.001636] Calibrating delay loop (skipped), value calculated using timer frequency.. 7399.37 BogoMIPS (lpj=3699687)
-[    0.002617] pid_max: default: 32768 minimum: 301
-[    0.003888] LSM: Security Framework initializing
-[    0.004744] SELinux:  Initializing.
-[    0.006672] Mount-cache hash table entries: 8192 (order: 4, 65536 bytes, linear)
-[    0.007869] Mountpoint-cache hash table entries: 8192 (order: 4, 65536 bytes, linear)
-[    0.014682] x86/cpu: User Mode Instruction Prevention (UMIP) activated
-[    0.016974] Last level iTLB entries: 4KB 512, 2MB 255, 4MB 127
-[    0.017603] Last level dTLB entries: 4KB 512, 2MB 255, 4MB 127, 1GB 0
-[    0.018602] Spectre V1 : Mitigation: usercopy/swapgs barriers and __user pointer sanitization
-[    0.018623] Spectre V2 : Mitigation: Retpolines
-[    0.019603] Spectre V2 : Spectre v2 / SpectreRSB mitigation: Filling RSB on context switch
-[    0.020637] Spectre V2 : mitigation: Enabling conditional Indirect Branch Prediction Barrier
-[    0.021603] Speculative Store Bypass: Mitigation: Speculative Store Bypass disabled via prctl
-[    0.083192] Freeing SMP alternatives memory: 44K
-[    0.086287] smpboot: CPU0: AMD Ryzen Threadripper 3970X 32-Core Processor (family: 0x17, model: 0x31, stepping: 0x0)
-[    0.088185] Performance Events: Fam17h+ core perfctr, AMD PMU driver.
-[    0.088635] ... version:                0
-[    0.089365] ... bit width:              48
-[    0.089610] ... generic registers:      6
-[    0.090332] ... value mask:             0000ffffffffffff
-[    0.090611] ... max period:             00007fffffffffff
-[    0.091424] ... fixed-purpose events:   0
-[    0.091614] ... event mask:             000000000000003f
-[    0.092889] rcu: Hierarchical SRCU implementation.
-[    0.095245] smp: Bringing up secondary CPUs ...
-[    0.095612] smp: Brought up 1 node, 1 CPU
-[    0.096340] smpboot: Max logical packages: 1
-[    0.096609] smpboot: Total of 1 processors activated (7399.37 BogoMIPS)
-[    0.169912] devtmpfs: initialized
-[    0.175284] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1911260446275000 ns
-[    0.175676] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
-[    0.177611] PM: RTC time: 10:29:46, date: 2022-03-20
-[    0.183040] NET: Registered PF_NETLINK/PF_ROUTE protocol family
-[    0.187536] audit: initializing netlink subsys (disabled)
-[    0.191857] thermal_sys: Registered thermal governor 'step_wise'
-[    0.191877] thermal_sys: Registered thermal governor 'user_space'
-[    0.192675] audit: type=2000 audit(1647772186.201:1): state=initialized audit_enabled=0 res=1
-[    0.194185] cpuidle: using governor menu
-[    0.198008] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xb0000000-0xbfffffff] (base 0xb0000000)
-[    0.198662] PCI: MMCONFIG at [mem 0xb0000000-0xbfffffff] reserved in E820
-[    0.200081] PCI: Using configuration type 1 for base access
-[    0.204517] kprobes: kprobe jump-optimization is enabled. All kprobes are optimized if possible.
-[    0.205408] HugeTLB registered 2.00 MiB page size, pre-allocated 0 pages
-[    0.206698] ACPI: Added _OSI(Module Device)
-[    0.207453] ACPI: Added _OSI(Processor Device)
-[    0.207610] ACPI: Added _OSI(3.0 _SCP Extensions)
-[    0.208402] ACPI: Added _OSI(Processor Aggregator Device)
-[    0.208611] ACPI: Added _OSI(Linux-Dell-Video)
-[    0.209375] ACPI: Added _OSI(Linux-Lenovo-NV-HDMI-Audio)
-[    0.209614] ACPI: Added _OSI(Linux-HPI-Hybrid-Graphics)
-[    0.212597] ACPI: 1 ACPI AML tables successfully acquired and loaded
-[    0.215363] ACPI: Interpreter enabled
-[    0.215779] ACPI: PM: (supports S0 S3 S4 S5)
-[    0.216543] ACPI: Using IOAPIC for interrupt routing
-[    0.216649] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
-[    0.217739] ACPI: Enabled 2 GPEs in block 00 to 3F
-[    0.221429] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
-[    0.221679] acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI HPX-Type3]
-[    0.222638] acpi PNP0A08:00: _OSC: platform does not support [LTR]
-[    0.223563] acpi PNP0A08:00: _OSC: OS now controls [PME PCIeCapability]
-[    0.223907] PCI host bridge to bus 0000:00
-[    0.224612] pci_bus 0000:00: root bus resource [io  0x0000-0x0cf7 window]
-[    0.225562] pci_bus 0000:00: root bus resource [io  0x0d00-0xffff window]
-[    0.225610] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff window]
-[    0.226616] pci_bus 0000:00: root bus resource [mem 0x80000000-0xafffffff window]
-[    0.227610] pci_bus 0000:00: root bus resource [mem 0xc0000000-0xfebfffff window]
-[    0.228611] pci_bus 0000:00: root bus resource [mem 0x180000000-0x97fffffff window]
-[    0.229611] pci_bus 0000:00: root bus resource [bus 00-ff]
-[    0.230749] pci 0000:00:00.0: [8086:29c0] type 00 class 0x060000
-[    0.233477] pci 0000:00:01.0: [1af4:1000] type 00 class 0x020000
-[    0.234636] pci 0000:00:01.0: reg 0x10: [io  0xc040-0xc05f]
-[    0.236087] pci 0000:00:01.0: reg 0x14: [mem 0xfebd0000-0xfebd0fff]
-[    0.239084] pci 0000:00:01.0: reg 0x20: [mem 0x1c0000000-0x1c0003fff 64bit pref]
-[    0.240327] pci 0000:00:01.0: reg 0x30: [mem 0xfeb80000-0xfebbffff pref]
-[    0.242540] pci 0000:00:02.0: [1af4:1050] type 00 class 0x030000
-[    0.245344] pci 0000:00:02.0: reg 0x10: [mem 0xfe000000-0xfe7fffff pref]
-[    0.247587] pci 0000:00:02.0: reg 0x14: [mem 0xfebd1000-0xfebd1fff]
-[    0.250649] pci 0000:00:02.0: reg 0x18: [mem 0x1c0004000-0x1c0007fff 64bit pref]
-[    0.253628] pci 0000:00:02.0: reg 0x20: [mem 0x180000000-0x1bfffffff 64bit pref]
-[    0.256753] pci 0000:00:02.0: reg 0x30: [mem 0xfebc0000-0xfebcffff pref]
-[    0.258570] pci 0000:00:02.0: Video device with shadowed ROM at [mem 0x000c0000-0x000dffff]
-[    0.263325] pci 0000:00:1d.0: [8086:2934] type 00 class 0x0c0300
-[    0.265363] pci 0000:00:1d.0: reg 0x20: [io  0xc060-0xc07f]
-[    0.266765] pci 0000:00:1d.1: [8086:2935] type 00 class 0x0c0300
-[    0.269437] pci 0000:00:1d.1: reg 0x20: [io  0xc080-0xc09f]
-[    0.270732] pci 0000:00:1d.2: [8086:2936] type 00 class 0x0c0300
-[    0.273371] pci 0000:00:1d.2: reg 0x20: [io  0xc0a0-0xc0bf]
-[    0.274696] pci 0000:00:1d.7: [8086:293a] type 00 class 0x0c0320
-[    0.276035] pci 0000:00:1d.7: reg 0x10: [mem 0xfebd2000-0xfebd2fff]
-[    0.279317] pci 0000:00:1f.0: [8086:2918] type 00 class 0x060100
-[    0.280866] pci 0000:00:1f.0: quirk: [io  0x0600-0x067f] claimed by ICH6 ACPI/GPIO/TCO
-[    0.282331] pci 0000:00:1f.2: [8086:2922] type 00 class 0x010601
-[    0.284903] pci 0000:00:1f.2: reg 0x20: [io  0xc0c0-0xc0df]
-[    0.286143] pci 0000:00:1f.2: reg 0x24: [mem 0xfebd3000-0xfebd3fff]
-[    0.287991] pci 0000:00:1f.3: [8086:2930] type 00 class 0x0c0500
-[    0.290370] pci 0000:00:1f.3: reg 0x20: [io  0x0700-0x073f]
-[    0.293435] ACPI: PCI: Interrupt link LNKA configured for IRQ 10
-[    0.293726] ACPI: PCI: Interrupt link LNKB configured for IRQ 10
-[    0.294744] ACPI: PCI: Interrupt link LNKC configured for IRQ 11
-[    0.295723] ACPI: PCI: Interrupt link LNKD configured for IRQ 11
-[    0.296740] ACPI: PCI: Interrupt link LNKE configured for IRQ 10
-[    0.297763] ACPI: PCI: Interrupt link LNKF configured for IRQ 10
-[    0.298722] ACPI: PCI: Interrupt link LNKG configured for IRQ 11
-[    0.299743] ACPI: PCI: Interrupt link LNKH configured for IRQ 11
-[    0.300662] ACPI: PCI: Interrupt link GSIA configured for IRQ 16
-[    0.301579] ACPI: PCI: Interrupt link GSIB configured for IRQ 17
-[    0.301618] ACPI: PCI: Interrupt link GSIC configured for IRQ 18
-[    0.302625] ACPI: PCI: Interrupt link GSID configured for IRQ 19
-[    0.303570] ACPI: PCI: Interrupt link GSIE configured for IRQ 20
-[    0.303617] ACPI: PCI: Interrupt link GSIF configured for IRQ 21
-[    0.304524] ACPI: PCI: Interrupt link GSIG configured for IRQ 22
-[    0.304617] ACPI: PCI: Interrupt link GSIH configured for IRQ 23
-[    0.307401] iommu: Default domain type: Translated 
-[    0.307611] iommu: DMA domain TLB invalidation policy: lazy mode 
-[    0.309801] pci 0000:00:02.0: vgaarb: setting as boot VGA device
-[    0.310602] pci 0000:00:02.0: vgaarb: VGA device added: decodes=io+mem,owns=io+mem,locks=none
-[    0.310612] pci 0000:00:02.0: vgaarb: bridge control possible
-[    0.311469] vgaarb: loaded
-[    0.312823] SCSI subsystem initialized
-[    0.314995] libata version 3.00 loaded.
-[    0.315348] ACPI: bus type USB registered
-[    0.315984] usbcore: registered new interface driver usbfs
-[    0.316671] usbcore: registered new interface driver hub
-[    0.317497] usbcore: registered new device driver usb
-[    0.317760] pps_core: LinuxPPS API ver. 1 registered
-[    0.318568] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
-[    0.318672] PTP clock support registered
-[    0.320169] Advanced Linux Sound Architecture Driver Initialized.
-[    0.322001] NetLabel: Initializing
-[    0.322614] NetLabel:  domain hash size = 128
-[    0.323353] NetLabel:  protocols = UNLABELED CIPSOv4 CALIPSO
-[    0.323799] NetLabel:  unlabeled traffic allowed by default
-[    0.324864] PCI: Using ACPI for IRQ routing
-[    0.486511] PCI: pci_cache_line_size set to 64 bytes
-[    0.487017] e820: reserve RAM buffer [mem 0x0009fc00-0x0009ffff]
-[    0.487056] e820: reserve RAM buffer [mem 0x7ffde000-0x7fffffff]
-[    0.488868] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0
-[    0.489610] hpet0: 3 comparators, 64-bit 100.000000 MHz counter
-[    0.493993] clocksource: Switched to clocksource tsc-early
-[    0.595279] VFS: Disk quotas dquot_6.6.0
-[    0.604747] VFS: Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
-[    0.606192] pnp: PnP ACPI init
-[    0.607564] system 00:05: [mem 0xb0000000-0xbfffffff window] has been reserved
-[    0.612917] pnp: PnP ACPI: found 6 devices
-[    0.630876] clocksource: acpi_pm: mask: 0xffffff max_cycles: 0xffffff, max_idle_ns: 2085701024 ns
-[    0.635819] NET: Registered PF_INET protocol family
-[    0.639137] IP idents hash table entries: 65536 (order: 7, 524288 bytes, linear)
-[    0.648315] tcp_listen_portaddr_hash hash table entries: 2048 (order: 3, 32768 bytes, linear)
-[    0.649938] TCP established hash table entries: 32768 (order: 6, 262144 bytes, linear)
-[    0.656731] TCP bind hash table entries: 32768 (order: 7, 524288 bytes, linear)
-[    0.668799] TCP: Hash tables configured (established 32768 bind 32768)
-[    0.670725] UDP hash table entries: 2048 (order: 4, 65536 bytes, linear)
-[    0.675922] UDP-Lite hash table entries: 2048 (order: 4, 65536 bytes, linear)
-[    0.677641] NET: Registered PF_UNIX/PF_LOCAL protocol family
-[    0.683489] RPC: Registered named UNIX socket transport module.
-[    0.684419] RPC: Registered udp transport module.
-[    0.685233] RPC: Registered tcp transport module.
-[    0.686051] RPC: Registered tcp NFSv4.1 backchannel transport module.
-[    0.690218] pci_bus 0000:00: resource 4 [io  0x0000-0x0cf7 window]
-[    0.691147] pci_bus 0000:00: resource 5 [io  0x0d00-0xffff window]
-[    0.692046] pci_bus 0000:00: resource 6 [mem 0x000a0000-0x000bffff window]
-[    0.695623] pci_bus 0000:00: resource 7 [mem 0x80000000-0xafffffff window]
-[    0.702621] pci_bus 0000:00: resource 8 [mem 0xc0000000-0xfebfffff window]
-[    0.703550] pci_bus 0000:00: resource 9 [mem 0x180000000-0x97fffffff window]
-[    0.709679] ACPI: \_SB_.GSIA: Enabled at IRQ 16
-[    0.711527] ACPI: \_SB_.GSIB: Enabled at IRQ 17
-[    0.717245] ACPI: \_SB_.GSIC: Enabled at IRQ 18
-[    0.718745] ACPI: \_SB_.GSID: Enabled at IRQ 19
-[    0.720153] PCI: CLS 0 bytes, default 64
-[    0.725883] PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
-[    0.726841] software IO TLB: mapped [mem 0x000000007bfcf000-0x000000007ffcf000] (64MB)
-[    0.728264] Unpacking initramfs...
-[    0.744075] Freeing initrd memory: 4K
-[    0.756363] Initialise system trusted keyrings
-[    0.758663] workingset: timestamp_bits=56 max_order=20 bucket_order=0
-[    0.764972] NFS: Registering the id_resolver key type
-[    0.767942] Key type id_resolver registered
-[    0.768863] Key type id_legacy registered
-[    0.770030] 9p: Installing v9fs 9p2000 file system support
-[    0.775964] Key type asymmetric registered
-[    0.776761] Asymmetric key parser 'x509' registered
-[    0.777862] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 251)
-[    0.779862] io scheduler mq-deadline registered
-[    0.780675] io scheduler kyber registered
-[    0.782859] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input0
-[    0.787721] ACPI: button: Power Button [PWRF]
-[    0.791799] ACPI: \_SB_.GSIF: Enabled at IRQ 21
-[    0.795895] ACPI: \_SB_.GSIG: Enabled at IRQ 22
-[    0.802029] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
-[    0.803727] 00:03: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A
-[    0.806289] Non-volatile memory driver v1.3
-[    0.807110] Linux agpgart interface v0.103
-[    0.808280] ACPI: bus type drm_connector registered
-[    0.810106] [drm] pci: virtio-vga detected at 0000:00:02.0
-[    0.811033] virtio-pci 0000:00:02.0: vgaarb: deactivate vga console
-[    0.812950] Console: switching to colour dummy device 80x25
-[    0.814010] [drm] Host memory window: 0x180000000 +0x40000000
-[    0.814014] [drm] features: +virgl +edid +resource_blob +host_visible
-[    0.814015] [drm] features: +context_init
-[    0.815749] [drm] number of scanouts: 1
-[    0.815764] [drm] number of cap sets: 1
-[    0.822421] [drm] cap set 0: id 4, max-version 0, max-size 20
-[    0.823816] [drm] Initialized virtio_gpu 0.1.0 0 for virtio1 on minor 0
-[    0.835655] loop: module loaded
-[    0.836198] ahci 0000:00:1f.2: version 3.0
-[    0.838738] ahci 0000:00:1f.2: AHCI 0001.0000 32 slots 6 ports 1.5 Gbps 0x3f impl SATA mode
-[    0.838743] ahci 0000:00:1f.2: flags: 64bit ncq only 
-[    0.844268] scsi host0: ahci
-[    0.845062] scsi host1: ahci
-[    0.845675] scsi host2: ahci
-[    0.846482] scsi host3: ahci
-[    0.847257] scsi host4: ahci
-[    0.847860] scsi host5: ahci
-[    0.848240] ata1: SATA max UDMA/133 abar m4096@0xfebd3000 port 0xfebd3100 irq 27
-[    0.848266] ata2: SATA max UDMA/133 abar m4096@0xfebd3000 port 0xfebd3180 irq 27
-[    0.848281] ata3: SATA max UDMA/133 abar m4096@0xfebd3000 port 0xfebd3200 irq 27
-[    0.848295] ata4: SATA max UDMA/133 abar m4096@0xfebd3000 port 0xfebd3280 irq 27
-[    0.848310] ata5: SATA max UDMA/133 abar m4096@0xfebd3000 port 0xfebd3300 irq 27
-[    0.848324] ata6: SATA max UDMA/133 abar m4096@0xfebd3000 port 0xfebd3380 irq 27
-[    0.854343] e100: Intel(R) PRO/100 Network Driver
-[    0.854365] e100: Copyright(c) 1999-2006 Intel Corporation
-[    0.854401] e1000: Intel(R) PRO/1000 Network Driver
-[    0.854403] e1000: Copyright (c) 1999-2006 Intel Corporation.
-[    0.854505] e1000e: Intel(R) PRO/1000 Network Driver
-[    0.854506] e1000e: Copyright(c) 1999 - 2015 Intel Corporation.
-[    0.854562] sky2: driver version 1.30
-[    0.855224] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
-[    0.855227] ehci-pci: EHCI PCI platform driver
-[    0.856209] ehci-pci 0000:00:1d.7: EHCI Host Controller
-[    0.856447] ehci-pci 0000:00:1d.7: new USB bus registered, assigned bus number 1
-[    0.857195] ehci-pci 0000:00:1d.7: irq 19, io mem 0xfebd2000
-[    0.863684] ehci-pci 0000:00:1d.7: USB 2.0 started, EHCI 1.00
-[    0.863941] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 5.16
-[    0.863946] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
-[    0.863948] usb usb1: Product: EHCI Host Controller
-[    0.863950] usb usb1: Manufacturer: Linux 5.16.14 ehci_hcd
-[    0.863952] usb usb1: SerialNumber: 0000:00:1d.7
-[    0.864286] hub 1-0:1.0: USB hub found
-[    0.864294] hub 1-0:1.0: 6 ports detected
-[    0.864919] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
-[    0.864953] ohci-pci: OHCI PCI platform driver
-[    0.865050] uhci_hcd: USB Universal Host Controller Interface driver
-[    0.865658] uhci_hcd 0000:00:1d.0: UHCI Host Controller
-[    0.865792] uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 2
-[    0.866072] uhci_hcd 0000:00:1d.0: irq 16, io port 0x0000c060
-[    0.866256] usb usb2: New USB device found, idVendor=1d6b, idProduct=0001, bcdDevice= 5.16
-[    0.866259] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
-[    0.866262] usb usb2: Product: UHCI Host Controller
-[    0.866263] usb usb2: Manufacturer: Linux 5.16.14 uhci_hcd
-[    0.866265] usb usb2: SerialNumber: 0000:00:1d.0
-[    0.866537] hub 2-0:1.0: USB hub found
-[    0.866542] hub 2-0:1.0: 2 ports detected
-[    0.867382] uhci_hcd 0000:00:1d.1: UHCI Host Controller
-[    0.867567] uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 3
-[    0.867827] uhci_hcd 0000:00:1d.1: irq 17, io port 0x0000c080
-[    0.868033] usb usb3: New USB device found, idVendor=1d6b, idProduct=0001, bcdDevice= 5.16
-[    0.868037] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1
-[    0.868039] usb usb3: Product: UHCI Host Controller
-[    0.868040] usb usb3: Manufacturer: Linux 5.16.14 uhci_hcd
-[    0.868042] usb usb3: SerialNumber: 0000:00:1d.1
-[    0.868240] hub 3-0:1.0: USB hub found
-[    0.868245] hub 3-0:1.0: 2 ports detected
-[    0.869174] uhci_hcd 0000:00:1d.2: UHCI Host Controller
-[    0.869321] uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 4
-[    0.869553] uhci_hcd 0000:00:1d.2: irq 18, io port 0x0000c0a0
-[    0.869959] usb usb4: New USB device found, idVendor=1d6b, idProduct=0001, bcdDevice= 5.16
-[    0.869963] usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1
-[    0.869965] usb usb4: Product: UHCI Host Controller
-[    0.870002] usb usb4: Manufacturer: Linux 5.16.14 uhci_hcd
-[    0.870003] usb usb4: SerialNumber: 0000:00:1d.2
-[    0.870149] hub 4-0:1.0: USB hub found
-[    0.870153] hub 4-0:1.0: 2 ports detected
-[    0.870910] usbcore: registered new interface driver usblp
-[    0.870991] usbcore: registered new interface driver usb-storage
-[    0.871112] i8042: PNP: PS/2 Controller [PNP0303:KBD,PNP0f13:MOU] at 0x60,0x64 irq 1,12
-[    0.873033] serio: i8042 KBD port at 0x60,0x64 irq 1
-[    0.873240] serio: i8042 AUX port at 0x60,0x64 irq 12
-[    0.874086] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input1
-[    0.878739] rtc_cmos 00:04: RTC can wake from S4
-[    0.880210] rtc_cmos 00:04: registered as rtc0
-[    0.880321] rtc_cmos 00:04: alarms up to one day, y3k, 242 bytes nvram, hpet irqs
-[    0.880886] i801_smbus 0000:00:1f.3: SMBus using PCI interrupt
-[    0.881236] i2c i2c-0: 1/1 memory slots populated (from DMI)
-[    0.881239] i2c i2c-0: Memory type 0x07 not supported yet, not instantiating SPD
-[    0.881737] device-mapper: ioctl: 4.45.0-ioctl (2021-03-22) initialised: dm-devel@redhat.com
-[    0.882038] hid: raw HID events driver (C) Jiri Kosina
-[    0.882495] usbcore: registered new interface driver usbhid
-[    0.882498] usbhid: USB HID core driver
-[    0.890838] Initializing XFRM netlink socket
-[    0.891351] NET: Registered PF_INET6 protocol family
-[    0.893594] Segment Routing with IPv6
-[    0.893647] In-situ OAM (IOAM) with IPv6
-[    0.893870] sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
-[    0.894342] NET: Registered PF_PACKET protocol family
-[    0.894821] 9pnet: Installing 9P2000 support
-[    0.894914] Key type dns_resolver registered
-[    0.895481] IPI shorthand broadcast: enabled
-[    0.895672] sched_clock: Marking stable (908022380, -12397814)->(1044483817, -148859251)
-[    0.895978] registered taskstats version 1
-[    0.895980] Loading compiled-in X.509 certificates
-[    0.897126] cryptomgr_test (53) used greatest stack depth: 15480 bytes left
-[    0.897149] cryptomgr_test (54) used greatest stack depth: 15448 bytes left
-[    0.898086] cryptomgr_test (69) used greatest stack depth: 15392 bytes left
-[    0.900491] PM:   Magic number: 14:469:477
-[    0.901051] printk: console [netcon0] enabled
-[    0.901053] netconsole: network logging started
-[    0.901456] cfg80211: Loading compiled-in X.509 certificates for regulatory database
-[    0.903159] kworker/u2:6 (76) used greatest stack depth: 14656 bytes left
-[    0.903680] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
-[    0.903771] ALSA device list:
-[    0.903773]   No soundcards found.
-[    0.904412] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2
-[    0.904450] cfg80211: failed to load regulatory.db
-[    1.094640] usb 1-1: new high-speed USB device number 2 using ehci-pci
-[    1.146521] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
-[    1.146780] ata1.00: ATA-7: QEMU HARDDISK, 2.5+, max UDMA/100
-[    1.146785] ata1.00: 33554432 sectors, multi 16: LBA48 NCQ (depth 32)
-[    1.146810] ata1.00: applying bridge limits
-[    1.147076] ata1.00: configured for UDMA/100
-[    1.147318] ata2: SATA link down (SStatus 0 SControl 300)
-[    1.154178] ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
-[    1.154371] ata3.00: ATAPI: QEMU DVD-ROM, 2.5+, max UDMA/100
-[    1.154375] ata3.00: applying bridge limits
-[    1.154673] ata3.00: configured for UDMA/100
-[    1.155258] ata4: SATA link down (SStatus 0 SControl 300)
-[    1.155530] ata5: SATA link down (SStatus 0 SControl 300)
-[    1.155833] ata6: SATA link down (SStatus 0 SControl 300)
-[    1.157704] scsi 0:0:0:0: Direct-Access     ATA      QEMU HARDDISK    2.5+ PQ: 0 ANSI: 5
-[    1.158268] sd 0:0:0:0: [sda] 33554432 512-byte logical blocks: (17.2 GB/16.0 GiB)
-[    1.158307] sd 0:0:0:0: [sda] Write Protect is off
-[    1.158309] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
-[    1.158316] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
-[    1.158993] sd 0:0:0:0: Attached scsi generic sg0 type 0
-[    1.165858] scsi 2:0:0:0: CD-ROM            QEMU     QEMU DVD-ROM     2.5+ PQ: 0 ANSI: 5
-[    1.175815]  sda: sda1 sda2 sda3
-[    1.176475] sd 0:0:0:0: [sda] Attached SCSI disk
-[    1.181093] sr 2:0:0:0: [sr0] scsi3-mmc drive: 4x/4x cd/rw xa/form2 tray
-[    1.181149] cdrom: Uniform CD-ROM driver Revision: 3.20
-[    1.197445] sr 2:0:0:0: Attached scsi CD-ROM sr0
-[    1.197689] sr 2:0:0:0: Attached scsi generic sg1 type 5
-[    1.224877] usb 1-1: New USB device found, idVendor=0627, idProduct=0001, bcdDevice= 0.00
-[    1.224885] usb 1-1: New USB device strings: Mfr=1, Product=3, SerialNumber=10
-[    1.224887] usb 1-1: Product: QEMU USB Tablet
-[    1.224889] usb 1-1: Manufacturer: QEMU
-[    1.224891] usb 1-1: SerialNumber: 28754-0000:00:1d.7-1
-[    1.231334] input: QEMU QEMU USB Tablet as /devices/pci0000:00/0000:00:1d.7/usb1/1-1/1-1:1.0/0003:0627:0001.0001/input/input4
-[    1.231474] hid-generic 0003:0627:0001.0001: input,hidraw0: USB HID v0.01 Mouse [QEMU QEMU USB Tablet] on usb-0000:00:1d.7-1/input0
-[    1.484028] random: fast init done
-[    1.486085] input: ImExPS/2 Generic Explorer Mouse as /devices/platform/i8042/serio1/input/input3
-[    1.486277] md: Waiting for all devices to be available before autodetect
-[    1.486280] md: If you don't use raid, use raid=noautodetect
-[    1.486308] md: Autodetecting RAID arrays.
-[    1.486310] md: autorun ...
-[    1.486311] md: ... autorun DONE.
-[    1.489760] EXT4-fs (sda3): INFO: recovery required on readonly filesystem
-[    1.489764] EXT4-fs (sda3): write access will be enabled during recovery
-[    1.549515] EXT4-fs (sda3): recovery complete
-[    1.551218] EXT4-fs (sda3): mounted filesystem with ordered data mode. Opts: (null). Quota mode: none.
-[    1.551395] VFS: Mounted root (ext4 filesystem) readonly on device 8:3.
-[    1.552185] devtmpfs: mounted
-[    1.564828] Freeing unused kernel image (initmem) memory: 1252K
-[    1.565429] Write protecting the kernel read-only data: 24576k
-[    1.588472] Freeing unused kernel image (text/rodata gap) memory: 2032K
-[    1.599305] Freeing unused kernel image (rodata/data gap) memory: 1092K
-[    1.600131] Run /sbin/init as init process
-[    1.600145]   with arguments:
-[    1.600145]     /sbin/init
-[    1.600145]     nokaslr
-[    1.600146]   with environment:
-[    1.600146]     HOME=/
-[    1.600146]     TERM=linux
-[    1.719163] systemd[1]: systemd 248.3-1ubuntu8.2 running in system mode. (+PAM +AUDIT +SELINUX +APPARMOR +IMA +SMACK +SECCOMP +GCRYPT +GNUTLS -OPENSSL +ACL +BLKID +CURL +ELFUTILS -FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP -LIBFDISK +PCRE2 -PWQUALITY -P11KIT -QRENCODE +BZIP2 +LZ4 +XZ +ZLIB +ZSTD -XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified)
-[    1.719924] systemd[1]: Detected virtualization kvm.
-[    1.719999] systemd[1]: Detected architecture x86-64.
-[    1.721691] systemd[1]: Hostname set to <lygstate-Standard-PC-Q35-ICH9-2009>.
-[    1.742316] (sd-executor) (84) used greatest stack depth: 13744 bytes left
-[    1.747792] tsc: Refined TSC clocksource calibration: 3699.944 MHz
-[    1.747936] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x6aaa423949d, max_idle_ns: 881591081251 ns
-[    1.748220] clocksource: Switched to clocksource tsc
-[    1.804055] friendly-recove (87) used greatest stack depth: 13736 bytes left
-[    1.857049] openvpn-generat (89) used greatest stack depth: 13672 bytes left
-[    1.857104] ls (104) used greatest stack depth: 13616 bytes left
-[    2.049195] systemd[1]: Queued start job for default target Graphical Interface.
-[    2.053399] systemd[1]: Created slice system-modprobe.slice.
-[    2.055075] systemd[1]: Created slice system-systemd\x2dfsck.slice.
-[    2.055330] systemd[1]: Created slice User and Session Slice.
-[    2.055443] systemd[1]: Started Forward Password Requests to Wall Directory Watch.
-[    2.057210] systemd[1]: Set up automount Arbitrary Executable File Formats File System Automount Point.
-[    2.057325] systemd[1]: Reached target User and Group Name Lookups.
-[    2.057352] systemd[1]: Reached target Remote File Systems.
-[    2.057371] systemd[1]: Reached target Slices.
-[    2.057397] systemd[1]: Reached target Local Verity Integrity Protected Volumes.
-[    2.058182] systemd[1]: Listening on Syslog Socket.
-[    2.058530] systemd[1]: Listening on fsck to fsckd communication Socket.
-[    2.058768] systemd[1]: Listening on initctl Compatibility Named Pipe.
-[    2.059725] systemd[1]: Listening on Journal Audit Socket.
-[    2.059946] systemd[1]: Listening on Journal Socket (/dev/log).
-[    2.060156] systemd[1]: Listening on Journal Socket.
-[    2.060815] systemd[1]: Listening on udev Control Socket.
-[    2.060970] systemd[1]: Listening on udev Kernel Socket.
-[    2.065155] systemd[1]: Mounting Huge Pages File System...
-[    2.069417] systemd[1]: Mounting POSIX Message Queue File System...
-[    2.079658] systemd[1]: Mounting Kernel Debug File System...
-[    2.082741] systemd[1]: Mounting Kernel Trace File System...
-[    2.083848] systemd[1]: systemd-journald.service: unit configures an IP firewall, but the local system does not support BPF/cgroup firewalling.
-[    2.083853] systemd[1]: (This warning is only shown for the first unit using IP firewalling.)
-[    2.089029] systemd[1]: Starting Journal Service...
-[    2.275345] systemd[1]: Starting Set the console keyboard layout...
-[    2.331794] systemd[1]: Condition check resulted in Create list of static device nodes for the current kernel being skipped.
-[    2.373032] systemd[1]: Starting Load Kernel Module configfs...
-[    2.390012] systemd[1]: Starting Load Kernel Module drm...
-[    2.401425] systemd[1]: Starting Load Kernel Module fuse...
-[    2.418703] systemd[1]: Condition check resulted in Set Up Additional Binary Formats being skipped.
-[    2.420064] systemd[1]: Starting File System Check on Root Device...
-[    2.432087] systemd[1]: Starting Load Kernel Modules...
-[    2.452273] systemd[1]: Starting Coldplug All udev Devices...
-[    2.468269] systemd[1]: Starting Uncomplicated firewall...
-[    2.518424] systemd[1]: Mounted Huge Pages File System.
-[    2.518764] systemd[1]: Mounted POSIX Message Queue File System.
-[    2.518974] systemd[1]: Mounted Kernel Debug File System.
-[    2.519140] systemd[1]: Mounted Kernel Trace File System.
-[    2.530711] systemd[1]: modprobe@configfs.service: Deactivated successfully.
-[    2.531730] systemd[1]: Finished Load Kernel Module configfs.
-[    2.538860] systemd[1]: modprobe@drm.service: Deactivated successfully.
-[    2.544760] systemd[1]: Finished Load Kernel Module drm.
-[    2.545030] systemd[1]: modprobe@fuse.service: Deactivated successfully.
-[    2.546685] systemd[1]: Finished Load Kernel Module fuse.
-[    2.546931] systemd[1]: systemd-modules-load.service: Main process exited, code=exited, status=1/FAILURE
-[    2.546980] systemd[1]: systemd-modules-load.service: Failed with result 'exit-code'.
-[    2.549652] systemd[1]: Failed to start Load Kernel Modules.
-[    2.552638] systemd[1]: Finished Uncomplicated firewall.
-[    2.553148] systemd[1]: Condition check resulted in FUSE Control File System being skipped.
-[    2.553189] systemd[1]: Condition check resulted in Kernel Configuration File System being skipped.
-[    2.557719] systemd[1]: Started File System Check Daemon to report status.
-[    2.566265] systemd[1]: Starting Apply Kernel Variables...
-[    2.579756] systemd[1]: Started Journal Service.
-[    2.641573] random: crng init done
-[    2.718179] EXT4-fs (sda3): re-mounted. Opts: errors=remount-ro. Quota mode: none.
-[    2.732681] Adding 752916k swap on /swapfile.  Priority:-2 extents:3 across:769300k 
-[    2.733844] swapon (132) used greatest stack depth: 13568 bytes left
-[    2.735312] systemd-journald[110]: Received client request to flush runtime journal.
-[    2.743169] systemd-journald[110]: File /var/log/journal/6baf11e8245c4ca98eface85b84be32f/system.journal corrupted or uncleanly shut down, renaming and replacing.
-[    2.811309] loop0: detected capacity change from 0 to 203424
-[    2.815025] loop1: detected capacity change from 0 to 126632
-[    2.815152] loop2: detected capacity change from 0 to 8
-[    2.827343] loop3: detected capacity change from 0 to 307976
-[    2.841748] loop0: detected capacity change from 0 to 133552
-[    2.843903] loop4: detected capacity change from 0 to 496320
-[    2.847378] loop1: detected capacity change from 0 to 111048
-[    2.914163] journal-offline (149) used greatest stack depth: 13344 bytes left
-[    3.788267] virtio_net virtio0 enp0s1: renamed from eth0
-[    9.114766] language-option (340) used greatest stack depth: 12992 bytes left
-[   12.965077] loop0: detected capacity change from 0 to 8
-[   15.602770] systemd-journald[110]: File /var/log/journal/6baf11e8245c4ca98eface85b84be32f/user-1000.journal corrupted or uncleanly shut down, renaming and replacing.
-[   19.878209] virtio_gpu virtio1: [drm] drm_plane_enable_fb_damage_clips() not called
-[  313.191235] loop0: detected capacity change from 0 to 8
-[  334.252458] loop0: detected capacity change from 0 to 126760
-[  336.575589] loop0: detected capacity change from 0 to 226664
-[  613.230337] loop0: detected capacity change from 0 to 8
-[  660.444496] kworker/dying (50) used greatest stack depth: 12400 bytes left
-[  809.013491] clocksource: timekeeping watchdog on CPU0: hpet wd-wd read-back delay of 65260ns
-[  809.013577] clocksource: wd-tsc-wd read-back delay of 1983150ns, clock-skew test skipped!
-[  913.163318] loop0: detected capacity change from 0 to 8
-[ 1213.159179] loop0: detected capacity change from 0 to 8
-[ 1513.151818] loop0: detected capacity change from 0 to 8
-[ 1813.150457] loop0: detected capacity change from 0 to 8
-```
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/928 b/gitlab/issues_text/target_i386/host_missing/accel_missing/928
deleted file mode 100644
index 650fa3fa8..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/928
+++ /dev/null
@@ -1,84 +0,0 @@
-QEMU/TCG generates #GP instead #SS for RBP/RSP based faults
-Description of problem:
-Setting RSP/RBP to a non-canonical address and trying to access a memory location based on RSP/RBP generates a #GP under QEMU/TCG while it should generate an #SS exception instead. This difference in behavior triggers a [Xen selftest](https://github.com/xen-project/xen/blob/1145d94c738e/xen/arch/x86/extable.c#L142-L144) violation as can be seen below.
-
-- A successful run should look like this, e.g. when run under KVM:
-
-```
-(XEN) Running stub recovery selftests...
-(XEN) Fixup #UD[0000]: ffff82d07fffe040 [ffff82d07fffe040] -> ffff82d04038b9e7
-(XEN) Fixup #GP[0000]: ffff82d07fffe041 [ffff82d07fffe041] -> ffff82d04038b9e7
-(XEN) Fixup #SS[0000]: ffff82d07fffe040 [ffff82d07fffe040] -> ffff82d04038b9e7
-(XEN) Fixup #BP[0000]: ffff82d07fffe041 [ffff82d07fffe041] -> ffff82d04038b9e7
-```
-
-- Under QEMU/TCG it triggers this scary warning:
-
-```
-(XEN) Running stub recovery selftests...
-(XEN) Fixup #UD[0000]: ffff82d07fffe040 [ffff82d07fffe040] -> ffff82d04038b9e7
-(XEN) Fixup #GP[0000]: ffff82d07fffe041 [ffff82d07fffe041] -> ffff82d04038b9e7
-(XEN) Fixup #GP[0000]: ffff82d07fffe040 [ffff82d07fffe040] -> ffff82d04038b9e7
-(XEN) Selftest 2 failed: Opc 02 04 04 c3 expected 12[0000], got 13[0000]
-(XEN) Fixup #BP[0000]: ffff82d07fffe041 [ffff82d07fffe041] -> ffff82d04038b9e7
-[...]
-(XEN) ***************************************************
-(XEN) SELFTEST FAILURE: CORRECT BEHAVIOR CANNOT BE GUARANTEED
-(XEN) ***************************************************
-(XEN) 3... 2... 1...
-```
-Steps to reproduce:
-The attached program ([noncanon.c](/uploads/34599a2fe23c6bbf1e9efd8cb8704537/noncanon.c)) generates the following output when run on native hardware or under KVM:
-
-```shell-session
-minipli@bell:~$ for i in "" -sp -bp; do ./noncanon $i; done
-Non-canonical acces via RAX: SIGSEGV, signo 11, error 0, code 128, addr (nil)
-Non-canonical acces via RSP: SIGBUS, signo 7, error 0, code 128, addr (nil)
-Non-canonical acces via RBP: SIGBUS, signo 7, error 0, code 128, addr (nil)
-```
-
-However, when run under QEMU using TCG, I get the following output:
-
-```shell-session
-root@box:~# for i in "" -sp -bp; do ./noncanon $i; done
-Non-canonical acces via RAX: SIGSEGV, signo 11, error 0, code 128, addr (nil)
-Non-canonical acces via RSP: SIGSEGV, signo 11, error 0, code 128, addr (nil)
-Non-canonical acces via RBP: SIGSEGV, signo 11, error 0, code 128, addr (nil)
-```
-
-Please note how RSP/RBP based access generates SIGSEGV instead of the expected SIGBUS.
-Additional information:
-The problem seems to be that QEMU always generates a #GP for non-canonical addresses, while it should differentiate, based on the register that led to the non-canonical address: #SS if RSP/RBP is involved, #GP otherwise. However, short of an instruction decoder, I don't see how this can easily be told apart.
-
-```diff
-diff --git a/target/i386/tcg/sysemu/excp_helper.c b/target/i386/tcg/sysemu/excp_helper.c
-index e1b6d8868338..ac4a6351a49d 100644
---- a/target/i386/tcg/sysemu/excp_helper.c
-+++ b/target/i386/tcg/sysemu/excp_helper.c
-@@ -386,6 +386,7 @@ static int handle_mmu_fault(CPUState *cs, vaddr addr, int size,
-             sext = (int64_t)addr >> (pg_mode & PG_MODE_LA57 ? 56 : 47);
-             if (sext != 0 && sext != -1) {
-                 env->error_code = 0;
-+                // XXX: or EXCP0C_STACK for SP/BP bassed error
-                 cs->exception_index = EXCP0D_GPF;
-                 return 1;
-             }
-```
-
-Relevant excerpt from the Intel SDM:
-
-> **6.15 EXCEPTION AND INTERRUPT REFERENCE**  
-> [...]  
-> **Interrupt 12—Stack Fault Exception (#SS)**  
-> [...] 
-> - A canonical violation is detected in 64-bit mode during an operation that reference memory using the stack pointer register containing a non-canonical memory address.
-
-Please note the lack of mentioning the base pointer register, but tests on real hardware show it's subject to this as well.
-
-The AMD manual is more precise about that:
-> **8.2.13 #SS—Stack Exception (Vector 12)**  
-> An #SS exception can occur in the following situations:  
-> - Implied stack references in which the stack address is not in canonical form. Implied stack references include all push and pop instructions, and any instruction using RSP or RBP as a base register  
-> [...]
-
-It explicitly mentions "any instruction using RSP or RBP as a base register".
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/930 b/gitlab/issues_text/target_i386/host_missing/accel_missing/930
deleted file mode 100644
index c1a37495a..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/930
+++ /dev/null
@@ -1 +0,0 @@
-Impossible to make windows 98 work on Qemu ver. 5.2
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/975 b/gitlab/issues_text/target_i386/host_missing/accel_missing/975
deleted file mode 100644
index a4fb042bf..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/975
+++ /dev/null
@@ -1,38 +0,0 @@
-LXD with QEMU 6.2.0 (and 7.0.0-rc3) breaks during stateful migration
-Description of problem:
-
-Steps to reproduce:
-```
-sudo snap install --lxd
-sudo lxd init --auto
-lxc init images:ubuntu/20.04/cloud v1 --vm
-Creating v1
-lxc config device override v1 root size.state=2GiB
-Device root overridden for v1
-lxc config set v1 migration.stateful=true
-lxc start v1
-sleep 10
-lxc exec v1 -- uptime
- 22:05:54 up 0 min,  0 users,  load average: 0.07, 0.02, 0.00
-lxc snapshot v1 --stateful
-Error: Migration call failed
-lxc snapshot v1 --stateful
-Error: Monitor is disconnected
-```
-
-The first attempt at `lxc snapshot v1 --stateful` caused this in the `lxc info v1 --show-log` log output:
-
-```
-qemu-system-x86_64: qemu_savevm_state_complete_precopy_non_iterable: bdrv_inactivate_all() failed (-1)
-```
-
-The second attempt caused this:
-
-```
-qemu-system-x86_64: ../block.c:6757: bdrv_inactivate_recurse: Assertion `!(bs->open_flags & BDRV_O_INACTIVE)' failed.
-```
-
-Which crashed QEMU completely and caused the VM to die.
-Nothing relevant showed up in dmesg, so this wasn't caused by an obvious seccomp or apparmor policy issue.
-Additional information:
-Originally reported by Stephane Graber at https://github.com/lxc/lxd/issues/9875
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/990 b/gitlab/issues_text/target_i386/host_missing/accel_missing/990
deleted file mode 100644
index a98d340ab..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/990
+++ /dev/null
@@ -1 +0,0 @@
-support for vIOMMU and vSR-IOV together in L1 as virtual machine
-- 
cgit 1.4.1