diff options
Diffstat (limited to 'gitlab/issues/target_missing/host_missing/accel_HVF')
9 files changed, 212 insertions, 0 deletions
diff --git a/gitlab/issues/target_missing/host_missing/accel_HVF/1011.toml b/gitlab/issues/target_missing/host_missing/accel_HVF/1011.toml new file mode 100644 index 000000000..79134ba53 --- /dev/null +++ b/gitlab/issues/target_missing/host_missing/accel_HVF/1011.toml @@ -0,0 +1,29 @@ +id = 1011 +title = "hvf: RDTSCP capability not passed to guests" +state = "closed" +created_at = "2022-05-02T20:34:23.082Z" +closed_at = "2022-07-14T13:25:47.363Z" +labels = ["accel: HVF"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/1011" +host-os = "macOS Monterey 12.3.1" +host-arch = "x86_64" +qemu-version = "6.2.0, master" +guest-os = "Alpine 3.15.4" +guest-arch = "x86_64" +description = """""" +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 = """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/target_missing/host_missing/accel_HVF/1091.toml b/gitlab/issues/target_missing/host_missing/accel_HVF/1091.toml new file mode 100644 index 000000000..3fefde13e --- /dev/null +++ b/gitlab/issues/target_missing/host_missing/accel_HVF/1091.toml @@ -0,0 +1,21 @@ +id = 1091 +title = "qemu-system-x86_64 hard crashes when using `--accel hvf` on intel Mac" +state = "opened" +created_at = "2022-06-28T09:14:24.223Z" +closed_at = "n/a" +labels = ["accel: HVF"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/1091" +host-os = "macOS 12.4 - Darwin 21.5.0: root:xnu-8020.121.3~4/RELEASE_X86_64 x86_64" +host-arch = "x86 - CPU Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz" +qemu-version = "QEMU emulator version 7.0.0" +guest-os = "Debian" +guest-arch = "x86" +description = """The QEMU process hard crashes after a few minutes. The only message is: + +``` +vmx_write_mem: mmu_gva_to_gpa ffff990489fa0000 failed +```""" +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 = """""" diff --git a/gitlab/issues/target_missing/host_missing/accel_HVF/1299.toml b/gitlab/issues/target_missing/host_missing/accel_HVF/1299.toml new file mode 100644 index 000000000..ddb9659e9 --- /dev/null +++ b/gitlab/issues/target_missing/host_missing/accel_HVF/1299.toml @@ -0,0 +1,32 @@ +id = 1299 +title = "User networking with an SMB Share while not running as root" +state = "opened" +created_at = "2022-11-04T07:52:58.161Z" +closed_at = "n/a" +labels = ["Networking", "accel: HVF", "hostos: macOS"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/1299" +host-os = "MacOS 12.6" +host-arch = "x86 (or ARM)" +qemu-version = "7.1.0" +guest-os = "Any Linux distro with CIFS, or with `smbclient" +guest-arch = "-" +description = """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.""" +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 = """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/target_missing/host_missing/accel_HVF/1364.toml b/gitlab/issues/target_missing/host_missing/accel_HVF/1364.toml new file mode 100644 index 000000000..5af46f397 --- /dev/null +++ b/gitlab/issues/target_missing/host_missing/accel_HVF/1364.toml @@ -0,0 +1,27 @@ +id = 1364 +title = "Support vmnet networking without elevated permissions" +state = "opened" +created_at = "2022-12-12T23:15:49.158Z" +closed_at = "n/a" +labels = ["Networking", "accel: HVF", "hostos: macOS"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/1364" +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 = """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/target_missing/host_missing/accel_HVF/1571.toml b/gitlab/issues/target_missing/host_missing/accel_HVF/1571.toml new file mode 100644 index 000000000..ee87640a6 --- /dev/null +++ b/gitlab/issues/target_missing/host_missing/accel_HVF/1571.toml @@ -0,0 +1,20 @@ +id = 1571 +title = "accel/hvf: Instance size not properly declared" +state = "opened" +created_at = "2023-04-02T19:27:47.892Z" +closed_at = "n/a" +labels = ["Bite Sized", "accel: HVF", "kind::Bug"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/1571" +host-os = "macOS" +host-arch = "x86_64/ARM" +qemu-version = "Almost HEAD" +guest-os = "Any supported by HVF" +guest-arch = "x86, AARCH64" +description = """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.""" +reproduce = """1. Run a HVF-accelerated VM""" +additional = """""" diff --git a/gitlab/issues/target_missing/host_missing/accel_HVF/2258.toml b/gitlab/issues/target_missing/host_missing/accel_HVF/2258.toml new file mode 100644 index 000000000..8c3c69291 --- /dev/null +++ b/gitlab/issues/target_missing/host_missing/accel_HVF/2258.toml @@ -0,0 +1,31 @@ +id = 2258 +title = "Breakpoint setting not working on apple Mac host" +state = "opened" +created_at = "2024-04-01T11:03:35.406Z" +closed_at = "n/a" +labels = ["accel: HVF", "hostos: macOS"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/2258" +host-os = "Mac OS 14.4.1" +host-arch = "ARM" +qemu-version = "8.2.1" +guest-os = "None" +guest-arch = "x86, ARM" +description = """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 +```""" +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 = """""" diff --git a/gitlab/issues/target_missing/host_missing/accel_HVF/2800.toml b/gitlab/issues/target_missing/host_missing/accel_HVF/2800.toml new file mode 100644 index 000000000..fdd70fb66 --- /dev/null +++ b/gitlab/issues/target_missing/host_missing/accel_HVF/2800.toml @@ -0,0 +1,15 @@ +id = 2800 +title = "-accel hvf: Error: ret = HV_DENIED (0xfae94007, at ../accel/hvf/hvf-accel-ops.c:334)" +state = "opened" +created_at = "2025-02-02T23:03:38.244Z" +closed_at = "n/a" +labels = ["accel: HVF", "hostos: macOS"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/2800" +host-os = "macOS" +host-arch = "64-bit ARM" +qemu-version = "9.2.50" +guest-os = "n/a" +guest-arch = "n/a" +description = """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)""" +reproduce = """1. Execute the above QEMU command line on a macOS Sequia 15.3""" +additional = """""" diff --git a/gitlab/issues/target_missing/host_missing/accel_HVF/444.toml b/gitlab/issues/target_missing/host_missing/accel_HVF/444.toml new file mode 100644 index 000000000..670c98a74 --- /dev/null +++ b/gitlab/issues/target_missing/host_missing/accel_HVF/444.toml @@ -0,0 +1,15 @@ +id = 444 +title = "EFI stub: ERROR: This 64 KB granular kernel is not supported by your CPU" +state = "closed" +created_at = "2021-06-22T16:19:06.057Z" +closed_at = "2022-02-21T14:56:34.943Z" +labels = ["Documentation", "accel: HVF"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/444" +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_missing/host_missing/accel_HVF/899.toml b/gitlab/issues/target_missing/host_missing/accel_HVF/899.toml new file mode 100644 index 000000000..b5b210900 --- /dev/null +++ b/gitlab/issues/target_missing/host_missing/accel_HVF/899.toml @@ -0,0 +1,22 @@ +id = 899 +title = "HVF: Ubuntu Server fails to boot Linux 5.4.0-104" +state = "opened" +created_at = "2022-03-11T06:48:01.672Z" +closed_at = "n/a" +labels = ["accel: HVF"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/899" +host-os = "macOS 12.1" +host-arch = "ARM64" +qemu-version = "6.2.0" +guest-os = "Ubuntu 20.04" +guest-arch = "ARM64" +description = """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.""" +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 = """""" |