diff options
Diffstat (limited to 'gitlab/issues_text/target_missing/host_missing/accel_HVF')
9 files changed, 0 insertions, 130 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 deleted file mode 100644 index 4307c03df..000000000 --- a/gitlab/issues_text/target_missing/host_missing/accel_HVF/1011 +++ /dev/null @@ -1,21 +0,0 @@ -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 deleted file mode 100644 index fb807aafd..000000000 --- a/gitlab/issues_text/target_missing/host_missing/accel_HVF/1091 +++ /dev/null @@ -1,13 +0,0 @@ -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 deleted file mode 100644 index 8c7d34bac..000000000 --- a/gitlab/issues_text/target_missing/host_missing/accel_HVF/1299 +++ /dev/null @@ -1,24 +0,0 @@ -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 deleted file mode 100644 index 77ce3808b..000000000 --- a/gitlab/issues_text/target_missing/host_missing/accel_HVF/1364 +++ /dev/null @@ -1,15 +0,0 @@ -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 deleted file mode 100644 index 2a70dcafa..000000000 --- a/gitlab/issues_text/target_missing/host_missing/accel_HVF/1571 +++ /dev/null @@ -1,12 +0,0 @@ -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 deleted file mode 100644 index 0ed2d01d9..000000000 --- a/gitlab/issues_text/target_missing/host_missing/accel_HVF/2258 +++ /dev/null @@ -1,23 +0,0 @@ -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 deleted file mode 100644 index 09155f418..000000000 --- a/gitlab/issues_text/target_missing/host_missing/accel_HVF/2800 +++ /dev/null @@ -1,7 +0,0 @@ --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 deleted file mode 100644 index 82aeeaa7c..000000000 --- a/gitlab/issues_text/target_missing/host_missing/accel_HVF/444 +++ /dev/null @@ -1 +0,0 @@ -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 deleted file mode 100644 index 297cef0c6..000000000 --- a/gitlab/issues_text/target_missing/host_missing/accel_HVF/899 +++ /dev/null @@ -1,14 +0,0 @@ -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: - |