gitlab scraper: download in toml and text format

9 files changed, 130 insertions, 0 deletions

diff --git a/gitlab/issues_text/target_missing/host_missing/accel_HVF/1011 b/gitlab/issues_text/target_missing/host_missing/accel_HVF/1011
new file mode 100644
index 000000000..4307c03df
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_HVF/1011
@@ -0,0 +1,21 @@
+hvf: RDTSCP capability not passed to guests
+Description of problem:
+
+Steps to reproduce:
+1. Run:
+wget https://dl-cdn.alpinelinux.org/alpine/v3.15/releases/x86/alpine-standard-3.15.4-x86.iso
+./qemu-system-x86_64 -cpu host,+rdtscp -machine q35,accel=hvf -m 512 -cdrom ./alpine-standard-3.15.4-x86.iso
+
+2. login as "root"
+3. type
+
+cat /etc/cpuinfo | grep rdtscp
+
+Expected result: cpu flag lines including rdtscp
+Actual result: empty, with:
+
+warning: host doesn't support requested feature: CPUID.80000001H:EDX.rdtscp [bit 27]
+Additional information:
+This patch apparently resolves the issue according to my tests:
+
+https://lore.kernel.org/qemu-devel/20211101054836.21471-1-dirty@apple.com/
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_HVF/1091 b/gitlab/issues_text/target_missing/host_missing/accel_HVF/1091
new file mode 100644
index 000000000..fb807aafd
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_HVF/1091
@@ -0,0 +1,13 @@
+qemu-system-x86_64 hard crashes when using `--accel hvf` on intel Mac
+Description of problem:
+The QEMU process hard crashes after a few minutes. The only message is:
+
+```
+vmx_write_mem: mmu_gva_to_gpa ffff990489fa0000 failed
+```
+Steps to reproduce:
+1. Run QEMU with the above commandline
+2. Do something to keep the VM busy - running `git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git` reliably crashes it for me
+3. Wait a 3-5 minutes
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_HVF/1299 b/gitlab/issues_text/target_missing/host_missing/accel_HVF/1299
new file mode 100644
index 000000000..8c7d34bac
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_HVF/1299
@@ -0,0 +1,24 @@
+User networking with an SMB Share while not running as root
+Description of problem:
+When attempting to write a file to the qemu share, Samba always responds with NT_STATUS_ACCESS_DENIED.
+
+This only happens on the MacOS version of Samba, on Linux it appears to work without issues for now.
+Steps to reproduce:
+1. Start a VM with a SMB share attached to it
+2. Create a test file to upload `touch test-file.txt`
+3. Upload the test file `smbclient //10.0.2.4/qemu -c 'put test-file.txt'
+Additional information:
+QEMU has been using Samba for it's SMB shares for quite some time now.
+But in the 4.17.x release a bug has appeared in the MacOS Build of Samba.
+
+I've filed a bug with Samba, and suggested a fix for it.
+https://bugzilla.samba.org/show_bug.cgi?id=15215
+
+The origin of the bug lies in the fact that when running SMBD as a non-root user, a function sets `errno` unexpectedly.
+But after discussing this with Samba, they concluded that running smbd as an un-privileged user is not a supported use case.
+
+Whilst this is not a QEMU bug per se, it is caused by the fact that QEMU is running smbd in an unsupported manner.
+
+As a side note, on Linux this bug does not appear to exist as of yet.
+The Linux version of `unbecome_root` doesn't seem to set `errno`. (tested on a recent ArchLinux install).
+But I think this depends on the LibC implementation of setuid/seteuid/setreuid/etc. so I can't say it won't happen in the future, or with a different LibC implementation.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_HVF/1364 b/gitlab/issues_text/target_missing/host_missing/accel_HVF/1364
new file mode 100644
index 000000000..77ce3808b
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_HVF/1364
@@ -0,0 +1,15 @@
+Support vmnet networking without elevated permissions
+Additional information:
+Here is a command, that doesn't work when running as normal user:
+```bash
+$ qemu-system-aarch64 \
+    -device virtio-net-pci,netdev=net0 \
+    -netdev vmnet-bridged,id=net0,ifname=en0 \
+    -machine virt
+```
+It fails with:
+```
+qemu-system-aarch64: -netdev vmnet-bridged,id=net0,ifname=en0: cannot create vmnet interface: general failure (possibly not enough privileges)
+```
+
+When running the same command using elevated permissions (i.e. via `sudo`), it works without any issue.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_HVF/1571 b/gitlab/issues_text/target_missing/host_missing/accel_HVF/1571
new file mode 100644
index 000000000..2a70dcafa
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_HVF/1571
@@ -0,0 +1,12 @@
+accel/hvf: Instance size not properly declared
+Description of problem:
+In [`include/sysemu/hvf.h`](https://gitlab.com/qemu-project/qemu/-/blob/master/include/sysemu/hvf.h#L36), `HVFState` is declared to have the QOM type `TYPE_HVF_ACCEL`;
+However, when the type is registered, proper `instance_size` for it was [not declared](https://gitlab.com/qemu-project/qemu/-/blob/master/accel/hvf/hvf-accel-ops.c#L351).
+
+As a result, a bad workaround was introduced. That is, when [`hvf_accel_init`](https://gitlab.com/qemu-project/qemu/-/blob/master/accel/hvf/hvf-accel-ops.c#L329) is called from [`accel_init_machine`](https://gitlab.com/qemu-project/qemu/-/blob/master/accel/accel-softmmu.c#L33), an new instance of `HVFState` is allocated while we should have used the pre-allocated instance in `ms->accelerator` similar to [what KVM does](https://gitlab.com/qemu-project/qemu/-/blob/master/accel/kvm/kvm-all.c#L2381) (the code didn't do so since the allocated ([using `object_new_with_class`](https://gitlab.com/qemu-project/qemu/-/blob/master/softmmu/vl.c#L2218)) instance didn't allocate enough memory for `HVFState`).
+
+Eventhough the code wouldn't crash nor have any serious implication, this would leak an `AccelState` and attempts to manually manage accelerators would cause a buffer-overflow.
+Steps to reproduce:
+1. Run a HVF-accelerated VM
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_HVF/2258 b/gitlab/issues_text/target_missing/host_missing/accel_HVF/2258
new file mode 100644
index 000000000..0ed2d01d9
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_HVF/2258
@@ -0,0 +1,23 @@
+Breakpoint setting not working on apple Mac host
+Description of problem:
+1. When use with parameter "-machine virt,accel=hvf -cpu host" to run launch a emulator, it can't set breakpoint and will report error: "warning: failed to set breakpoint site at 0xffff800081bf03cc for breakpoint 1.1: error: 34 sending the breakpoint request"
+but if not use with parameter "-machine virt -cpu cortex-a57"，The breakpoint can be set successfully.
+
+2. Set hardware breakpoint with lldb command "breakpoint set -H -a 0xFFFF800080000000" not report error, but can't hint breakpoint. I try set breakpoint on a old x86 MacOS, It will hint breakpoint successfully.
+
+3. I also try run qemu-system-x86_64 emulator on apple silicon mac, It also can't hint hardware breakping. The command is:
+```
+qemu-system-x86_64 -machine q35,accel=tcg -smp cpus=8  \
+  -kernel arch/x86/boot/bzImage \
+  -append "okaslr"\
+  -nographic -serial mon:stdio \
+  -m 16G \
+  -s -S
+```
+Steps to reproduce:
+1. Launch qemu on Apple silicon Mac. Remember to user "hvf" 
+2. Launch lldb or gdb to set breakpoint.
+3. Set breakpoint and hardware breakpoint.
+4. resume to run qemu by lldb.
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_HVF/2800 b/gitlab/issues_text/target_missing/host_missing/accel_HVF/2800
new file mode 100644
index 000000000..09155f418
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_HVF/2800
@@ -0,0 +1,7 @@
+-accel hvf: Error: ret = HV_DENIED (0xfae94007, at ../accel/hvf/hvf-accel-ops.c:334)
+Description of problem:
+QEMU fails to use -accel i.e., qemu-system-aarch64-unsigned: -accel hvf: Error: ret = HV_DENIED (0xfae94007, at ../accel/hvf/hvf-accel-ops.c:334)
+Steps to reproduce:
+1. Execute the above QEMU command line on a macOS Sequia 15.3
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_HVF/444 b/gitlab/issues_text/target_missing/host_missing/accel_HVF/444
new file mode 100644
index 000000000..82aeeaa7c
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_HVF/444
@@ -0,0 +1 @@
+EFI stub: ERROR: This 64 KB granular kernel is not supported by your CPU
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_HVF/899 b/gitlab/issues_text/target_missing/host_missing/accel_HVF/899
new file mode 100644
index 000000000..297cef0c6
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_HVF/899
@@ -0,0 +1,14 @@
+HVF: Ubuntu Server fails to boot Linux 5.4.0-104
+Description of problem:
+On macOS with HVF, when Ubuntu Server updates the Linux kernel to 5.4.0-104, it no longer boots and gets stuck at `EFI stub: Exiting boot services and installing virtual address map...`. This is not the case with QEMU 6.0.0 (with @agraf's HVF patches applied).
+
+It seems like 5.4.0-104 is the culprit because 5.4.0-100 boots fine.
+Steps to reproduce:
+1. Download Ubuntu Server 20.04 ARM64 ISO: https://ubuntu.com/download/server/arm
+2. Run the above QEMU command (make sure networking is disabled so Ubuntu installer does not auto-upgrade the kernel)
+3. Install Ubuntu with the default settings and reboot
+4. It will not reboot (expected) so Ctrl+C and restart the command adding `-device virtio-net-pci,netdev=net0 -netdev user,id=net0` to the end to get networking
+5. Boot into Ubuntu and install 5.4.0-104 kernel: `sudo apt install linux-image-5.4.0-104-generic`
+6. Reboot and it will get stuck at `EFI stub: Exiting boot services and installing virtual address map...`
+Additional information:
+![image](/uploads/5151ce8ae43911f503411902d330470c/image.png)