From 9260319e7411ff8281700a532caa436f40120ec4 Mon Sep 17 00:00:00 2001 From: Christian Krinitsin Date: Fri, 30 May 2025 16:52:07 +0200 Subject: gitlab scraper: download in toml and text format --- .../host_missing/accel_missing/101.toml | 15 - .../host_missing/accel_missing/1017.toml | 21 - .../host_missing/accel_missing/1035.toml | 26 - .../host_missing/accel_missing/1040.toml | 18 - .../host_missing/accel_missing/1041.toml | 39 -- .../host_missing/accel_missing/1042.toml | 30 - .../host_missing/accel_missing/1047.toml | 112 ---- .../host_missing/accel_missing/1098.toml | 19 - .../host_missing/accel_missing/1115.toml | 24 - .../host_missing/accel_missing/1131.toml | 28 - .../host_missing/accel_missing/1135.toml | 20 - .../host_missing/accel_missing/116.toml | 15 - .../host_missing/accel_missing/1164.toml | 27 - .../host_missing/accel_missing/1267.toml | 105 ---- .../host_missing/accel_missing/1279.toml | 18 - .../host_missing/accel_missing/1298.toml | 27 - .../host_missing/accel_missing/1323.toml | 25 - .../host_missing/accel_missing/1328.toml | 19 - .../host_missing/accel_missing/1348.toml | 15 - .../host_missing/accel_missing/1368.toml | 46 -- .../host_missing/accel_missing/1382.toml | 48 -- .../host_missing/accel_missing/1383.toml | 15 - .../host_missing/accel_missing/1396.toml | 15 - .../host_missing/accel_missing/141.toml | 15 - .../host_missing/accel_missing/1410.toml | 22 - .../host_missing/accel_missing/1437.toml | 16 - .../host_missing/accel_missing/1472.toml | 15 - .../host_missing/accel_missing/1473.toml | 15 - .../host_missing/accel_missing/1476.toml | 15 - .../host_missing/accel_missing/1492.toml | 300 ---------- .../host_missing/accel_missing/1524.toml | 47 -- .../host_missing/accel_missing/1533.toml | 15 - .../host_missing/accel_missing/1534.toml | 15 - .../host_missing/accel_missing/1570.toml | 71 --- .../host_missing/accel_missing/1628.toml | 138 ----- .../host_missing/accel_missing/1648.toml | 70 --- .../host_missing/accel_missing/1762.toml | 95 ---- .../host_missing/accel_missing/189.toml | 15 - .../host_missing/accel_missing/191.toml | 15 - .../host_missing/accel_missing/1919.toml | 28 - .../host_missing/accel_missing/192.toml | 15 - .../host_missing/accel_missing/1932.toml | 22 - .../host_missing/accel_missing/1947.toml | 28 - .../host_missing/accel_missing/1952.toml | 104 ---- .../host_missing/accel_missing/1956.toml | 15 - .../host_missing/accel_missing/1986.toml | 22 - .../host_missing/accel_missing/1998.toml | 35 -- .../host_missing/accel_missing/2008.toml | 22 - .../host_missing/accel_missing/2020.toml | 21 - .../host_missing/accel_missing/2064.toml | 20 - .../host_missing/accel_missing/2070.toml | 17 - .../host_missing/accel_missing/2079.toml | 15 - .../host_missing/accel_missing/2218.toml | 20 - .../host_missing/accel_missing/223.toml | 15 - .../host_missing/accel_missing/2244.toml | 54 -- .../host_missing/accel_missing/2263.toml | 36 -- .../host_missing/accel_missing/2266.toml | 77 --- .../host_missing/accel_missing/2270.toml | 15 - .../host_missing/accel_missing/2320.toml | 15 - .../host_missing/accel_missing/2330.toml | 81 --- .../host_missing/accel_missing/2334.toml | 264 --------- .../host_missing/accel_missing/237.toml | 15 - .../host_missing/accel_missing/2381.toml | 15 - .../host_missing/accel_missing/2383.toml | 15 - .../host_missing/accel_missing/2393.toml | 28 - .../host_missing/accel_missing/2420.toml | 52 -- .../host_missing/accel_missing/2426.toml | 15 - .../host_missing/accel_missing/243.toml | 15 - .../host_missing/accel_missing/2452.toml | 15 - .../host_missing/accel_missing/2509.toml | 34 -- .../host_missing/accel_missing/2520.toml | 19 - .../host_missing/accel_missing/2530.toml | 25 - .../host_missing/accel_missing/2555.toml | 30 - .../host_missing/accel_missing/2556.toml | 22 - .../host_missing/accel_missing/2562.toml | 64 --- .../host_missing/accel_missing/2583.toml | 33 -- .../host_missing/accel_missing/2586.toml | 15 - .../host_missing/accel_missing/2590.toml | 31 - .../host_missing/accel_missing/2593.toml | 67 --- .../host_missing/accel_missing/2594.toml | 43 -- .../host_missing/accel_missing/2597.toml | 15 - .../host_missing/accel_missing/2616.toml | 19 - .../host_missing/accel_missing/2626.toml | 18 - .../host_missing/accel_missing/2631.toml | 89 --- .../host_missing/accel_missing/2654.toml | 22 - .../host_missing/accel_missing/2657.toml | 19 - .../host_missing/accel_missing/2666.toml | 32 -- .../host_missing/accel_missing/267.toml | 15 - .../host_missing/accel_missing/2739.toml | 15 - .../host_missing/accel_missing/2769.toml | 15 - .../host_missing/accel_missing/2779.toml | 49 -- .../host_missing/accel_missing/2783.toml | 25 - .../host_missing/accel_missing/2813.toml | 17 - .../host_missing/accel_missing/2816.toml | 22 - .../host_missing/accel_missing/2817.toml | 63 -- .../host_missing/accel_missing/2832.toml | 107 ---- .../host_missing/accel_missing/2833.toml | 27 - .../host_missing/accel_missing/2834.toml | 27 - .../host_missing/accel_missing/2848.toml | 25 - .../host_missing/accel_missing/2868.toml | 15 - .../host_missing/accel_missing/2869.toml | 15 - .../host_missing/accel_missing/2874.toml | 19 - .../host_missing/accel_missing/2882.toml | 98 ---- .../host_missing/accel_missing/2892.toml | 15 - .../host_missing/accel_missing/2894.toml | 33 -- .../host_missing/accel_missing/2897.toml | 22 - .../host_missing/accel_missing/2922.toml | 17 - .../host_missing/accel_missing/2954.toml | 31 - .../host_missing/accel_missing/2961.toml | 41 -- .../host_missing/accel_missing/320.toml | 15 - .../host_missing/accel_missing/331.toml | 15 - .../host_missing/accel_missing/368.toml | 15 - .../host_missing/accel_missing/375.toml | 15 - .../host_missing/accel_missing/387.toml | 15 - .../host_missing/accel_missing/389.toml | 15 - .../host_missing/accel_missing/475.toml | 15 - .../host_missing/accel_missing/508.toml | 15 - .../host_missing/accel_missing/510.toml | 15 - .../host_missing/accel_missing/512.toml | 15 - .../host_missing/accel_missing/525.toml | 22 - .../host_missing/accel_missing/536.toml | 15 - .../host_missing/accel_missing/538.toml | 15 - .../host_missing/accel_missing/554.toml | 15 - .../host_missing/accel_missing/561.toml | 15 - .../host_missing/accel_missing/627.toml | 15 - .../host_missing/accel_missing/629.toml | 20 - .../host_missing/accel_missing/641.toml | 15 - .../host_missing/accel_missing/673.toml | 18 - .../host_missing/accel_missing/705.toml | 39 -- .../host_missing/accel_missing/745.toml | 44 -- .../host_missing/accel_missing/752.toml | 23 - .../target_i386/host_missing/accel_missing/77.toml | 15 - .../host_missing/accel_missing/770.toml | 15 - .../host_missing/accel_missing/771.toml | 22 - .../target_i386/host_missing/accel_missing/78.toml | 15 - .../host_missing/accel_missing/780.toml | 62 -- .../host_missing/accel_missing/786.toml | 25 - .../host_missing/accel_missing/791.toml | 15 - .../host_missing/accel_missing/810.toml | 79 --- .../host_missing/accel_missing/837.toml | 40 -- .../host_missing/accel_missing/855.toml | 25 - .../host_missing/accel_missing/871.toml | 24 - .../host_missing/accel_missing/877.toml | 114 ---- .../target_i386/host_missing/accel_missing/91.toml | 15 - .../host_missing/accel_missing/921.toml | 633 --------------------- .../host_missing/accel_missing/928.toml | 92 --- .../host_missing/accel_missing/930.toml | 15 - .../host_missing/accel_missing/975.toml | 46 -- .../host_missing/accel_missing/990.toml | 15 - 149 files changed, 5700 deletions(-) delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/101.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/1017.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/1035.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/1040.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/1041.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/1042.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/1047.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/1098.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/1115.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/1131.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/1135.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/116.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/1164.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/1267.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/1279.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/1298.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/1323.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/1328.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/1348.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/1368.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/1382.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/1383.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/1396.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/141.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/1410.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/1437.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/1472.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/1473.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/1476.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/1492.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/1524.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/1533.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/1534.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/1570.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/1628.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/1648.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/1762.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/189.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/191.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/1919.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/192.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/1932.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/1947.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/1952.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/1956.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/1986.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/1998.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/2008.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/2020.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/2064.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/2070.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/2079.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/2218.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/223.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/2244.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/2263.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/2266.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/2270.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/2320.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/2330.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/2334.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/237.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/2381.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/2383.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/2393.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/2420.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/2426.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/243.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/2452.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/2509.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/2520.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/2530.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/2555.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/2556.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/2562.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/2583.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/2586.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/2590.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/2593.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/2594.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/2597.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/2616.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/2626.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/2631.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/2654.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/2657.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/2666.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/267.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/2739.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/2769.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/2779.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/2783.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/2813.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/2816.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/2817.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/2832.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/2833.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/2834.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/2848.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/2868.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/2869.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/2874.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/2882.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/2892.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/2894.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/2897.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/2922.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/2954.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/2961.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/320.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/331.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/368.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/375.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/387.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/389.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/475.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/508.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/510.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/512.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/525.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/536.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/538.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/554.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/561.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/627.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/629.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/641.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/673.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/705.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/745.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/752.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/77.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/770.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/771.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/78.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/780.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/786.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/791.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/810.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/837.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/855.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/871.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/877.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/91.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/921.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/928.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/930.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/975.toml delete mode 100644 gitlab/issues/target_i386/host_missing/accel_missing/990.toml (limited to 'gitlab/issues/target_i386/host_missing/accel_missing') diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/101.toml b/gitlab/issues/target_i386/host_missing/accel_missing/101.toml deleted file mode 100644 index 8451de75..00000000 --- a/gitlab/issues/target_i386/host_missing/accel_missing/101.toml +++ /dev/null @@ -1,15 +0,0 @@ -id = 101 -title = "Running a virtual machine on a Haswell system produces machine check events" -state = "opened" -created_at = "2021-05-03T16:33:31.593Z" -closed_at = "n/a" -labels = ["Launchpad", "target: i386"] -url = "https://gitlab.com/qemu-project/qemu/-/issues/101" -host-os = "n/a" -host-arch = "n/a" -qemu-version = "n/a" -guest-os = "n/a" -guest-arch = "n/a" -description = "n/a" -reproduce = "n/a" -additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/1017.toml b/gitlab/issues/target_i386/host_missing/accel_missing/1017.toml deleted file mode 100644 index c6c2f5a7..00000000 --- a/gitlab/issues/target_i386/host_missing/accel_missing/1017.toml +++ /dev/null @@ -1,21 +0,0 @@ -id = 1017 -title = "Qemu Windows 10 restart bluescreen" -state = "opened" -created_at = "2022-05-08T10:20:10.081Z" -closed_at = "n/a" -labels = ["target: i386"] -url = "https://gitlab.com/qemu-project/qemu/-/issues/1017" -host-os = "Windows 10 20H2" -host-arch = "x86" -qemu-version = "QEMU emulator version 7.0.0 (v7.0.0-11902-g1d935f4a02-dirty)" -guest-os = "Ubuntu 20.4 TLS Server Edition" -guest-arch = "x86" -description = """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.""" -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 = """""" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/1035.toml b/gitlab/issues/target_i386/host_missing/accel_missing/1035.toml deleted file mode 100644 index bac3dc2c..00000000 --- a/gitlab/issues/target_i386/host_missing/accel_missing/1035.toml +++ /dev/null @@ -1,26 +0,0 @@ -id = 1035 -title = "Hyper-V on KVM does not work on AMD CPUs" -state = "opened" -created_at = "2022-05-23T20:57:34.988Z" -closed_at = "n/a" -labels = ["target: i386"] -url = "https://gitlab.com/qemu-project/qemu/-/issues/1035" -host-os = "Proxmox 7.2" -host-arch = "x86" -qemu-version = "QEMU emulator version 6.2.0 (pve-qemu-kvm_6.2.0)" -guest-os = "Windows 11" -guest-arch = "AMD64" -description = """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 -```""" -reproduce = "n/a" -additional = """Related issue: -https://bugzilla.kernel.org/show_bug.cgi?id=203477""" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/1040.toml b/gitlab/issues/target_i386/host_missing/accel_missing/1040.toml deleted file mode 100644 index bc818b91..00000000 --- a/gitlab/issues/target_i386/host_missing/accel_missing/1040.toml +++ /dev/null @@ -1,18 +0,0 @@ -id = 1040 -title = "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" -state = "opened" -created_at = "2022-05-27T14:11:02.095Z" -closed_at = "n/a" -labels = ["target: i386"] -url = "https://gitlab.com/qemu-project/qemu/-/issues/1040" -host-os = "Arch Linux." -host-arch = "x86_64" -qemu-version = "QEMU emulator version 7.0.0" -guest-os = "Windows Server 2016 Standard" -guest-arch = "x86_64" -description = """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)""" -reproduce = "n/a" -additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/1041.toml b/gitlab/issues/target_i386/host_missing/accel_missing/1041.toml deleted file mode 100644 index fcc8870f..00000000 --- a/gitlab/issues/target_i386/host_missing/accel_missing/1041.toml +++ /dev/null @@ -1,39 +0,0 @@ -id = 1041 -title = "x86_64 Auxillary vector reports platform as i686 which doesn't match the linux kernel" -state = "closed" -created_at = "2022-05-27T18:11:26.561Z" -closed_at = "2022-06-24T17:49:58.495Z" -labels = ["Closed::Fixed", "linux-user", "target: i386"] -url = "https://gitlab.com/qemu-project/qemu/-/issues/1041" -host-os = "Debian GNU/Linux 11 (bullseye)" -host-arch = "x86-64" -qemu-version = "qemu-x86_64 version 5.2.0 (Debian 1:5.2+dfsg-11+deb11u1)" -guest-os = "Linux" -guest-arch = "x86-64" -description = """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""" -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 -#include - -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 = """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/target_i386/host_missing/accel_missing/1042.toml b/gitlab/issues/target_i386/host_missing/accel_missing/1042.toml deleted file mode 100644 index 9ce8501f..00000000 --- a/gitlab/issues/target_i386/host_missing/accel_missing/1042.toml +++ /dev/null @@ -1,30 +0,0 @@ -id = 1042 -title = "windows 10 guest freezes the host on shutdown" -state = "opened" -created_at = "2022-05-27T21:18:58.837Z" -closed_at = "n/a" -labels = ["hostos: Windows", "target: i386"] -url = "https://gitlab.com/qemu-project/qemu/-/issues/1042" -host-os = "Gentoo" -host-arch = "x86-64" -qemu-version = "7.0.0" -guest-os = "Windows 10 Pro 21H1" -guest-arch = "x86-64" -description = """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.""" -reproduce = """1. Start Windows 10 guest. -2. Shutdown Windows 10 guest""" -additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/1047.toml b/gitlab/issues/target_i386/host_missing/accel_missing/1047.toml deleted file mode 100644 index 82d4b4aa..00000000 --- a/gitlab/issues/target_i386/host_missing/accel_missing/1047.toml +++ /dev/null @@ -1,112 +0,0 @@ -id = 1047 -title = "Single stepping Windows 10 bootloader results in Assertion `ret < cpu->num_ases && ret >= 0' failed." -state = "opened" -created_at = "2022-05-29T20:26:39.099Z" -closed_at = "n/a" -labels = ["target: i386"] -url = "https://gitlab.com/qemu-project/qemu/-/issues/1047" -host-os = "Debian 11" -host-arch = "x86_64" -qemu-version = "QEMU emulator version 7.0.0" -guest-os = "Windows 10" -guest-arch = "x64" -description = """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. -```""" -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 = """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:\tmov $0x7d85,%ebx - 0xf7d80:\tout %al,$0xb2 - 0xf7d82:\tpause - 0xf7d84:\thlt - 0xf7d85:\tmov %bp,%sp - 0xf7d88:\tjmp 0xf7dd1 - 0xf7d8a:\tmov %cx,%si - 0xf7d8d:\tmov $0x1,%ax - 0xf7d91:\tadd %al,(%eax) - 0xf7d93:\tcallw 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 .""" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/1098.toml b/gitlab/issues/target_i386/host_missing/accel_missing/1098.toml deleted file mode 100644 index 32f1f748..00000000 --- a/gitlab/issues/target_i386/host_missing/accel_missing/1098.toml +++ /dev/null @@ -1,19 +0,0 @@ -id = 1098 -title = "make check failed at bios-tables-test" -state = "opened" -created_at = "2022-07-04T08:00:26.571Z" -closed_at = "n/a" -labels = ["ACPI", "target: i386"] -url = "https://gitlab.com/qemu-project/qemu/-/issues/1098" -host-os = "CentOS Stream 8" -host-arch = "x86" -qemu-version = "version 7.0.50 (v7.0.0-2269-ge8e86b484e)" -guest-os = "n/a" -guest-arch = "n/a" -description = """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""" -reproduce = """1. ./configure --target-list=x86_64-softmmu --disable-xen --enable-sdl --enable-docs --disable-capstone -2. make -j check V=1""" -additional = """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/target_i386/host_missing/accel_missing/1115.toml b/gitlab/issues/target_i386/host_missing/accel_missing/1115.toml deleted file mode 100644 index 3e6de18e..00000000 --- a/gitlab/issues/target_i386/host_missing/accel_missing/1115.toml +++ /dev/null @@ -1,24 +0,0 @@ -id = 1115 -title = "qemu 7.0.0 stuck at Windows boot logo with SeaBios and MBR disk" -state = "opened" -created_at = "2022-07-22T05:58:30.352Z" -closed_at = "n/a" -labels = ["hostos: Windows", "target: i386"] -url = "https://gitlab.com/qemu-project/qemu/-/issues/1115" -host-os = "Manjaro fully updated" -host-arch = "x86_64" -qemu-version = "7.0.0" -guest-os = "Windows 10 21H1, Windows 10 PE iso" -guest-arch = "x86_64" -description = """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.""" -reproduce = """1. boot Windows image / WinPE iso with SeaBios""" -additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/1131.toml b/gitlab/issues/target_i386/host_missing/accel_missing/1131.toml deleted file mode 100644 index caa0131c..00000000 --- a/gitlab/issues/target_i386/host_missing/accel_missing/1131.toml +++ /dev/null @@ -1,28 +0,0 @@ -id = 1131 -title = "Multiboot: could not move values from provided mmap to another address directly." -state = "closed" -created_at = "2022-07-30T14:42:03.649Z" -closed_at = "2022-08-17T07:25:08.613Z" -labels = ["target: i386"] -url = "https://gitlab.com/qemu-project/qemu/-/issues/1131" -host-os = "Windows 11 with MSYS" -host-arch = "x86_64" -qemu-version = "master branch(fc2cc19ffa02c86ec1471ec8fdbc39d33fcec626)" -guest-os = "n/a" -guest-arch = "n/a" -description = """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; -```""" -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 = """#""" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/1135.toml b/gitlab/issues/target_i386/host_missing/accel_missing/1135.toml deleted file mode 100644 index b68a8c9d..00000000 --- a/gitlab/issues/target_i386/host_missing/accel_missing/1135.toml +++ /dev/null @@ -1,20 +0,0 @@ -id = 1135 -title = "Multiboot: invalid multiboot information block" -state = "opened" -created_at = "2022-08-01T14:09:39.403Z" -closed_at = "n/a" -labels = ["target: i386"] -url = "https://gitlab.com/qemu-project/qemu/-/issues/1135" -host-os = "Windows 11 with MSYS" -host-arch = "x86_64" -qemu-version = "4e06b3fc1b5e1ec03f22190eabe56891dc9c2236" -guest-os = "n/a" -guest-arch = "n/a" -description = """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.""" -reproduce = """""" -additional = """multiboot: [multiboot](/uploads/55fdfcf30ada0af2d00badf11fcd308c/multiboot) - -toop: [toop](/uploads/de3b63ae021303c544105ba1498f3373/toop)""" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/116.toml b/gitlab/issues/target_i386/host_missing/accel_missing/116.toml deleted file mode 100644 index f0082616..00000000 --- a/gitlab/issues/target_i386/host_missing/accel_missing/116.toml +++ /dev/null @@ -1,15 +0,0 @@ -id = 116 -title = "qemu fails under NeXTStep 3.3 when accessing ROM in SCSI-Adapter am53c974" -state = "opened" -created_at = "2021-05-04T05:45:13.039Z" -closed_at = "n/a" -labels = ["Launchpad", "Storage", "target: i386"] -url = "https://gitlab.com/qemu-project/qemu/-/issues/116" -host-os = "n/a" -host-arch = "n/a" -qemu-version = "n/a" -guest-os = "n/a" -guest-arch = "n/a" -description = "n/a" -reproduce = "n/a" -additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/1164.toml b/gitlab/issues/target_i386/host_missing/accel_missing/1164.toml deleted file mode 100644 index bfc16389..00000000 --- a/gitlab/issues/target_i386/host_missing/accel_missing/1164.toml +++ /dev/null @@ -1,27 +0,0 @@ -id = 1164 -title = "q35: incorrect values for PCIEXBAR masks" -state = "opened" -created_at = "2022-08-18T02:46:56.030Z" -closed_at = "n/a" -labels = ["device: PCI", "target: i386"] -url = "https://gitlab.com/qemu-project/qemu/-/issues/1164" -host-os = "n/a" -host-arch = "n/a" -qemu-version = "n/a" -guest-os = "n/a" -guest-arch = "n/a" -description = """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.""" -reproduce = "n/a" -additional = """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/target_i386/host_missing/accel_missing/1267.toml b/gitlab/issues/target_i386/host_missing/accel_missing/1267.toml deleted file mode 100644 index 0c441447..00000000 --- a/gitlab/issues/target_i386/host_missing/accel_missing/1267.toml +++ /dev/null @@ -1,105 +0,0 @@ -id = 1267 -title = "qemu-i386 missing VDSO" -state = "closed" -created_at = "2022-10-20T16:13:04.509Z" -closed_at = "2023-10-31T07:50:33.696Z" -labels = ["Closed::Fixed", "linux-user", "target: i386"] -url = "https://gitlab.com/qemu-project/qemu/-/issues/1267" -host-os = "Asahi Linux (Arch Linux ARM)" -host-arch = "arm64" -qemu-version = "7.0.0, 5.2.0, and git (214a8da23651f2472b296b3293e619fd58d9e212)" -guest-os = "Linux" -guest-arch = "x86 (32-bit)" -description = """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=, env=) at ./include/exec/translator.h:176 -#2 translator_ldub (pc=, env=) 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=, cpu=) at ../../target/i386/translate.c:4506 -#5 0x0000aaaaaab5e1c8 in i386_tr_translate_insn (dcbase=0xffffffffe990, cpu=) at ../../target/i386/translate.c:8569 -#6 0x0000aaaaaabbc9f4 in translator_loop (ops=0xaaaaaacd62b0 , db=0xffffffffe990, cpu=0xaaaaaad786a0, tb=, max_insns=) - 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=, argv=, envp=) at ../../linux-user/main.c:882 -```""" -reproduce = "n/a" -additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/1279.toml b/gitlab/issues/target_i386/host_missing/accel_missing/1279.toml deleted file mode 100644 index 522647a4..00000000 --- a/gitlab/issues/target_i386/host_missing/accel_missing/1279.toml +++ /dev/null @@ -1,18 +0,0 @@ -id = 1279 -title = "please assist resolving windows networking issue" -state = "closed" -created_at = "2022-10-27T12:45:04.889Z" -closed_at = "2022-12-11T18:07:10.636Z" -labels = ["hostos: Windows", "target: i386"] -url = "https://gitlab.com/qemu-project/qemu/-/issues/1279" -host-os = "(Proxmox 7.2)" -host-arch = "(x86_86)" -qemu-version = "(QEMU emulator version 6.2.0 (pve-qemu-kvm_6.2.0)" -guest-os = "(Windows 10 22H2 and before)" -guest-arch = "(x86_64)" -description = """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""" -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.""" -additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/1298.toml b/gitlab/issues/target_i386/host_missing/accel_missing/1298.toml deleted file mode 100644 index 4ecf738b..00000000 --- a/gitlab/issues/target_i386/host_missing/accel_missing/1298.toml +++ /dev/null @@ -1,27 +0,0 @@ -id = 1298 -title = "virtio-pmem not working on microvm: virtio-pmem missing request data" -state = "opened" -created_at = "2022-11-03T23:10:50.472Z" -closed_at = "n/a" -labels = ["device:virtio", "target: i386"] -url = "https://gitlab.com/qemu-project/qemu/-/issues/1298" -host-os = "Debian 6.0.3-1" -host-arch = "amd64" -qemu-version = "QEMU emulator version 7.1.0 (Debian 1:7.1+dfsg-2+b1)" -guest-os = "linux-5.17.15" -guest-arch = "amd64" -description = """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 -```""" -reproduce = "n/a" -additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/1323.toml b/gitlab/issues/target_i386/host_missing/accel_missing/1323.toml deleted file mode 100644 index 1bcec900..00000000 --- a/gitlab/issues/target_i386/host_missing/accel_missing/1323.toml +++ /dev/null @@ -1,25 +0,0 @@ -id = 1323 -title = "qemu-system-x86_64: keyboard not available in cd boot menu" -state = "closed" -created_at = "2022-11-18T15:20:06.770Z" -closed_at = "2022-11-30T08:18:19.712Z" -labels = ["device:input", "hostos: Windows", "target: i386"] -url = "https://gitlab.com/qemu-project/qemu/-/issues/1323" -host-os = "Windows 10 22H2 (Msys2/Mingw64), Debian Bullseye" -host-arch = "x86" -qemu-version = "QEMU emulator version 7.1.90 Tarball (Linux) / QEMU emulator version 7.1.91 Tarball (Windows)" -guest-os = "n/a" -guest-arch = "x86" -description = """While CD boot menu is shown, no keys input affects the CD boot menu""" -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 = """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/target_i386/host_missing/accel_missing/1328.toml b/gitlab/issues/target_i386/host_missing/accel_missing/1328.toml deleted file mode 100644 index a2cd60da..00000000 --- a/gitlab/issues/target_i386/host_missing/accel_missing/1328.toml +++ /dev/null @@ -1,19 +0,0 @@ -id = 1328 -title = "Cannot boot any UEFI systems after upgrade edk2-ovmf" -state = "closed" -created_at = "2022-11-21T22:15:44.840Z" -closed_at = "2022-11-26T04:34:44.821Z" -labels = ["target: i386"] -url = "https://gitlab.com/qemu-project/qemu/-/issues/1328" -host-os = "Arch Linux" -host-arch = "x86-64" -qemu-version = "7.1.0" -guest-os = "(Windows 10 21H1, Fedora 34, etc.)" -guest-arch = "(x86, ARM, s390x, etc.)" -description = """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.""" -reproduce = """1. Update edk2-ovmf to 202208-3 -2. Restart all running VM -3. Vm with UEFI bios cannot boot""" -additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/1348.toml b/gitlab/issues/target_i386/host_missing/accel_missing/1348.toml deleted file mode 100644 index 0ea42e6a..00000000 --- a/gitlab/issues/target_i386/host_missing/accel_missing/1348.toml +++ /dev/null @@ -1,15 +0,0 @@ -id = 1348 -title = "WIN10 MBR/SeaBIOS/CSM machine hangs at boot (same as #1115 https://gitlab.com/qemu-project/qemu/-/issues/1115 )" -state = "opened" -created_at = "2022-11-29T15:45:21.703Z" -closed_at = "n/a" -labels = ["target: i386", "workflow::Needs Info"] -url = "https://gitlab.com/qemu-project/qemu/-/issues/1348" -host-os = "n/a" -host-arch = "n/a" -qemu-version = "n/a" -guest-os = "n/a" -guest-arch = "n/a" -description = "n/a" -reproduce = "n/a" -additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/1368.toml b/gitlab/issues/target_i386/host_missing/accel_missing/1368.toml deleted file mode 100644 index 2e84486a..00000000 --- a/gitlab/issues/target_i386/host_missing/accel_missing/1368.toml +++ /dev/null @@ -1,46 +0,0 @@ -id = 1368 -title = "unexpect rax value" -state = "closed" -created_at = "2022-12-15T07:54:32.732Z" -closed_at = "2023-01-15T16:30:16.041Z" -labels = ["Closed::Invalid", "target: i386"] -url = "https://gitlab.com/qemu-project/qemu/-/issues/1368" -host-os = "Ubuntu 22.04" -host-arch = "x86" -qemu-version = "QEMU emulator version 7.1.94 (v7.2.0-rc4)" -guest-os = "- OS/kernel version:" -guest-arch = "x86" -description = """- 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.""" -reproduce = """- 1. Code currently executed -
-(gdb) x/2i $pc
-=> 0x2202 :\tmov    -0x8(%rbp),%rax
-   0x2206 :\tmovq   $0xb8000,(%rax)
-
-- 2. Value of memory address -0x8(%rbp) -
-(gdb) x /xg $rbp-0x8
-0x7fec8:\t0x000000000007fedf
-
-- 3. Value of rax before execution -
-(gdb) p /x $rax
-$1 = 0xfffffffd
-
-- 4. Value of rax after execution -
-(gdb) p /x $rax
-$1 = 0x7fedf
-
-It's all right so far. -- 5. View the current execution code again -
-(gdb) x/i $pc
-=> 0x2207 :\tmovl   $0xb8000,(%rax)
-
-the code address changed from 0x2206 to 0x2207 and the code changed from "movq xx, xx" to "movl xx, xx".
-Now rax is 0x7fedf. -- 6. After execution
-After executing "movl $0xb8000,(%rax)"
-The rax change to 0x7fede""" -additional = """""" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/1382.toml b/gitlab/issues/target_i386/host_missing/accel_missing/1382.toml deleted file mode 100644 index 241830e7..00000000 --- a/gitlab/issues/target_i386/host_missing/accel_missing/1382.toml +++ /dev/null @@ -1,48 +0,0 @@ -id = 1382 -title = "x86-64 In long mode the Selector Error Code has an improperly encoded Selector Index when dealing with IDT descriptor indexes" -state = "closed" -created_at = "2022-12-18T09:21:03.063Z" -closed_at = "2023-02-06T09:29:50.473Z" -labels = ["target: i386"] -url = "https://gitlab.com/qemu-project/qemu/-/issues/1382" -host-os = "Ubuntu 18.04" -host-arch = "x86" -qemu-version = "2.11.1/7.2.0 (Probably all versions)" -guest-os = "N/A" -guest-arch = "x86-64" -description = """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.""" -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 = """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/target_i386/host_missing/accel_missing/1383.toml b/gitlab/issues/target_i386/host_missing/accel_missing/1383.toml deleted file mode 100644 index ad5d6761..00000000 --- a/gitlab/issues/target_i386/host_missing/accel_missing/1383.toml +++ /dev/null @@ -1,15 +0,0 @@ -id = 1383 -title = "Pentium Pro cpuid capabilities are wrong, resulting in wrong definition of athlon and others" -state = "opened" -created_at = "2022-12-20T00:49:40.697Z" -closed_at = "n/a" -labels = ["target: i386"] -url = "https://gitlab.com/qemu-project/qemu/-/issues/1383" -host-os = "n/a" -host-arch = "n/a" -qemu-version = "n/a" -guest-os = "n/a" -guest-arch = "n/a" -description = "n/a" -reproduce = "n/a" -additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/1396.toml b/gitlab/issues/target_i386/host_missing/accel_missing/1396.toml deleted file mode 100644 index abefd7dd..00000000 --- a/gitlab/issues/target_i386/host_missing/accel_missing/1396.toml +++ /dev/null @@ -1,15 +0,0 @@ -id = 1396 -title = "Is it possible to emulate QEMU 64 Bit on Windows?" -state = "closed" -created_at = "2022-12-25T16:30:34.683Z" -closed_at = "2022-12-29T08:55:01.761Z" -labels = ["hostos: Windows", "target: i386"] -url = "https://gitlab.com/qemu-project/qemu/-/issues/1396" -host-os = "Windows 10" -host-arch = "64 Bit" -qemu-version = "7.1.94" -guest-os = "ESXi 6.5" -guest-arch = "n/a" -description = """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. `.""" -reproduce = "n/a" -additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/141.toml b/gitlab/issues/target_i386/host_missing/accel_missing/141.toml deleted file mode 100644 index f8c9ccb9..00000000 --- a/gitlab/issues/target_i386/host_missing/accel_missing/141.toml +++ /dev/null @@ -1,15 +0,0 @@ -id = 141 -title = "qemu-system-x86_64+gdb: unable to correctly disassemble \"real mode\" (i8086) instructions after attaching to QEMU started with \"-S -s\" options" -state = "opened" -created_at = "2021-05-05T06:56:52.542Z" -closed_at = "n/a" -labels = ["GDB", "Launchpad", "target: i386", "workflow::Needs Info"] -url = "https://gitlab.com/qemu-project/qemu/-/issues/141" -host-os = "n/a" -host-arch = "n/a" -qemu-version = "n/a" -guest-os = "n/a" -guest-arch = "n/a" -description = "n/a" -reproduce = "n/a" -additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/1410.toml b/gitlab/issues/target_i386/host_missing/accel_missing/1410.toml deleted file mode 100644 index 48836c45..00000000 --- a/gitlab/issues/target_i386/host_missing/accel_missing/1410.toml +++ /dev/null @@ -1,22 +0,0 @@ -id = 1410 -title = "system_powerdown only works once" -state = "opened" -created_at = "2023-01-03T13:50:34.074Z" -closed_at = "n/a" -labels = ["ACPI", "target: i386"] -url = "https://gitlab.com/qemu-project/qemu/-/issues/1410" -host-os = "Debian" -host-arch = "x86_64" -qemu-version = "7.2.0" -guest-os = "Windows 10 LTS" -guest-arch = "x86_64" -description = """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.""" -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 = """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/target_i386/host_missing/accel_missing/1437.toml b/gitlab/issues/target_i386/host_missing/accel_missing/1437.toml deleted file mode 100644 index a67ff65b..00000000 --- a/gitlab/issues/target_i386/host_missing/accel_missing/1437.toml +++ /dev/null @@ -1,16 +0,0 @@ -id = 1437 -title = "Nitrux doesn't finish boot process" -state = "closed" -created_at = "2023-01-12T22:39:09.799Z" -closed_at = "2023-01-17T12:40:10.200Z" -labels = ["target: i386"] -url = "https://gitlab.com/qemu-project/qemu/-/issues/1437" -host-os = "Linux Nitrux 2.6.0" -host-arch = "x86" -qemu-version = "n/a" -guest-os = "Linux Nitrux 2.6.0" -guest-arch = "x86" -description = """Boot process doesn't finish -![imagen](/uploads/787a61359bb79ba644a7d99bf021680e/imagen.png)""" -reproduce = """1.Load Nitrux ISO""" -additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/1472.toml b/gitlab/issues/target_i386/host_missing/accel_missing/1472.toml deleted file mode 100644 index e79f7087..00000000 --- a/gitlab/issues/target_i386/host_missing/accel_missing/1472.toml +++ /dev/null @@ -1,15 +0,0 @@ -id = 1472 -title = "Parameter 'sgx-epc.0.node' is unexpected" -state = "closed" -created_at = "2023-02-01T02:39:24.587Z" -closed_at = "2023-02-01T16:49:18.456Z" -labels = ["target: i386", "workflow::Triaged"] -url = "https://gitlab.com/qemu-project/qemu/-/issues/1472" -host-os = "ubuntu22.04" -host-arch = "x86" -qemu-version = "6.2.0" -guest-os = "ubuntu18.04 server" -guest-arch = "n/a" -description = """qemu-system-x86_64: Parameter 'sgx-epc.0.node' is unexpected""" -reproduce = "n/a" -additional = """""" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/1473.toml b/gitlab/issues/target_i386/host_missing/accel_missing/1473.toml deleted file mode 100644 index 28333521..00000000 --- a/gitlab/issues/target_i386/host_missing/accel_missing/1473.toml +++ /dev/null @@ -1,15 +0,0 @@ -id = 1473 -title = "how to run qemu with sgx feature enabled" -state = "closed" -created_at = "2023-02-01T02:47:18.682Z" -closed_at = "2023-02-01T16:49:55.994Z" -labels = ["Documentation", "target: i386", "workflow::Triaged"] -url = "https://gitlab.com/qemu-project/qemu/-/issues/1473" -host-os = "n/a" -host-arch = "n/a" -qemu-version = "n/a" -guest-os = "n/a" -guest-arch = "n/a" -description = "n/a" -reproduce = "n/a" -additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/1476.toml b/gitlab/issues/target_i386/host_missing/accel_missing/1476.toml deleted file mode 100644 index 2596f44c..00000000 --- a/gitlab/issues/target_i386/host_missing/accel_missing/1476.toml +++ /dev/null @@ -1,15 +0,0 @@ -id = 1476 -title = "Support for additional CMOS memory banks" -state = "opened" -created_at = "2023-02-06T06:34:05.891Z" -closed_at = "n/a" -labels = ["kind::Feature Request", "target: i386"] -url = "https://gitlab.com/qemu-project/qemu/-/issues/1476" -host-os = "n/a" -host-arch = "n/a" -qemu-version = "n/a" -guest-os = "n/a" -guest-arch = "n/a" -description = "n/a" -reproduce = "n/a" -additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/1492.toml b/gitlab/issues/target_i386/host_missing/accel_missing/1492.toml deleted file mode 100644 index 5b2f550a..00000000 --- a/gitlab/issues/target_i386/host_missing/accel_missing/1492.toml +++ /dev/null @@ -1,300 +0,0 @@ -id = 1492 -title = "[coredump] [git master] qemu-x86_64 segfaults on ppc64le (4K page size) when trying to run android-studio inside chroot" -state = "opened" -created_at = "2023-02-15T12:01:40.475Z" -closed_at = "n/a" -labels = ["linux-user", "target: i386"] -url = "https://gitlab.com/qemu-project/qemu/-/issues/1492" -host-os = "Gentoo Linux" -host-arch = "ppc64le (4K page size)" -qemu-version = "qemu-x86_64 version 7.2.50 (v7.2.0-1411-gf670b3eec7-dirty)" -guest-os = "Arch Linux" -guest-arch = "x86_64" -description = """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 "$@" -```""" -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 `): 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 = """``` -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 -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: -. -Find the GDB manual and other documentation resources online at: - . - -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\t../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\tin ../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\tin ../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\tin ../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\tin ../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\tin ../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\tin ../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\tin ../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\tin ../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\tin ../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\tin ../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/target_i386/host_missing/accel_missing/1524.toml b/gitlab/issues/target_i386/host_missing/accel_missing/1524.toml deleted file mode 100644 index 991ca276..00000000 --- a/gitlab/issues/target_i386/host_missing/accel_missing/1524.toml +++ /dev/null @@ -1,47 +0,0 @@ -id = 1524 -title = "error while loading state for instance 0x0 of device 'kvm-tpr-opt',load of migration failed: Operation not permitted" -state = "opened" -created_at = "2023-03-01T11:28:12.620Z" -closed_at = "n/a" -labels = ["Migration", "target: i386"] -url = "https://gitlab.com/qemu-project/qemu/-/issues/1524" -host-os = "n/a" -host-arch = "n/a" -qemu-version = "n/a" -guest-os = "centos8" -guest-arch = "x86" -description = """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"""" -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"}}""" -additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/1533.toml b/gitlab/issues/target_i386/host_missing/accel_missing/1533.toml deleted file mode 100644 index de41be25..00000000 --- a/gitlab/issues/target_i386/host_missing/accel_missing/1533.toml +++ /dev/null @@ -1,15 +0,0 @@ -id = 1533 -title = "qemu-i386 should not enable feature LM with named CPU models." -state = "closed" -created_at = "2023-03-06T11:54:17.020Z" -closed_at = "2023-06-16T23:35:12.364Z" -labels = ["Closed::Duplicate", "linux-user", "target: i386"] -url = "https://gitlab.com/qemu-project/qemu/-/issues/1533" -host-os = "n/a" -host-arch = "n/a" -qemu-version = "n/a" -guest-os = "n/a" -guest-arch = "n/a" -description = "n/a" -reproduce = "n/a" -additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/1534.toml b/gitlab/issues/target_i386/host_missing/accel_missing/1534.toml deleted file mode 100644 index a246f98d..00000000 --- a/gitlab/issues/target_i386/host_missing/accel_missing/1534.toml +++ /dev/null @@ -1,15 +0,0 @@ -id = 1534 -title = "usermode emulation warns about features that are system-only (x2apic, tsc-deadline, pcid, invpcid)" -state = "closed" -created_at = "2023-03-06T11:57:27.973Z" -closed_at = "2023-06-29T12:55:22.614Z" -labels = ["linux-user", "target: i386"] -url = "https://gitlab.com/qemu-project/qemu/-/issues/1534" -host-os = "n/a" -host-arch = "n/a" -qemu-version = "n/a" -guest-os = "n/a" -guest-arch = "n/a" -description = "n/a" -reproduce = "n/a" -additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/1570.toml b/gitlab/issues/target_i386/host_missing/accel_missing/1570.toml deleted file mode 100644 index 8d0119a2..00000000 --- a/gitlab/issues/target_i386/host_missing/accel_missing/1570.toml +++ /dev/null @@ -1,71 +0,0 @@ -id = 1570 -title = "Incorrect memory handling when booting redox" -state = "closed" -created_at = "2023-04-01T07:43:36.451Z" -closed_at = "2024-04-02T20:52:25.232Z" -labels = ["target: i386"] -url = "https://gitlab.com/qemu-project/qemu/-/issues/1570" -host-os = "MacOS 12." -host-arch = "x86_64" -qemu-version = "QEMU emulator version 7.2.92 (v8.0.0-rc2-16-gf00506aeca-dirty)" -guest-os = "[Redox OS](https://www.redox-os.org/)" -guest-arch = "x86_64" -description = """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)""" -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 = """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/target_i386/host_missing/accel_missing/1628.toml b/gitlab/issues/target_i386/host_missing/accel_missing/1628.toml deleted file mode 100644 index aa7b17c0..00000000 --- a/gitlab/issues/target_i386/host_missing/accel_missing/1628.toml +++ /dev/null @@ -1,138 +0,0 @@ -id = 1628 -title = "windows 10 display scale will cause an exception" -state = "opened" -created_at = "2023-04-28T06:30:53.137Z" -closed_at = "n/a" -labels = ["GUI", "guest: Windows", "target: i386", "workflow::Patch available"] -url = "https://gitlab.com/qemu-project/qemu/-/issues/1628" -host-os = "centos" -host-arch = "x86" -qemu-version = "7.2.0" -guest-os = "Windows 10 21H2" -guest-arch = "x86" -description = """windows dispaly sacle 150% or higher, windows system will exception""" -reproduce = """1. windows dispaly sacle 150%""" -additional = """- 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/target_i386/host_missing/accel_missing/1648.toml b/gitlab/issues/target_i386/host_missing/accel_missing/1648.toml deleted file mode 100644 index 427b6529..00000000 --- a/gitlab/issues/target_i386/host_missing/accel_missing/1648.toml +++ /dev/null @@ -1,70 +0,0 @@ -id = 1648 -title = "linux-user: incorrect alignment of sigframe::pretcode & rt_sigframe::pretcode cause crash" -state = "closed" -created_at = "2023-05-12T15:26:57.371Z" -closed_at = "2024-05-27T02:33:45.506Z" -labels = ["Closed::Fixed", "kind::Bug", "linux-user", "target: i386"] -url = "https://gitlab.com/qemu-project/qemu/-/issues/1648" -host-os = "Windows 11" -host-arch = "x86_64" -qemu-version = "8.0.0" -guest-os = "n/a" -guest-arch = "n/a" -description = """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.""" -reproduce = "n/a" -additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/1762.toml b/gitlab/issues/target_i386/host_missing/accel_missing/1762.toml deleted file mode 100644 index cbbc5c48..00000000 --- a/gitlab/issues/target_i386/host_missing/accel_missing/1762.toml +++ /dev/null @@ -1,95 +0,0 @@ -id = 1762 -title = "Linux RTC issues possibly with RTC_UIE_ON, RTC_UIE_OFF" -state = "opened" -created_at = "2023-07-14T17:27:02.151Z" -closed_at = "n/a" -labels = ["target: i386"] -url = "https://gitlab.com/qemu-project/qemu/-/issues/1762" -host-os = "Slackware64-current, Arch Linux, Linux Mint 21.1" -host-arch = "x86_64" -qemu-version = "n/a" -guest-os = "Slackware64-current, Arch Linux, Linux Mint 21.1" -guest-arch = "x86_64" -description = """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 -#""" -reproduce = "n/a" -additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/189.toml b/gitlab/issues/target_i386/host_missing/accel_missing/189.toml deleted file mode 100644 index b9c30d67..00000000 --- a/gitlab/issues/target_i386/host_missing/accel_missing/189.toml +++ /dev/null @@ -1,15 +0,0 @@ -id = 189 -title = "Intel GVT-g works in X11, segfaults in wayland" -state = "closed" -created_at = "2021-05-06T08:58:19.132Z" -closed_at = "2025-01-13T17:52:32.283Z" -labels = ["Launchpad", "VFIO", "device:graphics", "target: i386"] -url = "https://gitlab.com/qemu-project/qemu/-/issues/189" -host-os = "n/a" -host-arch = "n/a" -qemu-version = "n/a" -guest-os = "n/a" -guest-arch = "n/a" -description = "n/a" -reproduce = "n/a" -additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/191.toml b/gitlab/issues/target_i386/host_missing/accel_missing/191.toml deleted file mode 100644 index 2828ffb8..00000000 --- a/gitlab/issues/target_i386/host_missing/accel_missing/191.toml +++ /dev/null @@ -1,15 +0,0 @@ -id = 191 -title = "qemu64 CPU model is incorrect" -state = "closed" -created_at = "2021-05-06T08:58:45.366Z" -closed_at = "2021-06-02T10:41:58.632Z" -labels = ["Launchpad", "target: i386"] -url = "https://gitlab.com/qemu-project/qemu/-/issues/191" -host-os = "n/a" -host-arch = "n/a" -qemu-version = "n/a" -guest-os = "n/a" -guest-arch = "n/a" -description = "n/a" -reproduce = "n/a" -additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/1919.toml b/gitlab/issues/target_i386/host_missing/accel_missing/1919.toml deleted file mode 100644 index 88fbac4b..00000000 --- a/gitlab/issues/target_i386/host_missing/accel_missing/1919.toml +++ /dev/null @@ -1,28 +0,0 @@ -id = 1919 -title = "UEFI SecureCode hangs on MacOs - 8.1.1 / MacOS Ventura" -state = "closed" -created_at = "2023-10-03T11:58:14.876Z" -closed_at = "2023-10-18T10:14:26.000Z" -labels = ["hostos: macOS", "target: i386"] -url = "https://gitlab.com/qemu-project/qemu/-/issues/1919" -host-os = "MacOS ventura 13.6" -host-arch = "x86_64`, `ARM` - problem tested on devices with Intel and Apple silicon" -qemu-version = "QEMU emulator version 8.1.1" -guest-os = "None - hangs during UEFI bios load" -guest-arch = "x86_64" -description = """Unable to load edk2 secure boot UEFI code. Non-secure edk2 bios works fine, but secure one hangs during load.""" -reproduce = """1. Run mentioned command - it should display OVMF logo - but it hangs""" -additional = """* 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/target_i386/host_missing/accel_missing/192.toml b/gitlab/issues/target_i386/host_missing/accel_missing/192.toml deleted file mode 100644 index 6ac9f791..00000000 --- a/gitlab/issues/target_i386/host_missing/accel_missing/192.toml +++ /dev/null @@ -1,15 +0,0 @@ -id = 192 -title = "xv6 Bootloop" -state = "opened" -created_at = "2021-05-06T08:58:57.762Z" -closed_at = "n/a" -labels = ["Launchpad", "target: i386"] -url = "https://gitlab.com/qemu-project/qemu/-/issues/192" -host-os = "n/a" -host-arch = "n/a" -qemu-version = "n/a" -guest-os = "n/a" -guest-arch = "n/a" -description = "n/a" -reproduce = "n/a" -additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/1932.toml b/gitlab/issues/target_i386/host_missing/accel_missing/1932.toml deleted file mode 100644 index ee5b6772..00000000 --- a/gitlab/issues/target_i386/host_missing/accel_missing/1932.toml +++ /dev/null @@ -1,22 +0,0 @@ -id = 1932 -title = "Broken grab on hover setting" -state = "opened" -created_at = "2023-10-11T13:53:03.500Z" -closed_at = "n/a" -labels = ["GUI", "device:input", "target: i386"] -url = "https://gitlab.com/qemu-project/qemu/-/issues/1932" -host-os = "Arch Linux" -host-arch = "x86_64" -qemu-version = "8.1.1" -guest-os = "Kali Linux" -guest-arch = "x86_64" -description = """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?""" -reproduce = "n/a" -additional = """NIL""" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/1947.toml b/gitlab/issues/target_i386/host_missing/accel_missing/1947.toml deleted file mode 100644 index db1fdb2f..00000000 --- a/gitlab/issues/target_i386/host_missing/accel_missing/1947.toml +++ /dev/null @@ -1,28 +0,0 @@ -id = 1947 -title = "ACPI (Stop code 0x000000A5) BSOD During Windows XP Professional x64 Edition Setup" -state = "opened" -created_at = "2023-10-16T20:46:57.066Z" -closed_at = "n/a" -labels = ["ACPI", "target: i386"] -url = "https://gitlab.com/qemu-project/qemu/-/issues/1947" -host-os = "Linux Mint 21.1 Cinnamon" -host-arch = "x86_64" -qemu-version = "8.1.1" -guest-os = "Windows XP Professional x64 Edition SP2" -guest-arch = "x86_64" -description = """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) -```""" -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 = """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/target_i386/host_missing/accel_missing/1952.toml b/gitlab/issues/target_i386/host_missing/accel_missing/1952.toml deleted file mode 100644 index 2e946095..00000000 --- a/gitlab/issues/target_i386/host_missing/accel_missing/1952.toml +++ /dev/null @@ -1,104 +0,0 @@ -id = 1952 -title = "elf-linux-user: segfault caused by invalid loaddr extracted by the ELF loader" -state = "closed" -created_at = "2023-10-19T17:05:29.704Z" -closed_at = "2023-11-21T21:39:18.528Z" -labels = ["Closed::Fixed", "linux-user", "target: i386"] -url = "https://gitlab.com/qemu-project/qemu/-/issues/1952" -host-os = "NixOS 22.05" -host-arch = "x86_64`" -qemu-version = "latest master" -guest-os = "NixOS 22.05" -guest-arch = "x86_64`" -description = """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) -```""" -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 = """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/target_i386/host_missing/accel_missing/1956.toml b/gitlab/issues/target_i386/host_missing/accel_missing/1956.toml deleted file mode 100644 index 7bc25d74..00000000 --- a/gitlab/issues/target_i386/host_missing/accel_missing/1956.toml +++ /dev/null @@ -1,15 +0,0 @@ -id = 1956 -title = "[x86,microvm] Update microvm documentation with ACPI option" -state = "opened" -created_at = "2023-10-24T13:25:11.937Z" -closed_at = "n/a" -labels = ["ACPI", "Documentation", "target: i386"] -url = "https://gitlab.com/qemu-project/qemu/-/issues/1956" -host-os = "n/a" -host-arch = "n/a" -qemu-version = "n/a" -guest-os = "n/a" -guest-arch = "n/a" -description = "n/a" -reproduce = "n/a" -additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/1986.toml b/gitlab/issues/target_i386/host_missing/accel_missing/1986.toml deleted file mode 100644 index 3e6512d9..00000000 --- a/gitlab/issues/target_i386/host_missing/accel_missing/1986.toml +++ /dev/null @@ -1,22 +0,0 @@ -id = 1986 -title = "windows install fails with error 0x80070001" -state = "opened" -created_at = "2023-11-18T08:16:00.014Z" -closed_at = "n/a" -labels = ["target: i386"] -url = "https://gitlab.com/qemu-project/qemu/-/issues/1986" -host-os = "Gentoo" -host-arch = "x86_64" -qemu-version = "8.1.2" -guest-os = "Windows 11 (22H2_x64v1, Win11_23H2_x64)" -guest-arch = "x86_64" -description = """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.""" -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 = """[save.xml.txt](/uploads/0b7eb56d5fe00ff11341483d3d47ebed/save.xml.txt) -[qemu.cmd.txt](/uploads/b948eee1a95321d11136b96352caace0/qemu.cmd.txt)""" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/1998.toml b/gitlab/issues/target_i386/host_missing/accel_missing/1998.toml deleted file mode 100644 index b89e94f3..00000000 --- a/gitlab/issues/target_i386/host_missing/accel_missing/1998.toml +++ /dev/null @@ -1,35 +0,0 @@ -id = 1998 -title = "acpihp does not work with some common guest kernels" -state = "opened" -created_at = "2023-11-22T19:32:07.015Z" -closed_at = "n/a" -labels = ["ACPI", "target: i386"] -url = "https://gitlab.com/qemu-project/qemu/-/issues/1998" -host-os = "Fedora Linux 38" -host-arch = "x86 64" -qemu-version = "QEMU emulator version 7.2.6 (qemu-7.2.6-1.fc38)" -guest-os = "Fedora 39" -guest-arch = "x86 64" -description = """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 -```""" -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 = """""" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/2008.toml b/gitlab/issues/target_i386/host_missing/accel_missing/2008.toml deleted file mode 100644 index d2c4f47d..00000000 --- a/gitlab/issues/target_i386/host_missing/accel_missing/2008.toml +++ /dev/null @@ -1,22 +0,0 @@ -id = 2008 -title = "querying smbios type=1 UUID in Windows not possible when using SMBIOS 64 bit entry" -state = "closed" -created_at = "2023-11-28T14:44:32.801Z" -closed_at = "2024-03-18T10:34:30.833Z" -labels = ["guest: Windows", "target: i386"] -url = "https://gitlab.com/qemu-project/qemu/-/issues/2008" -host-os = "Proxmox VE 8 (but using upstream build of QEMU)" -host-arch = "x86" -qemu-version = "QEMU emulator version 8.1.0 (v8.1.0)" -guest-os = "Windows Server 2022 (also affects Windows Server 2019 and Windows 10)" -guest-arch = "x86" -description = """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.""" -reproduce = "n/a" -additional = """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/target_i386/host_missing/accel_missing/2020.toml b/gitlab/issues/target_i386/host_missing/accel_missing/2020.toml deleted file mode 100644 index b2656826..00000000 --- a/gitlab/issues/target_i386/host_missing/accel_missing/2020.toml +++ /dev/null @@ -1,21 +0,0 @@ -id = 2020 -title = "qemu-system-x86_64: ../../hw/rtc/mc146818rtc.c:203: periodic_timer_update: Assertion `lost_clock >= 0' failed." -state = "opened" -created_at = "2023-12-06T11:58:15.102Z" -closed_at = "n/a" -labels = ["kind::Bug", "target: i386", "workflow::Triaged"] -url = "https://gitlab.com/qemu-project/qemu/-/issues/2020" -host-os = "Debian 12.2" -host-arch = "x86_64" -qemu-version = "QEMU emulator version 7.2.5 (Debian 1:7.2+dfsg-7+deb12u2)" -guest-os = "Windows Server 2016" -guest-arch = "x86_64" -description = """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 -```""" -reproduce = """1. N/A - -/label ~"kind::Bug"""" -additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/2064.toml b/gitlab/issues/target_i386/host_missing/accel_missing/2064.toml deleted file mode 100644 index e45eef08..00000000 --- a/gitlab/issues/target_i386/host_missing/accel_missing/2064.toml +++ /dev/null @@ -1,20 +0,0 @@ -id = 2064 -title = "QEMU v8.2.0-rc4 and above will not take SMI" -state = "closed" -created_at = "2024-01-02T21:46:05.776Z" -closed_at = "2024-02-17T07:54:07.106Z" -labels = ["target: i386"] -url = "https://gitlab.com/qemu-project/qemu/-/issues/2064" -host-os = "Windows 11 and WSL" -host-arch = "x64" -qemu-version = "v8.2.0-rc4" -guest-os = "N/A, still in UEFI firmware" -guest-arch = "x86" -description = """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.""" -reproduce = """1. Launch once booting UEFI firmware, and the system will get stuck at the SMM base relocation logic.""" -additional = """I verified that after fixing the 2 issues mentioned above, the SMI can be correctly invoked at desired location.""" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/2070.toml b/gitlab/issues/target_i386/host_missing/accel_missing/2070.toml deleted file mode 100644 index 292fc49f..00000000 --- a/gitlab/issues/target_i386/host_missing/accel_missing/2070.toml +++ /dev/null @@ -1,17 +0,0 @@ -id = 2070 -title = "TCG acceleration + EDK2 + Secure Boot hangs on boot since qemu 8.2" -state = "closed" -created_at = "2024-01-04T14:40:25.218Z" -closed_at = "2024-01-20T15:04:15.194Z" -labels = ["target: i386", "workflow::Patch available"] -url = "https://gitlab.com/qemu-project/qemu/-/issues/2070" -host-os = "Arch Linux" -host-arch = "x86-64" -qemu-version = "qemu-8.2" -guest-os = "Fedora" -guest-arch = "x86" -description = """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.""" -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 = """""" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/2079.toml b/gitlab/issues/target_i386/host_missing/accel_missing/2079.toml deleted file mode 100644 index 3fc7e2b9..00000000 --- a/gitlab/issues/target_i386/host_missing/accel_missing/2079.toml +++ /dev/null @@ -1,15 +0,0 @@ -id = 2079 -title = "flaky test: tcg tests, cross-i686-tci runner, \"run-memory\" test" -state = "closed" -created_at = "2024-01-08T11:39:45.375Z" -closed_at = "2024-03-11T14:45:56.595Z" -labels = ["CI", "Tests", "flaky-ci", "kind::Bug", "target: i386", "workflow::Patch available"] -url = "https://gitlab.com/qemu-project/qemu/-/issues/2079" -host-os = "n/a" -host-arch = "n/a" -qemu-version = "n/a" -guest-os = "n/a" -guest-arch = "n/a" -description = "n/a" -reproduce = "n/a" -additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/2218.toml b/gitlab/issues/target_i386/host_missing/accel_missing/2218.toml deleted file mode 100644 index c52750f7..00000000 --- a/gitlab/issues/target_i386/host_missing/accel_missing/2218.toml +++ /dev/null @@ -1,20 +0,0 @@ -id = 2218 -title = "MIDI playback issue on Windows 98 / 2000 / XP guest" -state = "opened" -created_at = "2024-03-10T00:13:10.649Z" -closed_at = "n/a" -labels = ["Audio", "target: i386"] -url = "https://gitlab.com/qemu-project/qemu/-/issues/2218" -host-os = "Windows 11 (23H2)" -host-arch = "x64" -qemu-version = "8.2.0" -guest-os = "Windows 98 SE, Windows 2000 SP4, Windows XP SP3" -guest-arch = "x86" -description = """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.""" -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 = """""" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/223.toml b/gitlab/issues/target_i386/host_missing/accel_missing/223.toml deleted file mode 100644 index 0ff3c7e5..00000000 --- a/gitlab/issues/target_i386/host_missing/accel_missing/223.toml +++ /dev/null @@ -1,15 +0,0 @@ -id = 223 -title = "guest migration 100% cpu freeze bug" -state = "closed" -created_at = "2021-05-09T15:10:54.510Z" -closed_at = "2024-03-14T15:55:21.758Z" -labels = ["Launchpad", "Migration", "target: i386"] -url = "https://gitlab.com/qemu-project/qemu/-/issues/223" -host-os = "n/a" -host-arch = "n/a" -qemu-version = "n/a" -guest-os = "n/a" -guest-arch = "n/a" -description = "n/a" -reproduce = "n/a" -additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/2244.toml b/gitlab/issues/target_i386/host_missing/accel_missing/2244.toml deleted file mode 100644 index c87471a9..00000000 --- a/gitlab/issues/target_i386/host_missing/accel_missing/2244.toml +++ /dev/null @@ -1,54 +0,0 @@ -id = 2244 -title = "Regression in 8.2.90: cpu_physical_memory_snapshot_get_dirty: assertion failed" -state = "closed" -created_at = "2024-03-24T08:59:26.554Z" -closed_at = "2024-04-03T16:45:37.265Z" -labels = ["device:graphics", "kind::Bug", "target: i386", "workflow::Patch available"] -url = "https://gitlab.com/qemu-project/qemu/-/issues/2244" -host-os = "Debian Bookworm (and Windows 10 22H2, too)" -host-arch = "x86_64" -qemu-version = "8.2.90 - commit determined by git bisect: 973a724eb006f674301a0c45f34b3c08dee0fe49" -guest-os = "ETH Native Oberon" -guest-arch = "i386" -description = """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) -```""" -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 = """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 -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 -```""" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/2263.toml b/gitlab/issues/target_i386/host_missing/accel_missing/2263.toml deleted file mode 100644 index 215adbc8..00000000 --- a/gitlab/issues/target_i386/host_missing/accel_missing/2263.toml +++ /dev/null @@ -1,36 +0,0 @@ -id = 2263 -title = "guest panics when attempting to perform loadvm operation on x86_64 platform with kvm_intel ept=0" -state = "opened" -created_at = "2024-04-02T11:41:11.302Z" -closed_at = "n/a" -labels = ["target: i386"] -url = "https://gitlab.com/qemu-project/qemu/-/issues/2263" -host-os = "Ubuntu 22.04.3 LTS" -host-arch = "x86" -qemu-version = "QEMU emulator version 8.2.50 (v8.2.0-1871-g158a054c4d-dirty)" -guest-os = "Ubuntu 22.04.3 LTS" -guest-arch = "x86" -description = """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`.""" -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 = """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/target_i386/host_missing/accel_missing/2266.toml b/gitlab/issues/target_i386/host_missing/accel_missing/2266.toml deleted file mode 100644 index aad4513b..00000000 --- a/gitlab/issues/target_i386/host_missing/accel_missing/2266.toml +++ /dev/null @@ -1,77 +0,0 @@ -id = 2266 -title = "qemu-system-x86_64: stuck on watchpoint hit" -state = "opened" -created_at = "2024-04-04T10:01:04.687Z" -closed_at = "n/a" -labels = ["target: i386"] -url = "https://gitlab.com/qemu-project/qemu/-/issues/2266" -host-os = "Ubuntu 2022.04" -host-arch = "x86" -qemu-version = "8.2.92 (v9.0.0-rc2-7-g786fd793b8" -guest-os = "Yocto current build" -guest-arch = "x86" -description = """""" -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 = """* 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; -\tl1 = 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 -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: -. -Find the GDB manual and other documentation resources online at: - . - -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/target_i386/host_missing/accel_missing/2270.toml b/gitlab/issues/target_i386/host_missing/accel_missing/2270.toml deleted file mode 100644 index 8fe1a826..00000000 --- a/gitlab/issues/target_i386/host_missing/accel_missing/2270.toml +++ /dev/null @@ -1,15 +0,0 @@ -id = 2270 -title = "CPU topology recognition for Ryzen 9 7950X3D" -state = "opened" -created_at = "2024-04-06T13:45:12.995Z" -closed_at = "n/a" -labels = ["target: i386"] -url = "https://gitlab.com/qemu-project/qemu/-/issues/2270" -host-os = "Debian Trixie" -host-arch = "x86" -qemu-version = "QEMU emulator version 8.2.2 (Debian 1:8.2.2+ds-2+b1)" -guest-os = "Windows 11 22H2" -guest-arch = "x86" -description = "n/a" -reproduce = "n/a" -additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/2320.toml b/gitlab/issues/target_i386/host_missing/accel_missing/2320.toml deleted file mode 100644 index ecfaf2b3..00000000 --- a/gitlab/issues/target_i386/host_missing/accel_missing/2320.toml +++ /dev/null @@ -1,15 +0,0 @@ -id = 2320 -title = "-Wchar-subscripts warnings in target/i386/tcg/decode-new.c.inc" -state = "opened" -created_at = "2024-05-01T11:02:22.629Z" -closed_at = "n/a" -labels = ["target: i386"] -url = "https://gitlab.com/qemu-project/qemu/-/issues/2320" -host-os = "n/a" -host-arch = "n/a" -qemu-version = "n/a" -guest-os = "n/a" -guest-arch = "n/a" -description = "n/a" -reproduce = "n/a" -additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/2330.toml b/gitlab/issues/target_i386/host_missing/accel_missing/2330.toml deleted file mode 100644 index 80672b10..00000000 --- a/gitlab/issues/target_i386/host_missing/accel_missing/2330.toml +++ /dev/null @@ -1,81 +0,0 @@ -id = 2330 -title = "acpi-erst: divide by zero in make_erst_storage_header()" -state = "opened" -created_at = "2024-05-07T05:17:35.268Z" -closed_at = "n/a" -labels = ["ACPI", "target: i386"] -url = "https://gitlab.com/qemu-project/qemu/-/issues/2330" -host-os = "Ubuntu" -host-arch = "x86" -qemu-version = "9.0.50" -guest-os = "n/a" -guest-arch = "n/a" -description = """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; - } -```""" -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 = """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/target_i386/host_missing/accel_missing/2334.toml b/gitlab/issues/target_i386/host_missing/accel_missing/2334.toml deleted file mode 100644 index 0c05bca7..00000000 --- a/gitlab/issues/target_i386/host_missing/accel_missing/2334.toml +++ /dev/null @@ -1,264 +0,0 @@ -id = 2334 -title = "[9.0.0] qemu breaks mac os vm" -state = "closed" -created_at = "2024-05-08T07:31:09.954Z" -closed_at = "2024-11-10T07:57:41.796Z" -labels = ["target: i386"] -url = "https://gitlab.com/qemu-project/qemu/-/issues/2334" -host-os = "Manjaro kernel 5.15.158-1" -host-arch = "x86_64" -qemu-version = "9.0.0-1" -guest-os = "Mac OS Monterey 12.7.4" -guest-arch = "x86_64" -description = """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: - -``` - - Monterey - 33554432 - 33554432 - - - - 32 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 2 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - hvm - /opt/macos/AUDK_CODE.fd - /opt/macos/AUDK_VARS.fd - - - - - - - - - - - - - - - destroy - restart - restart - - /usr/bin/qemu-system-x86_64 - - - - -
- - - - -
- - - - -
- - - - -
- - -
- - -
- - - -
- - -
- - - - - -
- - - - - -
- - - - - - - - - - - -
- - - -