diff options
Diffstat (limited to 'gitlab/issues_text/target_missing/host_arm/accel_missing')
5 files changed, 62 insertions, 0 deletions
diff --git a/gitlab/issues_text/target_missing/host_arm/accel_missing/1168 b/gitlab/issues_text/target_missing/host_arm/accel_missing/1168 new file mode 100644 index 000000000..0d7025640 --- /dev/null +++ b/gitlab/issues_text/target_missing/host_arm/accel_missing/1168 @@ -0,0 +1,13 @@ +ivshmem: ivshmem-doorbell can't notify the MSI-X interrupt on Arm64 guest +Description of problem: +I init several qemu-kvm VMs on my arm64 host, which is a NVIDIA Xavier board. I want to use qemu's ivshmem-doorbell to build a sync shared memory communition with its MSI-X interrupt mechanism. I init the ivshmem-server and ivshmem-client on the host first, after then init the guests. The visul PCI-e device named "Inter-VM shared memory" can be successfully seen in my guests with command "lspci". +I write a driver for this pci-e device to request and handle the MSI-X interrupts, which init well in the guest and can ring or receive from an interrupt vector on other peerID with the driver's IOCTL interface, the peer that receive vector in my environment is the ivshmem-client. However, when i use the ivshmem-client command "int" to ring my guest , the guest can't receive the msi-x interrupt notification. +Steps to reproduce: +1. init ivshmem-server on the host, with command "ivshmem-server -l 4M -M fg-doorbell -n 8 -F -v". +2. init ivshmem-client on the host, with command "ivshmem-client -v". +3. init the qemu-kvm VM . +4. init the driver with "insmod" in guest to request the msi-x interrupt, while "cat /proc/interrupts" shows the interrupt request successfully! +5. on host, ivshmem-client use command "int 1 0" to ring the guest's interrupt trigger, however ,nothing happened. +Additional information: +I am fully sure that there is no problem about the driver I wrote for the pci-e inter-VM shared memory device, for i has tested that the driver works on my X86 PC, where I deployed qemu-x86 VMs and the driver can work well in X86 guests with the inshmem-doorbell mechanism. The ivshmem-client work on host can notify the guest to trigger the correct msix-x interrupt. +Therefore, I digged the msi-x interrupt structure and use devmem tool to write the data to the messageAddress manually, which can correctly trigger the msi-x interrupt in my arm64 guest in the Xavier board, meaning the msi-x interrupt is OK in the guest. So I doubt maybe there is any issue on the ivshmem-doorbell mechanism that ring a interrupt vector in the guset of qemu-aarch64. diff --git a/gitlab/issues_text/target_missing/host_arm/accel_missing/1434 b/gitlab/issues_text/target_missing/host_arm/accel_missing/1434 new file mode 100644 index 000000000..a3c0f2bf4 --- /dev/null +++ b/gitlab/issues_text/target_missing/host_arm/accel_missing/1434 @@ -0,0 +1,3 @@ +Windows on ARM64 host support +Additional information: + diff --git a/gitlab/issues_text/target_missing/host_arm/accel_missing/1635 b/gitlab/issues_text/target_missing/host_arm/accel_missing/1635 new file mode 100644 index 000000000..98f20175b --- /dev/null +++ b/gitlab/issues_text/target_missing/host_arm/accel_missing/1635 @@ -0,0 +1,37 @@ +Slow graphics output under aarch64 hvf (no dirty bitmap tracking) +Description of problem: +When using a display adapter such as `bochs-display` (which, yes, I realize is not the ideal choice for an aarch64 guest, but it works fine under TCG and KVM, so bear with me) under `hvf` acceleration on an M1 Mac, display output is slow enough to be measured in seconds-per-frame. + +The issue seems to stem from each write to the framebuffer memory resulting in a data abort, while the expected behavior is that only one such write results in a data abort exception, which is handled by marking the region dirty and then subsequent writes do not yield exceptions until the display management in QEMU resets the dirty flag. Instead, every pixel drawn causes the VM to trap, and performance is degraded. +Steps to reproduce: +1. Start an aarch64 HVF guest with the `bochs-display` display adapter. +2. Observe performance characteristics. +3. +Additional information: +I reported this issue on IRC around a year ago, and was provided with a patch by @agraf which I have confirmed works. That patch was shared on the `qemu-devel` mailing list in February, 2022, with a response from @pm215: https://lists.gnu.org/archive/html/qemu-devel/2022-02/msg00609.html + +As a quick summary, the patch takes this snippet from the i386 HVF target: + +https://gitlab.com/qemu-project/qemu/-/blob/master/target/i386/hvf/hvf.c#L132-138 + +And applies a variation of it to the ARM target when handling a data abort exception, before this assert: + +https://gitlab.com/qemu-project/qemu/-/blob/master/target/arm/hvf/hvf.c#L1381 + +Something to the effect of: + +```c + if (iswrite) { + uint64_t gpa = hvf_exit->exception.physical_address; + hvf_slot *slot = hvf_find_overlap_slot(gpa, 1); + + if (slot && slot->flags & HVF_SLOT_LOG) { + memory_region_set_dirty(slot->region, 0, slot->size); + hv_vm_protect(slot->start, slot->size, HV_MEMORY_READ | + HV_MEMORY_WRITE | HV_MEMORY_EXEC); + break; + } + } +``` + +I am reporting this issue now as I updated my git checkout with the release of QEMU 8.0.0 and was surprised to find that the patch had never made it upstream and the issue persists. diff --git a/gitlab/issues_text/target_missing/host_arm/accel_missing/1678 b/gitlab/issues_text/target_missing/host_arm/accel_missing/1678 new file mode 100644 index 000000000..f0edb7546 --- /dev/null +++ b/gitlab/issues_text/target_missing/host_arm/accel_missing/1678 @@ -0,0 +1,8 @@ +Running Qemu on windows arm64 host, and use qemu-system-x86_64 to emulate an ubuntu OS, but it didn't work. +Description of problem: +Running QemuV8.0 on windows arm64 host, and use qemu-system-x86_64 to emulate an ubuntu OS, but it didn't work. +Steps to reproduce: +1.qemu-img.exe create hdd.img 10G +2.qemu-system-x86_64.exe -m 8096 hdd.img -cdrom ubuntu22.04-desktop-amd64.iso -machine pc +Additional information: +both Use qemu v8.0 and qemu v8.1 to test, but failed also diff --git a/gitlab/issues_text/target_missing/host_arm/accel_missing/443 b/gitlab/issues_text/target_missing/host_arm/accel_missing/443 new file mode 100644 index 000000000..b8059db50 --- /dev/null +++ b/gitlab/issues_text/target_missing/host_arm/accel_missing/443 @@ -0,0 +1 @@ +QEMU on Windows aarch64 |