Re: [PATCH v3] target/riscv: preserve vl on element-zero fault

Thanks Max, that makes sense.

I'll update the root-cause description and the test comment accordingly.
The implementation itself will remain unchanged.

Thanks,
Zephyr

On Wed, Aug 12, 2026 at 11:13 PM Max Chou <[email protected]> wrote:

> On 2026-08-11 10:55, Zephyr Li wrote:
> > A unit-stride fault-only-first load must leave vl unchanged when element
> > zero raises a synchronous exception. Keep the shortened value in a local
> > bound until all loads complete, and only then update the architectural
> vl.
> >
>
> The failing case is a corner case. When the element-0 faulting probe in
> vext_ldff() faults, it longjmps out of the helper, ProbeSuccess is never
> reached and env->vl is never touched -- that path was already correct.
>
> The broken path is element 0 in a mapped MMIO page: probe_access()
> succeeds there, but QEMU cannot know a device transaction will fail
> without issuing it that broken the assumption of the pre probe_access()
> checking.
>
> > --- /dev/null
> > +++ b/tests/tcg/riscv64/test-vle32ff.S
> ...
> > +     vsetvli t2, t1, e32, m1, ta, ma
> > +     li      t0, 0x18000000  /* Unmapped gap in the virt memory map.
> > */
>
> Actually it is not unmapped -- it is mapped as unassigned MMIO, and that
> is exactly why the bug reproduces: an unmapped address would make the
> element-0 probe fault and the test would pass even with the bug present.
>
>
> I think the fixed vext_ldff implementation is valid according to the
> RISC-V specification, considering the VL reduction rule and the
> non-idempotent constraint. Only the test case wording and the root
> cause explanation may need to be updated.
>
> As for the patch:
> Reviewed-by: Max Chou <[email protected]>
>