clean up repository

4 files changed, 0 insertions, 123 deletions

diff --git a/gitlab/issues_text/target_i386/host_x86/accel_missing/1910 b/gitlab/issues_text/target_i386/host_x86/accel_missing/1910
deleted file mode 100644
index 6181dcd77..000000000
--- a/gitlab/issues_text/target_i386/host_x86/accel_missing/1910
+++ /dev/null
@@ -1,62 +0,0 @@
-Signal handlers in x86_64 userspace have wrongly aligned stack
-Description of problem:
-Various applications crash in signal handlers due to `movaps` getting a misaligned stack address. For some reason this is reported as a NULL deref, but `gdb` clearly shows the true cause.
-
-```plaintext
-> qemu-x86_64 /usr/bin/ruby -e '`true`'
--e:1: [BUG] Segmentation fault at 0x0000000000000000
-ruby 3.2.2 (2023-03-30 revision e51014f9c0) [x86_64-linux-gnu]
-
--- Control frame information -----------------------------------------------
-c:0003 p:---- s:0011 e:000010 CFUNC  :`
-c:0002 p:0005 s:0006 e:000005 EVAL   -e:1 [FINISH]
-c:0001 p:0000 s:0003 E:0015b0 DUMMY  [FINISH]
-
--- Ruby level backtrace information ----------------------------------------
--e:1:in `<main>'
--e:1:in ``'
-
--- Machine register context ------------------------------------------------
- RIP: 0x00002aaaab50f98a RBP: 0x00002aaaabb136b8 RSP: 0x00002aaaab2a9c98
- RAX: 0x0000000000000000 RBX: 0x0000000000004946 RCX: 0x0000000000000000
- RDX: 0x00002aaaab2a9c98 RDI: 0x000000000caf0000 RSI: 0x0000000000000000
-  R8: 0x00002aaaab2aaa50  R9: 0x0000000000000050 R10: 0x0000000000000008
- R11: 0x0000000000000000 R12: 0x0000000000000002 R13: 0x0000000000007310
- R14: 0x0000000000005e10 R15: 0x00002aaab0537f20 EFL: 0x0000000000000246
-
--- C level backtrace information -------------------------------------------
-```
-
-```plaintext
-(gdb) x/i $pc
-=> 0x2aaaab50f98a:      movaps %xmm0,(%rsp)
-(gdb) p/x $rsp
-$3 = 0x2aaaab2a9998
-```
-Steps to reproduce:
-1. ```qemu-x86_64 /usr/bin/ruby -e '`true`'```
-Additional information:
-The x86_64 psABI says:
-
-> the value (%rsp − 8) is always a multiple of 16 when control is transferred to the function entry point.
-
-However, when QEMU jumps to the signal handler, $rsp is aligned to 16B, i.e. ends in `0x..0`.
-
-The relevant kernel code:
-
-https://elixir.bootlin.com/linux/v6.5.5/source/arch/x86/kernel/signal.c#L123
-
-```plaintext
-	sp -= frame_size;
-
-	if (ia32_frame)
-		/*
-		 * Align the stack pointer according to the i386 ABI,
-		 * i.e. so that on function entry ((sp + 4) & 15) == 0.
-		 */
-		sp = ((sp + 4) & -FRAME_ALIGNMENT) - 4;
-	else
-		sp = round_down(sp, FRAME_ALIGNMENT) - 8;
-```
-
-CC @lvivier @bonzini @rth7680
diff --git a/gitlab/issues_text/target_i386/host_x86/accel_missing/1926 b/gitlab/issues_text/target_i386/host_x86/accel_missing/1926
deleted file mode 100644
index 58cf48470..000000000
--- a/gitlab/issues_text/target_i386/host_x86/accel_missing/1926
+++ /dev/null
@@ -1,24 +0,0 @@
-Spice: handle_dev_destroy_surface_wait: condition `msg->surface_id == 0' failed (DoS via assert failure)
-Description of problem:
-Assert failure in libspice-server was found during fuzzing qxl-vga device.
-
-```plaintext
-qemu-system-x86_64: Spice: ../server/red-worker.cpp:367:handle_dev_destroy_surface_wait: condition `msg->surface_id == 0' failed
-Аварийный останов
-```
-Steps to reproduce:
-1. This bug can be reroduced with 
-
-   ```plaintext
-   cat << EOF | ./qemu-system-x86_64 -display none -machine accel=qtest, -m 512M -M \
-   pc -nodefaults -vga qxl -qtest stdio
-   outl 0xcf8 0x8000101c
-   outl 0xcfc 0xc000
-   outl 0xcf8 0x80001004
-   outw 0xcfc 0x01
-   outl 0xc00b 0x01000000
-   EOF
-   ```
-2. This bug is in another place from https://gitlab.com/qemu-project/qemu/-/issues/1829, please pay attention to it. It has to be solved, because it interferes with further fuzzing process
-Additional information:
-As I mentioned, I really need this bug to be solved, because fuzzing qxl-vga device gets less efficient. I suggested to report it here, not in spice-server, because this bug can be on the QEMU side.
diff --git a/gitlab/issues_text/target_i386/host_x86/accel_missing/1946 b/gitlab/issues_text/target_i386/host_x86/accel_missing/1946
deleted file mode 100644
index 0c912f0b1..000000000
--- a/gitlab/issues_text/target_i386/host_x86/accel_missing/1946
+++ /dev/null
@@ -1,28 +0,0 @@
-High CPU Load after QEMU 8.1.1
-Description of problem:
-Since the update there is a massive CPU load and this affects the CPU load of the router.
-The VMs are partially for about 3min sporadically not accessible.
-The VMs themselves were not adjusted and I have in the console.
-
-Using the VMM, I was able to see the message recorded below.
-
-`watchdog:_ BUG: soft lockup - CPU#0 stuck for 21s! [swapper/0:0]`
-
-I will also add some data like a XML file of a VM.
-Additional information:
-![webproxy](/uploads/5df86f9adfdd257ca2f43697603567c3/webproxy.PNG)
-[webproxy.log](/uploads/1d428f4c59b2397b9343a62dd8c4bce2/webproxy.log)
-
-[webproxy.xml](/uploads/04221c88956c49d76b4896dd8f6fd1f0/webproxy.xml)
-[Host_Kernel.log](/uploads/f145bf599bf2003b89c17daaabb07143/Host_Kernel.log)
-
-Unfortunately I can't revert to the old QEMU version in the router OS but in the current state all my VM are not really 100% usable anymore.
-
-I would be very grateful if you could take a look at my case.
-
-many thanks in advance.
-
-
-
-
-Paul
diff --git a/gitlab/issues_text/target_i386/host_x86/accel_missing/2608 b/gitlab/issues_text/target_i386/host_x86/accel_missing/2608
deleted file mode 100644
index 4850dc582..000000000
--- a/gitlab/issues_text/target_i386/host_x86/accel_missing/2608
+++ /dev/null
@@ -1,9 +0,0 @@
-Black screen in Windows XP
-Description of problem:
-When starting the installation of Windows XP (or Windows 2003) the screen in VNC stays black while the installer is in text-mode. During the second half of the installation, where it switches to graphical GUI, the display becomes visible again.
-
-This problem never happened on 9.0.1 and below, so is a regression in 9.1.0
-Steps to reproduce:
-1. Start the Windows XP installer
-2. Connect to VNC
-3. Screen stays black