Re: Plugins Not Reporting AArch64 SVE Memory Operations

["Alex Bennée" <alex.bennee@linaro.org>]

Aaron Lindsay <aaron@os.amperecomputing.com> writes:

> Hi folks,
>
> I see there has been some previous discussion [1] about 1.5 years ago
> around the fact that AArch64 SVE instructions do not emit any memory
> operations via the plugin interface, as one might expect them to.
>
> I am interested in being able to more accurately trace the memory
> operations of SVE instructions using the plugin interface - has there
> been any further discussion or work on this topic off-list (or that
> escaped my searching)?
>
> In the previous discussion [1], Richard raised some interesting
> questions:
>
>> The plugin interface needs extension for this.  How should I signal that 256
>> consecutive byte loads have occurred?  How should I signal that the controlling
>> predicate was not all true, so only 250 of those 256 were actually active?  How
>> should I signal 59 non-consecutive (gather) loads have occurred?
>> 
>> If the answer is simply that you want 256 or 250 or 59 plugin callbacks
>> respectively, then we might be able to force the memory operations into the
>> slow path, and hook the operation there.  As if it were an i/o operation.
>
> My initial reaction is that simply sending individual callbacks for each
> access (only the ones which were active, in the case of predication)
> seems to fit reasonably well with the existing plugin interface. For
> instance, I think we already receive two callbacks for each AArch64
> `LDP` instruction, right?

This seems the simplest solution. I think what you need to look at is
how the sve_ldst1_host_fn and sve_ldst1_tlb_fn functions eventually
emerge out of the macro expansion (having a -E copy of the compiled
source might be helpful here).

That said I'm confused that softmmu isn't already hooked into by virtue
of using the softmmu slowpath (cpu_[ld|st]_*). However user space
emulation which typically directly accesses a final host address will
need to be fixed.

> If this is an agreeable solution that wouldn't take too much effort to
> implement (and no one else is doing it), would someone mind pointing me
> in the right direction to get started?

Richard, anything to add?

>
> Thanks!
>
> -Aaron
>
> [1] https://lists.nongnu.org/archive/html/qemu-discuss/2020-12/msg00015.html


-- 
Alex Bennée