device: 0.619
risc-v: 0.605
performance: 0.563
graphic: 0.557
register: 0.528
PID: 0.500
ppc: 0.491
architecture: 0.473
socket: 0.437
user-level: 0.425
kernel: 0.399
assembly: 0.389
permissions: 0.372
hypervisor: 0.351
files: 0.350
vnc: 0.343
peripherals: 0.340
debug: 0.306
network: 0.294
semantic: 0.265
x86: 0.260
TCG: 0.249
virtual: 0.240
i386: 0.224
VMM: 0.221
arm: 0.218
mistranslation: 0.195
boot: 0.192
KVM: 0.124

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.