add 18th iteration of classifier

1 files changed, 67 insertions, 0 deletions

diff --git a/results/classifier/118/performance/1635 b/results/classifier/118/performance/1635
new file mode 100644
index 000000000..a0cd7b223
--- /dev/null
+++ b/results/classifier/118/performance/1635
@@ -0,0 +1,67 @@
+performance: 0.864
+graphic: 0.645
+i386: 0.631
+architecture: 0.481
+device: 0.466
+PID: 0.281
+mistranslation: 0.253
+ppc: 0.248
+permissions: 0.216
+register: 0.193
+kernel: 0.190
+semantic: 0.177
+socket: 0.168
+hypervisor: 0.134
+peripherals: 0.127
+files: 0.126
+vnc: 0.122
+arm: 0.095
+debug: 0.082
+network: 0.074
+VMM: 0.069
+virtual: 0.067
+assembly: 0.065
+risc-v: 0.063
+boot: 0.059
+user-level: 0.041
+x86: 0.024
+TCG: 0.014
+KVM: 0.005
+
+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.