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

[Peter Maydell]

On Fri, 16 Feb 2024 at 11:40, Alex Bennée <alex.bennee@linaro.org> wrote:
>
> Mark Charney OS <mark.charney@os.amperecomputing.com> writes:
> > 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.

Yes, this sounds like it. The implementation of the SVE first-fault
instructions is that we probe the TLB to see if the address for bytes
beyond the first load is backed by host memory. If it's actually backed
by MMIO then we will not load from that. A comment in sve_ldnfff1_r()
explains why:

     * Per the MemSingleNF pseudocode, a no-fault load from Device memory
     * must not actually hit the bus -- it returns (UNKNOWN, FAULT) instead.
     *
     * Unfortuately we do not have access to the memory attributes from the
     * PTE to tell Device memory from Normal memory.  So we make a mostly
     * correct check, and indicate (UNKNOWN, FAULT) for any MMIO.
     * This gives the right answer for the common cases of "Normal memory,
     * backed by host RAM" and "Device memory, backed by MMIO".
     * The architecture allows us to suppress an NF load and return
     * (UNKNOWN, FAULT) for any reason, so our behaviour for the corner
     * case of "Normal memory, backed by MMIO" is permitted.  The case we
     * get wrong is "Device memory, backed by host RAM", for which we
     * should return (UNKNOWN, FAULT) for but do not.

Unfortunately because the plugin memory-access handling forces the
slow-path it is TLB_MMIO here, and so it ends up in the "normal memory,
backed by MMIO" corner case, where we do the architecturally-permitted
but perhaps unexpected thing of only loading one byte.

thanks
-- PMM