add results

1 files changed, 42 insertions, 0 deletions

diff --git a/results/classifier/gemma3:27b/runtime/2655 b/results/classifier/gemma3:27b/runtime/2655
new file mode 100644
index 000000000..eb6ceccef
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/2655
@@ -0,0 +1,42 @@
+
+
+
+A problem in target/riscv/vector_helper.c: vext_ldff()
+Description of problem:
+I‘m confused about a behavior in function vext_ldff() in target/riscv/vector_helper.c:
+```
+static inline void
+vext_ldff(...)
+{
+...
+    for (i = env->vstart; i < env->vl; i++) {
+...
+        if (i == 0) {
+            probe_pages(env, addr, nf << log2_esz, ra, MMU_DATA_LOAD);
+        } else {
+...
+                flags = probe_access_flags(env, addr, offset, MMU_DATA_LOAD,
+                                           mmu_index, true, &host, 0);
+...
+                if (flags & ~TLB_WATCHPOINT) {
+                    vl = i;
+                    goto ProbeSuccess;
+                }
+...
+        }
+    }
+ProbeSuccess:
+...
+}
+```
+If the current instruction has a memory callback by plugin, the function probe_access_flags() will return TLB_MMIO when the page is exist.
+
+In this case, the function will always set vl to 1, goto ProbeSuccess, and only load the first element. Does it meet expectations? 
+
+This problem occurred in both linux-user mode and full-system mode.
+
+Maybe we can add extra parameter to probe_access_flags(), in order to change the behavior of inner functions.
+Steps to reproduce:
+1. Make a binary with instruction vle(x)ff.v, what I am using is https://github.com/chipsalliance/riscv-vector-tests.
+2. Write a plugin to add memory callbacks.
+3. Observe the behavior of the function.