QEMU 8.2.0 aarch64 sve ldff1b returning 1 byte when 16 are expected

[Mark Charney OS]

Using QEMU v8.2.0 (and also the HEAD of the git master branch), I
encountered an unexpected situation: an ldff1b is returning 1 byte
when I run with the QEMU user level plugin (and setting FFR as if
there was a fault).

However the ldff1b actually loads 16 bytes when: (a) I run this same
test natively on a system with SVE support (no QEMU involved) or (b)
when I run this test interactively (logged in to a console) in GDB
running on the QEMU (with no plugin involved).

I was wondering if this one-byte-per-ldff1b was a known/expected
behavior with plugins?  I guess it is legal to only return one byte,
but I was wondering why QEMU did this and if there was some way to get
QEMU to return 16 bytes in the absence of faults (or as many bytes as
it can up until the fault).

There is *no* page boundary being crossed in the examples of interest,
and no MMIO, so a partial data return is not expected. The page
referenced is mapped and previously referenced.

Talking to Alex Bennee, he pointed out:

> I'm wondering if this is a result of the fix in 6d03226b422
> (plugins: force slow path when plugins instrument memory ops). This
> will always force the slow path which is where we instrument the
> operation.

I attempted to revert this commit locally and no longer got memop
callbacks for any SVE load operations, first fault, nonfault or not
"normal" predicated SVE operations. But I believe ldff1b are returning
16 bytes (judging by the control flow).

Our goal is to use QEMU for tracing with a home-grown plugin.  For our
purposes, we were expecting to observe control flow like what we see
on SVE-enabled hardware where ldff1b returns 16 bytes in the absence
of faults.

If necessary, I can provide a reproducer, that includes:
  - a sve strcpy loop from one of Alex's talks.
  - a simple user level plugin