qemu-arm
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Alex Bennée
Subject: Re: QEMU 8.2.0 aarch64 sve ldff1b returning 1 byte when 16 are expected
Date: Fri, 16 Feb 2024 11:40:21 +0000
User-agent: mu4e 1.11.28; emacs 29.1

Mark Charney OS <mark.charney@os.amperecomputing.com> writes:

> 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).

Could it be a change with the location w.r.t a page boundary between the
two cases?

>
> 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.

Yeah lets add the test case.

>   - a simple user level plugin

It should show up with execlog as well right?

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro



reply via email to

[Prev in Thread] Current Thread [Next in Thread]